A2P 10DLC rule registry
A campaign is a set of promises about what you will send, to whom, and how they asked. These rules cover use-case selection, field bounds, the attribute declarations that gate throughput, and the evidence each declaration silently commits you to producing.
The opt-in / message-flow field must carry no leading or trailing whitespace.
The mandatory campaign boolean attributes — embeddedLink, embeddedPhone, ageGated, directLending and numberPool — must each be explicitly true or false, never left unset.
Every campaign registration field must be written in English.
Uploaded opt-in evidence must be a JPG, PNG or PDF file no larger than 500 KB.
The campaign description must describe this specific programme rather than restating that the business sends messages.
The campaign description must name the business whose messages these are, not the platform or agency registering on its behalf.
No campaign field may reference a second company, subsidiary, franchise or client brand alongside the registered one.
Where any campaign text describes promotional or marketing content, MARKETING must be a declared use case or sub-use case.
A campaign must describe application-to-person business messaging, not person-to-person or influencer-to-follower messaging.
Where an ISV or platform registers on behalf of a customer, the campaign must carry the customer's website and brand information, not the platform's.
The message-flow / CTA field must state the exact consent-capture mechanism end to end.
All opt-in methods actually in use must be described inside the single message-flow field.
Every declared opt-in method must carry its own description satisfying that method's own rule set.
Every opt-in method actually in use must appear in the submission; none may be left out.
The URL in the message flow must point at the page that carries the consent surface, verified against the crawl.
Where the opt-in surface is login-gated, unpublished, on paper, verbal, or in-store, a publicly hosted screenshot URL is required in the message flow.
A hosted evidence URL must return 200 and render the artifact rather than a 404, a timeout, a redirect or a placeholder.
The message-flow / CTA field must state the message types the subscriber will receive.
The message-flow / CTA field must state the message frequency.
The message-flow / CTA field must state that message and data rates may apply.
The message-flow / CTA field must state how the consumer gets help.
The message-flow / CTA field must state how the consumer opts out.
The message-flow / CTA field must state the programme terms, either in full or as a link.
The message-flow / CTA field must state the privacy policy link, or that opt-in data will not be shared.
The message-flow / CTA field must state how the consumer is told about the programme and what they do to join.
The message-flow / CTA field must state where on the site, app, or premises the opt-in happens.
The message-flow / CTA field must state who is opting in and at what moment.
The message-flow / CTA field must state how consent is recorded once given.
The described opt-in should follow one of the published message-flow templates: digital, verbal, paper, or inbound keyword.
The description or the message flow must describe some form of opt-in, however briefly.
Implied consent is acceptable only where both the use case and the message flow are conversational, with the consumer sending first.
The consent standard evidenced must match the content grade: conversational needs implied consent, informational needs express consent, promotional needs express written consent.
A web-form or checkout opt-in must supply the link to the opt-in page, or a screenshot of the form.
A keyword-based opt-in must populate both the opt-in keywords and the opt-in confirmation message.
A keyword opt-in must state the exact keyword and the exact destination number in the message flow.
The opt-in methods ticked on the form must be the ones the message flow describes, in both directions.
A QR-code opt-in must include the QR image in the registration evidence.
A QR opt-in must state whether the code opens a hosted opt-in form or a pre-filled SMS in the native messaging app.
A campaign whose content requires express written consent must not declare a spoken opt-in as its only collection method.
A debt-collection campaign must not collect its consent verbally.
Consent evidence captured on a third-party platform must show the registered brand as the party the consumer agreed to hear from.
A campaign's opt-in evidence must all come from the registered brand, not from subsidiaries, franchises or client brands.
On a platform offering no evidence upload, every artifact must be reachable from a public URL written into the message-flow text.
A campaign declaring sub-use cases must carry at least one sample message for each of them.
The campaign must carry at least the number of sample messages its use case requires.
Restricted use cases must only be selected by the entity types eligible for them.
On a CSP whose API accepts only true for the subscriber opt-in, opt-out and help attributes, none of the three may be submitted false.
Where the provider ties the two fields together, declaring subscriberOptin true requires optinKeywords to be populated.
Where the platform publishes a wider standard opt-out set, the declared keywords must cover HALT and STOPALL as well as the universal five.
A campaign declaring affiliate marketing — sharing opt-ins with, or promoting, third parties — is rejected.
The campaign description must be at least 40 and at most 4096 characters.
No campaign registration field may contain an emoji character.
The opt-in / message-flow field must be at least 40 and at most 2049 characters.
All URLs in the registration must use https://; plain http:// is rejected.
Opt-out and help keyword lists must contain only alphanumeric keywords and must not exceed 255 characters.
The embeddedLink attribute must be true when any sample contains a URL, and a sample must contain a URL when it is declared true.
No registration field may contain lorem-ipsum, obvious placeholder text, or unreplaced template tokens.
A campaign must carry at least two, and at most five, sample messages.
Every sample message must be at least 20 and at most 1024 characters.
The declared use case must be one of the recognised TCR use-case values.
The registration contact email and phone number must not contain spaces anywhere.
A campaign declaring embedded links must supply the example link, at most 255 characters and at most fifteen entries.
The campaign description must disclose the messaging frequency.
Where the campaign solicits donations, the description must state that donations are collected.
A campaign may not describe itself as sending emergency or public-safety alerts unless EMERGENCY is declared and genuinely applies.
A campaign whose business performs first-party lending must contain the literal phrase "Direct Lending" in its description.
Where the brand website is not yet published, the description must say so explicitly.
Where the registrant is a platform registering a direct offering of its own, the description must state that explicitly.
Opt-in methods selected on the registration must be methods the brand genuinely uses; unused selections must be deselected.
Hosted evidence URLs must stay reachable for the life of the campaign, not only until it is approved.
Any URL referenced inside the message-flow text must also be supplied in the structured link fields.
The CTA disclosure text must appear inside the registration itself even when it is also published on the website.
A screenshot or artifact is required for EACH opt-in method declared, not one artifact covering the set.
A point-of-sale opt-in must supply a hosted photo of the signage, kiosk or tablet screen carrying the disclosure.
Where the opt-in is solicited by email, a screenshot of that email must be supplied.
Where the opt-in is presented in a pop-up or modal, the message flow must say so.
A screenshot submitted as opt-in evidence must show the Terms and Privacy Policy links as the consumer sees them.
Where consent is collected across several screens, evidence must show each step rather than the final one.
Where the opt-in sits behind a login, is unpublished, is spoken, or is on paper, the submission must say so explicitly.
Evidence must reach the reviewer through the channel the submission target provides, whether an upload field, a TCR attachment, or a URL inside the flow.
The opt-in, opt-out and HELP reply messages must each be 20–320 characters.
The embeddedPhone attribute must be true when any sample contains a phone number, and vice versa.
Sample messages must be materially different from one another.
The privacy policy URL and the terms of service URL must not be the same page.
The HELP and opt-out reply bodies should each fit within 160 characters.
Keyword lists must be comma-separated with no space around the individual entries.
Conditionally-allowed fields must not be populated when they do not apply to the chosen registration type.
The campaign reference id must be at most 50 characters, and unique within the CSP.
The campaign description must not contain individual names, account numbers or other personal data.
Where the website is geo-restricted so a US reviewer cannot open it, the description must disclose that and attach a screenshot.
Opt-out keywords outside the standard monitored set are handled by the sending platform alone and must not be relied on as carrier-enforced.
The privacy policy and terms links must each be at most 255 characters.
A campaign whose traffic does not need 10DLC should be told that toll-free or another channel fits it better.
Evidence fields that do not apply must be omitted rather than filled with filler text.
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.