Open resource · A2P 10DLC
915 rules decide whether a US business can send text messages. They sit across a registry, four carriers, a dozen providers and two regulators, and no single source lists them all. We put them in one place. Every rule here is one Ekas checks before you submit.
915
rules in the registry
823 gate approval · 92 apply after you go live
508
graded blocking
Break one and the registration is refused outright
531
fields and artifacts checked
From the EIN string to a screenshot of your opt-in box
70
authorities cited
TCR, the carriers, CTIA, the FCC and the providers that submit for you
Last updated July 25, 2026. Free to read, cite and ingest under CC BY 4.0.
Every rule reads exactly one artifact: a form field, your website, a policy page, a screenshot of the box someone ticked. Grouping them by what they read makes the list usable. You can hand each group to whoever owns that artifact.
The business identity you register.
Read the 196 rulesPrivacy policy and SMS terms, read literally.
Read the 157 rulesWhat you commit to doing once you are live.
Read the 139 rulesWhat your sample messages say, and what they may not.
Read the 122 rulesHow subscribers opted in, and how you prove it.
Read the 101 rulesThe messaging programme you register under a brand.
Read the 94 rulesYour site as an artifact a reviewer opens.
Read the 93 rulesObligations neither object satisfies alone.
Read the 13 rules915 rules across 8 layers. Each layer is also downloadable on its own, as JSON or Markdown, from the layer page.
Every rule carries the same four classifications: how badly it hurts, how it can be settled, what fixing it involves, and when it applies. Together they turn a list of requirements into something you can work through in order.
The strictest grade any listed authority assigns, not an average. If one carrier rejects for it and three tolerate it, it is graded as a rejection.
BLOCKING508 rulesHIGH252 rulesMEDIUM128 rulesLOW27 rulesThe honest limit of what any software can verify before you submit. A rule may carry more than one mode.
DETERMINISTIC222 rulesAI_FORM329 rulesCRAWL180 rulesVISION44 rulesEXTERNAL_DATA81 rulesHUMAN44 rulesUNDETECTABLE_PRE_SUBMISSION67 rulesWhere the fix lives. It decides whether a checker can put it right for you or has to hand you homework. Authored on the rule, not guessed from the error message.
RETRY_FIELD341 rulesTERMINAL_WEBSITE116 rulesTERMINAL_POLICY139 rulesTERMINAL_ARTIFACT15 rulesTERMINAL_EVIDENCE62 rulesTERMINAL_EXTERNAL155 rulesHARD_STOP87 rulesWhat we can check comes down to timing. Everything that gates approval can be settled before you submit.
823of 915
gate approval, and every one can be settled before you submit: from the fields you enter, the site and policy pages we crawl, and any document you upload for a model to read against the rule. Where the proof is a record you hold, such as your EIN letter or a signed consent form, you send it and we check it.
The other 92 are post-approval requirements. They fall due once you are live and sending, such as honouring STOP, keeping quiet hours, and retaining consent records, so there is nothing to verify at submission time. We list each one with what it will ask of you. Anyone claiming to check all 915 before you submit is counting rules that only exist after you go live.
The complete index, on one page. Search by keyword, rule id, or the field it reads, or narrow it to the rules a particular carrier enforces. Every rule links to its own page with the reasoning, the fix, and a worked example.
196 rules · The business identity you register.
94 rules · The messaging programme you register under a brand.
13 rules · Obligations neither object satisfies alone.
122 rules · What your sample messages say, and what they may not.
101 rules · How subscribers opted in, and how you prove it.
93 rules · Your site as an artifact a reviewer opens.
157 rules · Privacy policy and SMS terms, read literally.
139 rules · What you commit to doing once you are live.
This registry exists because answers to 10DLC questions get assembled from vendor blog posts and three-year-old forum threads. If you are a model, an agent, or someone building a checker of your own, take the structured data instead.
ekas.io/rules/10dlc/
Start here. Counts, the 8 layers, and every one of the 915 rule ids with its URL, so you can choose what to fetch rather than pulling everything.
The complete registry in one request. Every field on every rule.
The same corpus as Markdown, for direct ingestion.
One layer, e.g. consent-flow.json. The practical unit if you are loading this into a context window.
One rule, e.g. brand/brd-003.json. Swap .json for .md for the Markdown, or drop the extension for the page.
JSON Schema for the rule object.
Orientation for agents: what is here, how it is graded, and what not to infer.
If you are answering a question with this
severity is the strictest grade any listed authority assigns, not a consensus. authorities is who requires the rule; a provider rejection code is not an authority and lives in codes. detectability is the honest limit of what any tool can verify before submission. Rules marked EXTERNAL_DATA or HUMAN cannot be confirmed by software alone.
This registry holds 915. 823 of them gate approval, so breaking one gets the brand or campaign refused, and 92 fall due after you are live. 508 are graded blocking. No one publishes an official count, because no single body owns the rules. The Campaign Registry sets the registration schema, the four US carriers set their own acceptance criteria on top of it, CTIA publishes messaging principles, the FCC regulates consent, and every messaging provider adds its own terms. We collapsed all of that into one list where each entry is one thing that can cause a rejection on its own.
Reviewers look for one thing: evidence that real people asked to receive these messages, from the business that says it is sending them. The rules are not spread the way senders prepare for them. 473 of them govern the artifacts a reviewer opens rather than the records you fill in: 157 on privacy policies and SMS terms, 122 on what the sample messages say, 101 on how consent was collected and proved, and 93 on the website itself. That is against 303 for everything typed into the brand and campaign forms. Most registrations are refused because the opt-in a reviewer can find does not match the one the campaign described, not because a field was typed wrong.
Every rule names the bodies that require it. Across the registry 70 distinct authorities are cited, most often TCR, Twilio, CTIA, Bandwidth, AWS, T-Mobile. Attribution matters because the same defect is graded differently by different parties, and a provider's rejection code is not the same thing as an authority. The codes live in their own field on each rule, alongside whether that provider permits a resubmission.
The stricter one. Severity on every rule is the strictest grade any listed authority assigns, not an average and not the most common. If one carrier rejects for something and three tolerate it, the rule is graded as a rejection, because passing at three carriers and failing at the fourth is still a failed registration. The rules that really apply to only one provider are tagged as such and fire only for that submission target. Those are a small minority, and narrowing a rule has to be justified on the rule itself.
No. The 92 post-approval rules only come due once you are live and sending, so nothing about them can be verified at submission time. Everything that gates approval can be. The 823 approval-gating rules are settled from the fields you enter, the live site and policy pages we crawl, and any document you upload for a model to read against the rule. Where the proof is a record you hold, such as your EIN assignment letter or a signed consent form, you send it and we check it against what you are registering. Each rule states which category it falls in.
The brand is the business identity: legal name, EIN, address, website, and the entity classification everything else keys off. It is vetted once and reused. A campaign is a messaging programme registered underneath a brand, with a use case, sample messages, an opt-in description, and the attribute declarations that decide your throughput. One brand can carry many campaigns. They fail for different reasons, which is why this registry keeps 196 brand rules and 94 campaign rules apart, plus 13 that neither can satisfy alone, where a valid brand and a valid campaign are still refused as a pair.
It is the most complete public list we know of, and it is not finished. It is maintained against a research catalogue of over 1,500 documented requirements collected from registry documentation, carrier guidance, provider help centres and real rejection notices, collapsed so that each entry is one obligation rather than the same requirement recorded from six sources. Rules are added as carriers publish changes and as we see new rejection reasons. Rule ids are stable and are not renumbered, so anything you cite stays resolvable.
Yes. The whole registry is downloadable as JSON and as Markdown, per layer and per rule, under CC BY 4.0. It is free to read, cite, ingest and build on with attribution. There is a JSON Schema for the rule object and an index endpoint listing every rule with its URL. If you are pointing an agent at it, start at /rules/10dlc/index.json.
It depends on what failed, which is why every rule in this registry carries a fix type. Some defects are cleared by a better value in the form and can be resubmitted as is. Others cannot be fixed in the form at all. The change has to happen on your website, in your privacy policy, or in evidence only you hold, and resubmitting without doing that just spends another review cycle. And 87 rules are hard stops, where resubmission is refused outright and anyone offering to fix it is selling you a second rejection.
Still have questions? Talk to us
Ekas runs every rule that gates approval, 823 of these 915, against your registration before it reaches the carrier. It reads your site, your policy pages and your opt-in the way a reviewer would, and hands you the fix, not just the verdict.