If there is one section of this Knowledge Center that I expect to be read more than any other, it’s this one. Campaign rejections are the single most common pain point in 10DLC, and they are also the single most fixable one once you understand what is going on.

Here is the frustrating truth about rejections: most of them are avoidable. The campaigns that get rejected are usually rejected because someone filled out a form incorrectly, did not provide enough detail, did not realize their messaging had an attribute that triggered a special review, or registered the wrong use case for what they actually intend to send.

The good news: once you know the patterns, you stop hitting them.

This section is written from the perspective of a DCA. We see what flows through us, what the carriers accept, what the carriers reject, and what patterns recur across thousands of campaigns from many different CSPs. The patterns below are the ones we see most often.

A note on terminology

When I say "rejection," I am using the word loosely to cover several different outcomes that all feel similar from the customer's perspective:

• The Brand fails identity verification at TCR.

• The Campaign is rejected by the CNP, DCA, or carrier during review.

• The Campaign is accepted but then suspended or blocked after going live.

• The Campaign was technically accepted but receives a vetting score so low that throughput is functionally unusable.

These are different things mechanically. They happen at different layers, for different reasons. From where you are sitting they all feel like "the system told me no." This section addresses all of them.

Pattern 1: The Brand information does not match the tax record

This is, by some distance, the most common reason brands fail identity verification.

The 10DLC framework requires the Brand's legal company name, EIN (or equivalent tax ID), and registered address to match what is on file with the issuing tax authority. The verification system queries those authorities and looks for a match.

When verification fails, the simplest path forward is to confirm the Brand details against the official tax record (the IRS confirmation letter for U.S. companies, the equivalent for international entities) and resubmit. If the resubmission also fails, an appeal can be filed with supporting documentation.

The takeaway from the DCA perspective: do not assume the system will be flexible with naming variations. Match the tax record exactly. The minutes you spend confirming the Brand details upfront save days of back-and-forth later.

Pattern 2: The Campaign description is too vague

This is the most common reason for Campaign rejections, as opposed to Brand rejections.

When you register a Campaign, you have to provide a Campaign Description. Most CSPs have a free-text box and a couple of sentences of guidance. People often interpret this as "fill this in with whatever quick description fits." That is a mistake.

The Campaign Description is the primary document that the DCA and the carriers use to evaluate whether your campaign is what it claims to be. A two-sentence description like "Marketing messages to our customers" tells us almost nothing. We do not know what kind of business you are, what kind of products you sell, how you collected the consents you are claiming, what the messages will actually look like in practice, or what the consumer experience will be.

A good Campaign Description tells us:

• Who the Brand is and what they do.

• Who the audience is. The consumers who will receive these messages, and how they came to be on the list.

• How those consumers opted in to messaging. The specific mechanism, like a checkbox at checkout, or a text-to-join keyword on a poster, or a verbal opt-in during onboarding.

• What the messages will be about. Categories of content, frequency expectations, examples of typical messaging.

• Anything special about the campaign. Embedded links, age-gated content, references to other services.

A solid Campaign Description is a paragraph or two. It usually takes 5 to 10 minutes longer to write than a quick one-liner. Those minutes save days of rejection back-and-forth.

Pattern 3: The sample messages do not match the use case

Every campaign requires sample messages. These are examples of what consumers will receive. Some use cases require one sample, others require two or more. The samples are the most concrete evidence we have of what the campaign does.

What we see when reviews go wrong:

The samples are placeholder text. Reviewers see "Hi customer, here is an update from us" with depressing regularity. These get rejected. Use real examples that look like real production messages.

The samples do not include the brand name. This is one of the most consistently flagged issues. Carrier guidance is clear that consumers should be able to recognize who sent a message. If your Brand is Acme Plumbing and your sample message is "Your appointment is confirmed for Tuesday at 2pm. Reply Y to confirm," there is no way for the consumer or the reviewer to tell who that message is from. A better version: "Acme Plumbing: Your appointment is confirmed for Tuesday at 2pm. Reply Y to confirm. STOP to opt out."

The samples do not include opt-out language. Most campaign types require opt-out instructions in at least some of the messages, and the absence of "Reply STOP to opt out" or equivalent is a common flag.

The samples do not match the use case. We have reviewed campaigns registered as "Account Notifications" with sample messages that are clearly marketing. Campaigns registered as "2FA" with sample messages that look like delivery notifications. The use case has to match what is being sent. If you are going to send mixed content, register the Mixed-use case (or Low Volume Mixed for smaller volumes).

The samples include public URL shorteners. Public URL shorteners are not allowed in 10DLC content. The carriers and aggregators flag them because phishing operations use them to obscure malicious destinations. Use your own branded short domain or full URLs.

Pattern 4: The opt-in flow is missing or implausible

Every Campaign that contacts consumers require consumer opt-in. The only meaningful exception is Machine-to-Machine (M2M) campaigns, where there is no human consumer involved.

The opt-in field, usually labeled "Call to Action" or "Message Flow" in the CSP portals, is where you describe how consumers came to be on your messaging list. This is one of the most-scrutinized fields in the entire registration, because consent is the legal and ethical foundation of the whole system.

What gets rejected:

Vague opt-in descriptions. "Customers opt in" tells us nothing. We need to know how, where, and what they were told they were opting into.

Missing the required disclosures. The opt-in description should include the brand name, a description of the messages, message frequency disclosure for recurring campaigns, "message and data rates may apply," and how to get help (HELP) and stop (STOP). If the opt-in language does not include these elements, the Campaign is non-compliant on its face.

Implausible opt-in stories. We have seen Campaign Descriptions claim that consumers opted in via a website that does not have an opt-in form. Or claim opt-ins via a paper form that the brand cannot produce. Or claim opt-ins from years ago for a brand that is only six months old. Reviewers will check websites, look for the opt-in mechanism, and flag mismatches.

Purchased or shared opt-in lists. This is a flat prohibition. Opt-ins from lists rented, sold, or shared from other senders are not valid for 10DLC campaigns. Each Brand has to collect its own opt-ins for its own campaigns.

If you can take a screenshot of your actual opt-in page or attach a copy of your actual opt-in script, do it. The campaigns that get approved most quickly are the ones where the opt-in evidence is concrete and verifiable.

Pattern 5: The Brand picked the wrong use case

There are a couple dozen different use cases in the 10DLC framework. Each has its own rules, throughput allowances, approval requirements, and restrictions. If you pick the wrong one, the campaign either gets rejected outright or gets approved but does not perform the way you expected.

Common mistakes:

Picking "Marketing" for what is transactional. If the messages you are sending are appointment reminders, account alerts, delivery notifications, or 2FA codes, those have their own dedicated use cases. Registering them as Marketing is wrong, and you will often get rejected because Marketing has stricter consent requirements than the transactional use cases do.

Picking "Mixed" when the volume is low. If you have a small business sending a mix of message types and the total volume is low, Low Volume Mixed is usually the right choice. Mixed (without "Low Volume") has different requirements and is not always appropriate for small operations.

Not picking a Special use case when one applies. If you are a charity, register as Charity. If you are an agents-and-franchises model, register that way. If you are sending political campaign messaging, that is a Special use case with its own requirements. Trying to fit a Special use case into a Standard one almost always results in rejection.

The use case cannot be changed after registration. Once a campaign is registered, the use case is locked. To change it, you have to deactivate the campaign and register a new one. There is no shortcut.

Pattern 6: The campaign is technically registered but the numbers are not associated

This is a different kind of "rejection." The campaign was approved, but messages are still not going through, because the phone numbers have not been properly associated with the campaign in the routing system (the nnSR).

Registering a campaign in TCR is necessary but not sufficient. The phone numbers you intend to use for that campaign also need to be associated to that campaign in the nnSR. If your CSP handles that automatically, great. If not, someone has to do it.

Symptoms of unassociated numbers: the campaign shows as Active in TCR, but messages from those numbers are being treated as unregistered traffic by the carriers. They get throttled to lower throughput rates. They may get blocked entirely. The customer thinks something is wrong with the campaign when the issue is one layer down at the routing level.

If your campaign looks fine in TCR but messages are not delivering at the throughput you expect, the next thing to check is whether the numbers are properly associated in the routing layer. This is one of the most common second-order issues we see.

Pattern 7: The content drifted from the registration

Even after a campaign is approved and traffic is flowing, it can be suspended or blocked later if the actual content being sent drifts away from what was registered.

The carriers and DCAs monitor traffic patterns. If a campaign was registered for Account Notifications but starts sending what looks like marketing messages, that is content drift. If the sample messages registered showed transactional content but the live traffic includes promotional offers and embedded links to checkout pages, that is content drift. If the Campaign Description claimed one frequency and the live traffic is sending five times that frequency, that is content drift.

Content drift triggers compliance reviews. Those reviews can result in campaign suspensions.

The fix is simple: keep what you actually send aligned with what you registered. If your messaging strategy changes, register new campaigns for new use cases, content types or frequency that fall outside of what you originally declared. Do not let registered campaigns silently morph into something different from what was approved.

What to do when your campaign is rejected

When a campaign is rejected, you usually get a reason. Sometimes the reason is terse, generic, or technical. Syniverse provides error codes and explanations that help diagnose the cause. Here is the order I would troubleshoot in:

1. Read the rejection reason carefully. The most common reasons map directly to the patterns above. The fix is often clearly indicated.

2. Re-read the Campaign Description with fresh eyes. Ask yourself: if I were a stranger reading this, would I know what this business does, who they are texting, why, and how those people consented? If not, expand it.

3. Audit your sample messages. Are they real? Do they include the brand name? Do they have opt-out language where required? Do they match the use case?

4. Verify the opt-in flow is documented and verifiable. Take screenshots. Save the actual opt-in language. Be ready to defend it.

5. Confirm the use case is right. If there is any chance you picked the wrong one, fix that, even if it means deactivating and re-registering.

6. If the rejection persists after all of the above, ask your CSP to escalate. Some rejections happen at the DCA or carrier level for reasons that are not visible in the CSP portal. Aggregators like Syniverse can sometimes provide context that the CSP does not have direct visibility into.

The honest summary

Most campaign rejections come from a small number of repeatable causes. None of those causes are mysterious once you know to look for them. The 10DLC system is not trying to keep good actors out. It is trying to keep bad actors out, and the friction you are feeling is mostly a side effect of that.

Take the registration process seriously. Treat the Campaign Description like it matters, because it does. Make your sample messages real. Make your opt-in flow defensible. Pick the right use case. Keep your live traffic aligned with what you registered.

Do those things and your rejection rate drops to near zero. Skip them and you will keep hitting the same walls.

RELATED SECTIONS

• The 10DLC Ecosystem: Who Does What

• Spam, Phishing, and What We See at the Network Layer