10DLC Campaign Rejected
TCR rejection feedback is almost always too vague to act on. "Use case mismatch" and "opt-in issue" don't tell you what to fix — they tell you something was flagged. Here's what those rejections actually mean and what needs to change before you resubmit.
The four real rejection causes
TCR reviewers check the campaign type, use case description, sample messages, opt-in documentation, and website content together. A mismatch anywhere across those five things gets flagged.
The campaign type you selected doesn't match the use case description. A marketing campaign described in vague terms, a use case that contradicts what the sample messages show, or a campaign type that doesn't fit the actual messaging purpose — reviewers catch all of these. The fix is getting the campaign type, description, and sample messages to tell the same story.
The opt-in form doesn't include required disclosure language. The privacy policy doesn't reference SMS. Consent is implied rather than explicit. Pre-checked boxes were used. Any one of these will cause a rejection — and they often appear together. Every opt-in point needs to state clearly what the user is consenting to, who is sending the messages, and how to opt out.
The website describes a different use case than the campaign submission. The privacy policy has no SMS language. The opt-in form and the campaign description disagree on what type of messages will be sent. Reviewers check the website against the campaign claim — if they don't match, the campaign gets flagged regardless of how clean the submission itself is.
Sample messages include content TCR won't approve — unapproved marketing language, missing opt-out instructions, references to prohibited content categories, or messages that don't match the stated use case. Sample messages are reviewed against the campaign type and the use case description. All three have to be consistent.
Decoding the feedback
TCR rejection feedback is written to identify a category, not a specific fix. Here's what the most common rejection reasons are pointing to.
Get your rejection reviewedThe campaign type, use case description, and sample messages don't align. Start by checking whether the campaign type actually fits the messaging purpose, then verify that the description and samples are consistent with each other.
The opt-in flow is missing required elements — disclosure language, SMS-specific privacy policy reference, or explicit consent capture. Pre-checked boxes and implied consent are not accepted.
The website doesn't support the campaign claim. The privacy policy lacks SMS language, the opt-in form is missing disclosures, or the site describes a different use case than what was submitted.
One or more sample messages include prohibited content, missing opt-out language, or content that doesn't match the campaign type. All sample messages need to reflect what will actually be sent and include proper opt-out instructions.
The resubmission trap
Every resubmission adds days or weeks to your timeline. The fastest path through is identifying the actual rejection cause before making any changes, then fixing that specific issue before resubmitting. A faster resubmission of a broken campaign is still a broken campaign.
Rejection feedback points to a category, not a fix. The specific gap needs to be identified before anything is changed.
Use case, opt-in, website, or sample messages — each requires a different correction. Fixing the wrong thing wastes a resubmission cycle.
Confirm the correction actually closes the gap TCR flagged. A resubmission that doesn't address the rejection reason will be rejected again.
A complete, accurate submission moves faster through review than a partial one. Every missing piece is a reason to slow down or reject.
How a rejection review works
Send the rejection feedback, campaign submission, website URL, and any TCR correspondence. The review identifies the specific cause and maps out exactly what needs to change before resubmission.
See the full processSend the TCR rejection reason, the campaign submission, and the website URL. The review starts from there and ends with specific corrections — not a generic checklist.