Running a United States SMS programme is less about knowing the law and more about being able to prove, on demand, that your operation does what it says it does. Consent, opt-outs, sender identity, and registration are all things carriers, aggregators, and eventually a customer's lawyer can ask you to evidence. Most programmes don't fail because nobody understood the rules — they fail because the evidence was never captured, or it lived in five different systems that didn't agree with each other.
This is operational guidance, not legal advice. Requirements vary by jurisdiction, by carrier, and by the terms your own vendors impose on top of the law — and those terms change. Nothing here should be treated as a substitute for reviewing current primary guidance from your carriers, your registry provider, and your own counsel before you rely on it for a live programme.
Consent evidence: what you need to be able to produce later
The question is never "did we get consent." It's "can we produce the record six months from now, for a specific phone number, on demand." That record should include:
- Source — which form, keyword, checkout flow, or partner lead source captured the opt-in.
- Timestamp — when consent was captured, in a timezone-stable format.
- Wording shown — the exact disclosure text the customer saw at that moment, not the current version of your terms page. If your legal team edits the disclosure copy next quarter, you need the old copy preserved against old consent records.
- Channel/IP — the page URL, app screen, or channel (web form, SMS keyword, call center, in-store) and, where captured, the IP address associated with a web-based opt-in.
Where teams usually can't produce this: third-party lead sources and legacy sign-up forms. A lead vendor will happily tell you "the consumer opted in," but if they can't hand you the disclosure text and timestamp that went with that specific record, you don't have evidence — you have an assertion. Marketing pages also get edited in place, so unless disclosure text is versioned and tied to consent records, you can't reconstruct what a customer actually saw a year ago.
Brand and campaign registration: does the paperwork match the traffic
10DLC (or equivalent) registration exists to tell carriers who you are, what you're sending, and how customers get in and out. Registration fields typically cover legal business identity, declared use case, sample messages, opt-in/opt-out language, and expected throughput.
The most common operational failure is drift: a campaign registered as "account notifications" that later carries promotional content, or a use case declared as low-volume that scales past its registered throughput. This isn't just a paperwork problem — carriers and aggregators actively compare declared use case against observed traffic patterns, and a mismatch is one of the more common reasons legitimate traffic starts getting filtered or throttled. Registration should be reviewed whenever campaign content, volume, or audience meaningfully changes, not just at initial setup.
Sender and category alignment across traffic classes
Different traffic classes — marketing, transactional, OTP, customer service — carry different expectations, and mixing them under one sender ID or one registered campaign is a recurring source of trouble. An OTP sender that starts carrying promotional copy stops looking like an OTP sender to carrier filtering systems, and marketing sends can crowd out time-sensitive authentication traffic if they share a route. Keep senders and campaigns aligned to a single declared purpose, and treat a change in what a sender carries as a change that needs sign-off, not a copy tweak.
Opt-out handling
- Recognised keywords — STOP and its common variants need to work automatically and immediately. But customers also use natural language ("please stop texting me," "remove me"), and support channels (phone, email, chat) receive opt-out requests too. Decide, explicitly, whether and how those get captured and routed into the same suppression system as a STOP reply.
- Propagation across vendors and campaigns — a suppression added in one system (a support ticket, a specific campaign's keyword handler) needs to reach every other system that might message that number: other campaigns, other vendors, CRM re-imports, lead vendor syncs. This is usually the weakest link — suppression logic is often built per-campaign rather than per-customer.
- Latency — the gap between "customer asked to stop" and "number is actually suppressed everywhere" is a real, measurable window. It should be short, and it should be monitored, not assumed.
- Confirmation messages — sending a final confirmation of opt-out is common practice; make sure that confirmation message itself doesn't get treated as new marketing content that requires its own consent check, and that it's the last message the number receives.
Quiet hours and sending windows
Quiet hours are simple to state and hard to implement correctly, because they depend on the recipient's local time, not the sender's. Resolving a phone number to a timezone is a genuine engineering problem: area codes don't reliably map to current location, ported numbers carry no location signal, and a customer's stored mailing address may not match where their phone actually is. Decide what signal you'll trust for timezone resolution (billing address, IP at signup, carrier-reported region) and be explicit that it's an approximation — then build sending-window logic around that decision rather than assuming a single global cutoff time works everywhere.
Suppression lists: scope, ownership, and vendor changes
A suppression list is only useful if everyone agrees what it covers. Is it per-brand, per-campaign, or global across every message type a business sends? Who owns it — the SMS platform, the CRM, a dedicated compliance system? What happens when you switch messaging vendors: does the suppression list migrate with you, or does the new vendor start from zero and start messaging previously-suppressed numbers? This is a genuinely common failure point during vendor migrations, and it's worth a written runbook step, not a verbal handoff.
Template and content governance
- Who approves a new message template before it goes live, and against what criteria?
- Is there a version history of template copy, so you can reconstruct what was sent to a given audience segment on a given date?
- How are links handled — are shortened links reviewed before use, and can copy be changed in production without going back through approval?
- Who has production access to edit live templates, and is that access logged?
A template that quietly drifts from its approved, registered version is exactly the kind of thing that shows up as a mismatch during a carrier or registry review.
Record retention
How long you keep consent records, opt-out records, message logs, and template history is a policy decision the business has to make deliberately — it shouldn't default to "whatever the database happens to retain" or "whatever the vendor's default log retention is." Decide retention periods with input from legal counsel based on your own risk profile and the guidance current at the time, document the decision, and make sure the retention period is actually enforced across every system involved (including third-party vendors) rather than just the primary platform.
Route and vendor change control
A change in sending route — a new aggregator, a failover path, a new sender ID — is a compliance-relevant change, not just a technical one, because it can affect registration validity, suppression list coverage, and throughput expectations. Before a route change goes live, log: what changed, why, who approved it, whether registration was updated to reflect it, and whether the suppression list was confirmed to carry over. Treat this the same way you'd treat a change to consent language — as something that needs a record, not just a deploy.
Incident ownership
When a carrier, aggregator, or regulator raises a complaint or a violation notice, the first hour matters. Decide in advance:
- Who is the named point of contact for a carrier or vendor escalation, and do they have authority to pause a campaign unilaterally?
- What evidence pack can be assembled quickly — consent record for the specific number, opt-out history if relevant, template version sent, registration status, route history?
- Who communicates with the vendor or carrier, and who reviews before response goes out?
Programmes that handle incidents well aren't the ones with no problems — they're the ones that can produce the relevant evidence pack in minutes rather than days.
What to verify yourself
None of the above substitutes for checking current, primary guidance for your own programme: your registry provider's current registration requirements, your carriers' current filtering and content policies, and applicable federal and state law as it stands today, ideally with your own counsel involved. Rules, registration fields, and platform requirements change, and what's accurate at the time this is written may not be accurate by the time you read it.
Flowstates doesn't provide legal compliance — that's a decision for your business and your counsel to own. What we help with is the operational layer underneath it: routing, sender management, and the ability to run on your own vendors, a Flowstates-managed channel, or a mix of both, with the visibility to actually answer the questions in this checklist when someone asks.