A2P 10DLC campaign rejected: the real reasons — and how to fix each one

What a rejection actually means

A rejection means the carrier registry's vetting — automated checks, human reviewers, or both — looked at your campaign submission, and often at your live website, and found something that didn't check out. It is not a ban and it is not final: campaigns are rejected and then approved on resubmission every day, once the real problem is fixed. The cost of leaving it rejected is real, though — until it's approved, carriers treat you as unregistered, with all the silent filtering that does to your texts.

The frustrating part is the feedback. Rejections come back as terse reason codes — on Twilio you'll see errors like 30886 or 30882 — with official descriptions vague enough to be useless. "Terms and conditions" as a rejection reason could mean six different things. This guide decodes what reviewers actually check behind each rejection, from a playbook built taking a maximum-scrutiny client — a California mortgage brokerage — through rejection and resubmission to a verified campaign.

One mindset shift before the list: the reviewer's job is to confirm a real business is texting real customers who really agreed to it. Every rejection below is a failure to prove one of those three things.

Reason 1: your campaign description is vague

The single most common rejection is a campaign description that reads like marketing copy instead of a factual account of who texts whom, and why. Reviewers reject descriptions that don't let them picture the actual messages: "we engage our customers with timely updates" tells them nothing.

On Twilio this often surfaces as error 30886 (invalid campaign description). The fix is to rewrite the description as plain, concrete fact:

The test to write toward: could a reviewer verify every sentence of your description against your live website in two minutes?

• Who sends: your business, named exactly as registered.
• Who receives: customers or prospects who contacted you and opted in — say where (your website, your intake form).
• What the messages are: follow-ups about their own inquiry, appointment reminders, status updates — whatever is literally true for you.
• What you don't do: if your industry attracts scrutiny, say explicitly that you don't send affiliate or third-party marketing messages.

Reason 2: your consent language is missing required pieces

Carrier reviewers expect the consent language at your opt-in point to contain a specific set of elements, and omitting any of them is grounds for rejection. On Twilio this family of problems tends to come back as error 30882.

Check your opt-in language against this list:

Two extra traps here: placeholder URLs — a submission pointing at example.com instead of your real policy pages is an instant rejection — and inconsistency: if the live checkbox and your campaign submission quote different wording, the mismatch is itself a red flag. Every opt-in point should carry the same consent text, word for word. (The full registration checklist walks the complete consent flow element by element.)

• Your business name, so the customer knows who they're agreeing to hear from.
• What kinds of messages they'll get (follow-up about their inquiry, reminders, updates).
• "Message and data rates may apply" and a note that message frequency varies.
• How to opt out and get help: "Reply STOP to opt out, HELP for help."
• That consent is not a condition of purchase, and is specific to this program — not bundled into some broader agreement.
• Links to your privacy policy and terms — real, working URLs, on the page where consent happens.

Reason 3: the reviewer couldn't find your opt-in

Reviewers manually visit your website and try to find the consent checkbox you described. If they can't reach it, the campaign is rejected — even if the checkbox genuinely exists.

On Twilio this shows up as error 30896 (opt-in information rejected). The classic way to fail it: your consent checkbox lives inside a JavaScript widget — a chat launcher, a popup, an embedded booking tool — that a reviewer skimming your page HTML never opens. We hit exactly this one: the consent flow lived inside a website widget, and the fix was putting an ordinary consent checkbox — unchecked by default — in plain page HTML on a normal page of the site.

The fix checklist:

1. Put the consent checkbox in static, crawlable HTML — visible in view-source, not rendered only after a script runs.
2. Keep it unchecked by default; pre-checked boxes don't count as consent.
3. In the campaign's opt-in description, quote the checkbox text verbatim and tell the reviewer exactly which page it's on and how to find it.
4. Attach a screenshot of the real checkbox on the real page.

Reason 4: your privacy policy contradicts your campaign

Reviewers read your live privacy policy, and if it says anything that contradicts your SMS promises, the campaign is rejected — most often for third-party data-sharing language. Your campaign says "we don't share mobile information for marketing," while the boilerplate privacy policy your old website shipped with says you share data with "marketing partners." The reviewer believes the policy.

The fix is on your website, not in the campaign form:

• Remove or rewrite any language about sharing customer data with third parties or affiliates for marketing purposes.
• Add an explicit clause that mobile numbers and SMS consent are not sold or shared with third parties for marketing. Sharing needed to actually serve the customer (payment processors, your messaging provider) is fine — say so plainly.
• Deploy the fix and confirm the live page shows it before you resubmit. Reviewers check the live site, not your intentions.

Reason 5: your brand and campaign don't match

The reviewer checks that the name sending the texts, the name on the website, and the legal entity registered as the brand all line up — and rejects when they don't. This one hits businesses operating under a DBA hardest: the brand is registered to the legal entity, the website and sample messages carry the trade name, and to a reviewer that gap looks like third-party or affiliate traffic.

The fix is to close the gap explicitly:

• In the campaign description, state the link: "TradeName, a registered DBA of LegalEntity, Inc."
• Make sure your website footer shows the same relationship, so the reviewer can verify it.
• Use one consistent business name in your sample messages — the name customers actually see.

Reason 6: your sample messages don't add up

Sample messages get rejected when they don't match the use case you described, or when they're missing the required opt-out language. If your description says "appointment reminders" and your samples read like promotional blasts, that inconsistency reads as deception even when it's just sloppiness.

Make your samples boring and true: real messages you'd actually send, one per genuine use, each ending with "Reply STOP to opt out, HELP for help." And answer the campaign's attribute questions honestly — if your messages include phone numbers or links, say so; claiming otherwise while sampling a message with a link in it is a rejection. Automated senders follow the same rule: if your texts come from an AI receptionist texting back missed callers or an automated follow-up system, describe that plainly and sample the real automated messages — reviewers approve honest automation every day.

Reason 7: restricted content

Some content categories are restricted or prohibited outright in A2P messaging, and campaigns touching them get rejected regardless of how clean the paperwork is. Carriers publish lists that include things like cannabis, firearms sales, and certain high-risk financial offers; other regulated areas — lending, insurance, healthcare — are allowed but reviewed with extra scrutiny.

In a regulated-but-allowed vertical, the fix is precision: describe the use case exactly, keep promotional claims out of the samples, and expect a longer review. If your category is genuinely prohibited, no registration service can honestly promise approval — be suspicious of anyone who does.

How to resubmit: edit, don't start over

Fix the real problems first — on your website and in the campaign fields — then edit the rejected campaign and resubmit it. Editing keeps your campaign and its review history intact; deleting and re-registering from scratch throws that away for no benefit, and re-vetting an approved brand is self-inflicted delay. (Edit-and-resubmit is exactly how our maximum-scrutiny client reached verified status.)

The order of operations that works:

If you'd rather not burn review cycles learning each code the hard way, this decode-fix-resubmit loop is the core of our A2P registration and setup service — we correct from a map, not by guessing. Related reading: why business texts stop delivering in the first place and the full registration checklist to pass on the first try. Not sure the campaign is your only leak? The $75 audit checks the whole funnel.

1. Decode every reason on the rejection — there are often two problems at once, and fixing only one earns you another rejection cycle.
2. Fix the website first: consent checkbox in plain HTML, consent language complete, privacy policy contradictions removed. Deploy and verify the live pages.
3. Fix the campaign fields: description, consent URLs, samples, attribute flags.
4. Edit the existing rejected campaign, resubmit, and wait out the review — typically days, longer under backlog.