CTA and opt-in rejections
About a 2-3 minute read.
Opt-in problems are the single most common rejection category. The good news: most of them are a wording fix on the campaign or a small change to your website, not a structural rebuild.
If you haven't read Write a CTA that passes, start there. This guide is for when you've already filed and the carriers sent back an opt-in-related reason. For how the reason reaches you, see How rejections work.
The shapes an opt-in rejection takes
Almost every one falls into one of these patterns. Find yours, then apply the fix.
The opt-in isn't described, or it's too vague
What it means: the "how recipients opt in" field doesn't clearly say how a person consents. Either nothing concrete was provided, or it's too general to evaluate.
The fix: pick the one mechanism you actually use, web form, keyword, in-person, or phone, and describe it specifically. For a web form, include the exact URL of the page with the form. For a keyword, include the keyword and the number it's sent to. See Write a CTA that passes.
The opt-in URL is missing, broken, or has no form on it
What it means: you didn't supply a URL where one was needed, the link doesn't load (or has a certificate error), or the page it points to doesn't actually contain the opt-in form.
The fix:
- Link directly to the page with the form, not a homepage where it's buried.
- Test the URL in a private/incognito window. A 404 or "can't be reached" means the link is wrong or the page isn't published yet.
- Fix any SSL/certificate error, reviewers won't accept HTTPS warnings.
If the opt-in lives behind a login or inside an app where a logged-out visitor can't see the form, explain that in the opt-in field and provide screenshots of the in-app flow to support.
The web opt-in form is missing required disclosures
What it means: the page at your opt-in URL is missing one or more of the elements carriers expect, brand name, what you send, frequency, "msg & data rates may apply," HELP info, STOP info, and links to your privacy policy and terms.
The fix: edit the page to add what's missing. Common gaps:
- A phone-number field with no consent text beside it, add the consent paragraph.
- HELP/STOP present, but no "message frequency varies; msg & data rates may apply" line.
- No inline links to the privacy policy and terms, add them.
Because this fix is on your website, you usually don't need a campaign change, once the page is live, contact support to have the campaign re-filed against the corrected page. See Opt-in, opt-out, and HELP.
The verbal opt-in script is incomplete
What it means: you collect consent by phone or in person, but the script you provided is missing required elements (or no script was attached).
The fix: write a fuller script so every disclosure is spoken before the person consents. Something like:
"Before we wrap up, would you like to receive text messages from Example Co? We'll send appointment reminders and occasional offers, typically 2 to 4 messages a month. Message and data rates may apply. Reply STOP any time to opt out, or HELP for support. We don't share your number with anyone else for marketing. Our privacy policy is at example.com/privacy. Do you consent to receiving these messages?"
Provide the script to support so it can be filed with the campaign.
Less common opt-in rejections
Forced or pre-checked consent
What it means: your form makes SMS consent mandatory or pre-checks the consent box. Carriers require active, optional consent.
The fix: make the SMS opt-in box unchecked by default and allow the form to submit without it. The phone-number field can still be required for other purposes, but consent to text has to be separable from everything else.
The opt-in language doesn't match the use case
What it means: your opt-in or samples describe promotional content, but Marketing isn't one of your selected use cases (or the reverse).
The fix: either remove the promotional language so it matches a non-marketing use case, or move to a use case that includes marketing. Changing the use case is structural and means re-filing, AgentMessage handles that. See Pick a use case.
Consent described as court-ordered
What it means: the opt-in is described as obtained through a court order, which isn't a valid 10DLC consent mechanism.
The fix: if there's a normal consumer opt-in path (a form, a keyword), describe that instead. If a court order is the only basis for the messaging, 10DLC isn't a viable channel, carriers require consumer-initiated consent.
What's easy to fix vs. what means re-filing
Wording-level pieces, the opt-in description, the confirmation, the HELP and STOP replies, the samples, and the privacy policy and terms URLs, can be re-filed without rebuilding the campaign. The structural pieces, the use case and the content toggles (embedded links, embedded phone numbers, age-gated, direct lending), define the campaign at the registry, so changing one means re-creating it. AgentMessage handles both; contact support to push a fix back through.
After a fix
Expect a fresh round of review. If you don't address every issue from the original reason, the same fields can come back flagged, so re-read the full reason before asking for the re-file. If you've been through this loop more than once, see If you keep getting rejected.