Skip to content
A2PCheck

A2P 10DLC rejection reasons — why Twilio / TCR campaigns get rejected

Most A2P 10DLC rejections are not mysterious. They usually trace back to one of six campaign-packet problems: vague description, weak sample messages, missing consent evidence, privacy-policy gaps, forbidden content, or URLs that don't support the story. Use this hub to map the rejection to the fix before you resubmit.

Guidance only — A2PCheck is independent and not affiliated with Twilio, The Campaign Registry, or any carrier, and we can't guarantee approval.

Free — no signup required

Find likely rejection reasons in your campaign

Paste the campaign details you plan to submit or resubmit. A2PCheck checks for common A2P 10DLC rejection patterns across description, samples, opt-in, privacy, and URLs. Free, no signup.

Independent pre-submission check
No Twilio or TCR submission
Use campaign metadata, not customer PII

Use representative templates and public URLs only. Do not paste real customer phone numbers, customer records, API keys, or internal/signed URLs.

New here? Try a realistic example

Load a complete, carrier-friendly campaign to scan in one click — then tweak it for your own.

01

Campaign Info

Basic details about your messaging campaign.

0 characters — Too short — describe who opts in, what you send, and how often.

02

Sample Messages

Provide at least 2 example messages you'll send.

STOP foundHELP foundchecked across your keywords & messages
03

Opt-In / Message Flow

How users consent to receive your messages.

Consent evidence readiness

Describe where and how subscribers consent — name the opt-in location and the consent language they agree to.

  • Name the opt-in location (web form, checkout, keyword, QR code, paper form, etc.).
  • Spell out the consent language — what the subscriber explicitly agrees to.
  • State the message frequency (e.g. recurring, varies, msgs/month).
  • Include a "Message and data rates may apply" disclosure.
  • Link a privacy policy describing how you handle subscriber data.
  • Clarify that consent isn't a condition of purchase, where that applies.
  • Capture and retain opt-in evidence (timestamp, source URL, exact consent text/screenshot) for each subscriber.

Guidance only — consent requirements can vary by use case and jurisdiction.

or sign up to run a Full scan

Quick triage: match the rejection to a fix

Reviewer says opt-in, consent, or message flow is unclearQuote the exact consent language, URL, checkbox/keyword flow, frequency, STOP/HELP, and policy links.Samples are generic, missing STOP/HELP, or don't match use caseRewrite samples as real sends with brand identity, opt-out/help wording, and specific content.Privacy policy is missing, generic, or does not mention SMSPublish SMS-specific privacy language and no-sale/no-sharing language for phone numbers.Campaign description is too vague or internally inconsistentExplain audience, message purpose, content, frequency, and consent path in one coherent story.Content appears prohibited, restricted, or misclassifiedConfirm the use case is allowed, remove prohibited content, and set content flags honestly.Website, opt-in URL, privacy URL, or brand does not matchMake every URL public, crawlable, brand-consistent, and visibly connected to the campaign.

Rejection-reason guides

Campaign description rejectionThe campaign narrative is too generic, internally inconsistent, or missing the concrete details that connect your business, audience, use case, samples, and opt-in flow.Sample message rejectionThe submitted examples do not prove compliant, expected traffic: missing brand identity, no STOP/HELP language where needed, vague placeholders, mismatched use case, or risky links/phone numbers.Opt-in / consent rejectionThe consent path is missing, too vague, not publicly verifiable, or does not include the disclosures reviewers expect before someone receives SMS/MMS.Privacy policy rejectionThe privacy URL does not return a public, relevant policy with SMS-specific language and no-sale/no-sharing disclosures for phone numbers collected for messaging.Forbidden content rejectionReviewers saw content signals associated with prohibited categories, high-risk regulated offers, age-gated content, lending, misleading affiliate traffic, or another content type your provider/carriers do not permit for the selected route.Website mismatch rejectionThe reviewer could not verify the business, brand, opt-in flow, privacy policy, or message purpose from the URLs in the submission.

Official references

Use official provider documentation for submission mechanics and policy boundaries. A2PCheck is an independent pre-scan layer for the campaign packet you plan to submit.

What to do before resubmitting

Do not only edit the one sentence mentioned in the rejection. First, repair the category above. Then walk the resubmission checklist and run the updated campaign through the scanner. If you submit through a provider portal, use the relevant provider checker as a final pre-flight.

Frequently asked questions

What are the most common A2P 10DLC rejection reasons?

The most common patterns are vague campaign descriptions, sample messages that do not look like real sends, missing opt-in/consent evidence, weak privacy-policy disclosures, prohibited or restricted content, and public URLs that are broken, gated, or inconsistent with the campaign.

Does the rejection reason tell me the only thing to fix?

No. Treat the cited reason as the first clue. Carriers re-review the full campaign packet, so fix the category that was flagged and then re-check description, samples, opt-in evidence, privacy policy, terms, and website URLs together.

Is A2PCheck affiliated with Twilio or TCR?

No. A2PCheck is independent and is not affiliated with Twilio, The Campaign Registry, or any carrier. It helps identify common readiness issues but cannot guarantee approval.

Scan my rejected campaignResubmission checklist