- July 26,2026
- 20 days ago
A 10DLC submission is not approved simply because every field in the registration form is filled out. Reviewers need to determine whether the business is legitimate, the messaging use case is clear, consumers knowingly consent to receive the messages, and the proposed traffic matches carrier requirements.
That distinction matters.
A technically complete submission can still fail when the legal company name does not match the EIN, the opt-in process cannot be verified, sample messages do not match the stated use case, or the website tells a different story from the campaign application.
The Campaign Registry performs brand identity checks, while campaign vetting can also involve downstream Direct Connect Aggregators and carrier requirements. Current industry guidance shows that legal business information, campaign details, consent flows, sample messages, privacy policies, terms, and the company's online presence can all affect review.
For teams using Text Torrent, which provides free A2P 10DLC registration and does not charge a monthly fee for its 10DLC service, TextTorrent's guided 10DLC setup Process, the objective should therefore be broader than completing registration fields. The entire submission should tell one consistent, verifiable story about who is sending, why messages are being sent, how recipients opted in, and what they will actually receive.
This is especially important for teams running bulk messaging campaigns, where the approved use case needs to remain consistent with the traffic that eventually leaves the platform. Businesses should also understand why 10DLC is required before treating registration as a simple administrative step.
For compliance-sensitive industries such as insurance or businesses using SMS for promotions, reminders, customer service, and operational communication, that consistency should be established before the campaign is submitted—not after the first rejection.
Here is what reviewers are actually looking for.
The first question is straightforward:
Who is actually sending these messages?
Brand registration connects messaging traffic to a real organization. The Campaign Registry's identity process checks information including the EIN or Tax ID, legal company name, and legal company address. TCR specifically notes that typos and outdated information can affect the verification outcome.
This is why seemingly minor business-information mistakes can stop a submission before the messaging strategy itself becomes relevant.
Your submission should contain accurate information for items such as:
Legal business name
EIN or applicable Tax ID
Legal business address
Business website
Support contact information
Business entity information
The critical word is legal.
If "Northstar Funding LLC" is the entity attached to the EIN, submitting "Northstar Capital" simply because that is the customer-facing brand can create a verification problem.
Teams often:
Submit a DBA instead of the legal entity
Omit part of the registered company name
Enter an outdated address
Use information belonging to a related company
Mistype the EIN
Submit a website that does not clearly connect to the registered organization
Do not improvise business identity information.
Before submitting, compare the registration details against the company's official tax documentation and current business records.
After determining who you are, reviewers need to understand what you intend to send.
"Customer communication" is not particularly useful.
Neither is:
We send messages to customers.
A reviewer needs enough information to understand the expected traffic.
A stronger campaign description might explain that an MCA (Merchant Cash Advance) agency sends opted-in customers appointment reminders, funding status updates, requested application or quote follow-ups, and customer-service messages.
The difference is specificity.
Who receives the messages?
Why are they receiving them?
What types of messages will be sent?
How did those recipients provide consent?
Is the traffic promotional, conversational, informational, or mixed?
The description should also agree with the use-case category selected during registration.
Bandwidth's current registration guidance specifically identifies campaign descriptions, content attributes, sample messages, opt-out information, and call-to-action information among the fields reviewed during campaign vetting.
The reviewer has to infer what your business intends to do.
That creates unnecessary risk.
If the selected use case says customer care, the description suggests marketing, and the samples look like lead-generation messages, the submission no longer presents a coherent campaign.
A useful rule is:
A reviewer should be able to understand the campaign without researching your business to figure out what you meant.
Consent is one of the most important parts of the submission.
Carriers do not only want a statement saying:
Customers opt in.
They need to understand how.
Bandwidth identifies insufficient call-to-action or message-flow information as a common campaign rejection reason. Its guidance recommends describing the actual mechanism, such as a website form, keyword, point of sale, IVR, or another identifiable consent process.
Suppose customers enter their phone number on a quote form.
The registration should explain:
Where the form is located.
What action the customer takes.
What SMS disclosure appears near the phone field.
Whether the SMS checkbox is optional.
What type of messages the customer agrees to receive.
Where the privacy policy and terms are available.
If the form is publicly accessible, provide the actual page rather than sending reviewers to a generic homepage.
A particularly important issue is forced consent.
For web and app flows, consumers should not have to accept marketing SMS simply to complete an unrelated transaction. Twilio's current campaign rejection guidance specifically identifies preselected checkboxes, mandatory SMS consent, and consent bundled with required terms or policies as potential rejection causes.
For example:
Poor implementation:
"By submitting this form, you agree to receive promotional text messages."
There is no meaningful choice.
Better implementation:
An unchecked SMS consent box is displayed separately from the form's required submission action, with the relevant messaging disclosure available to the user.
The exact legal requirements can depend on the use case, so businesses should have their consent language reviewed for their circumstances rather than blindly copying another company's form.
Having a compliant process internally is not enough if the reviewer cannot verify it.
This problem frequently appears when consent happens:
Behind a login
Inside a mobile application
Through an internal CRM
Verbally
On a paper document
At a physical location
Through a private checkout process
Do not leave the reviewer guessing.
Explain the workflow.
If necessary, provide supporting information showing what the consumer sees and how consent is recorded.
For a verbal workflow, for example, describe when the representative asks for SMS permission, what disclosure is provided, and how that consent is recorded.
The operational principle is simple:
If the reviewer cannot see the opt-in directly, your explanation has to make the process independently understandable.
Sample messages are not filler.
They are evidence of what the campaign intends to send.
Current Twilio guidance requires sample messages to relate to the campaign description, identify the sender, use real functional websites when links are included, and indicate an opt-out mechanism.
Consider this sample:
Hello, we have an offer for you. Click here for more information.
It creates several questions.
Who sent it?
What kind of offer?
Why is the recipient receiving it?
Does it actually represent the registered campaign?
Compare it with:
Northstar Insurance: Your requested auto quote is ready for review. Reply STOP to opt out.
The second sample gives reviewers much more information about the expected traffic.
Recognizable sender identity
Actual message purpose
Realistic wording
Appropriate opt-out instructions
Content consistent with the campaign description
If variables will be used, show them clearly.
For example:
Northstar Dental: Reminder—your appointment is scheduled for [date] at [time]. Reply C to confirm or call [number] to reschedule. Reply STOP to opt out.
Do not submit generic samples just to complete the form and then send completely different traffic after approval.
One of the most useful ways to think about campaign review is as a consistency test.
Reviewers are not evaluating each field in isolation.
They can compare:
Business → Website → Use Case → Opt-In → Samples → Policies
Those pieces should agree.
Imagine a submission with:
Campaign description: appointment reminders.
Opt-in page: "Get weekly discounts and promotional offers."
Sample message: "Apply today and see how much funding you qualify for."
Those are three different stories.
Even if each individual field looks polished, the campaign is structurally inconsistent.
Before submission, ask:
If someone reviewed only our website, campaign description, consent flow, and sample messages, would they conclude that all four describe the same messaging program?
If the answer is no, fix the inconsistency first.
7. A Real, Functional Business Website
Your website is part of the verification surface.
Bandwidth specifically identifies a lack of a website or online presence as a potential campaign vetting issue.
Reviewers may use the website to understand:
What the company does
Whether the brand appears legitimate
Whether the domain matches the submitted business
Whether the claimed use case makes sense
Whether consent can be verified
Whether required policies are available
Whether restricted content is present
A polished registration attached to a broken, empty, inaccessible, or unrelated website creates unnecessary doubt.
Check the website technically too
Before submission, test:
HTTPS works correctly
Pages load without authentication
No maintenance page is active
Opt-in URLs work
Privacy policy loads
Terms and conditions load
Business identity is visible
Forms work on desktop and mobile
Important content is accessible without unusual browser behavior
Think beyond what you see in your own browser. A reviewer or automated verification system also needs to reach the relevant pages.
Privacy policies have become an increasingly important part of campaign review.
Bandwidth lists privacy-policy issues among common rejection reasons, while Twilio began requiring publicly accessible privacy-policy and terms-and-conditions URLs for new A2P 10DLC campaign submissions through its Messaging API on June 30, 2026.
A generic website privacy template may not be sufficient for every messaging program.
The policy should accurately describe the organization's real data practices, including how personal information related to messaging is handled.
Teams should pay particular attention to whether the policy's statements about phone numbers, consent information, data sharing, and messaging practices agree with the actual SMS program.
Do not add promises your business cannot operationally honor.
Terms and conditions are another place where copied templates create problems.
The messaging terms should describe the actual program rather than an imaginary one.
Depending on the campaign and applicable requirements, relevant disclosures may include:
Program or brand identification
Nature of the messaging program
Expected message frequency or frequency language
Message and data rate disclosure
HELP instructions
STOP or opt-out instructions
Support information
Links to applicable policies
The important part is consistency.
If your terms describe four promotional messages per month but your campaign application describes transactional appointment notifications, something needs to be reconciled.
Your website policies should support the registration rather than contradict it.
Consent does not last forever.
Consumers need a practical way to stop receiving messages.
Bandwidth's current vetting guidance identifies recognized opt-out terms such as STOP, END, UNSUBSCRIBE, and CANCEL, and recommends demonstrating opt-out language in sample traffic.
Keyword-based subscription flows may also require confirmation messages that identify the brand and explain HELP and opt-out behavior.
But registration language is only half the job.
Your production system has to honor it.
If your sample says "Reply STOP to unsubscribe" while your application continues sending to people after they reply STOP, the live traffic no longer matches the compliance model represented during registration.
That can become a deliverability and compliance problem even though the original campaign was approved.
10DLC approval is not permission to send any content a business wants.
Carriers and messaging providers restrict or prohibit certain categories of traffic.
Bandwidth's current vetting guidance, for example, identifies SHAFT-C categories—including certain sex, hate, alcohol, firearms, tobacco, cannabis/CBD-related content—as important areas of campaign review, with specific exceptions or additional requirements potentially applying to some categories.
Restrictions can extend beyond individual SMS messages.
Website content can matter too.
This is why businesses in regulated or higher-risk verticals should verify eligibility before building an SMS acquisition strategy around 10DLC.
Do not assume that obtaining consumer consent automatically makes a prohibited messaging use case acceptable.
Consent and carrier eligibility are separate questions.
12. Alignment Between Registration and Live Traffic
Campaign approval is not the end of carrier scrutiny.
Registration tells the ecosystem what traffic to expect.
Live messaging shows what you actually do.
Suppose you register:
Existing-customer appointment reminders.
Then you use those numbers for:
High-volume promotional outreach to newly acquired lead lists.
The traffic pattern no longer resembles the registered campaign.
That mismatch matters.
The safest operating principle is:
Register what you actually intend to send, then send what you registered.
If your business model changes materially, review whether the existing campaign registration still accurately represents the traffic before simply adding new message types.
Some teams assume a rejection means one field was "wrong."
Often, the real problem is ambiguity.
The reviewer could not establish enough confidence in the overall messaging program.
Typical examples include:
Correct EIN but inconsistent company name
Legitimate business but unclear website
Good samples but weak opt-in explanation
Strong consent language but inaccessible opt-in page
Valid use case but samples from another workflow
Privacy policy that does not support the messaging program
Terms that contradict the registration
Restricted content elsewhere on the business website
That is why repeatedly changing random fields after a rejection is usually a poor troubleshooting strategy.
Find the inconsistency first.
Before sending the registration for review, run the campaign through four checks.
Confirm that:
Legal business name matches official records
EIN or Tax ID is correct
Address is current
Website belongs to the business
Contact information works
Confirm that:
Every recipient enters through a legitimate opt-in path
The opt-in mechanism is described specifically
SMS consent is clearly disclosed
Web consent is voluntary where required
Checkboxes are not improperly preselected
The reviewer can inspect or understand the consent flow
Proof of consent can be retained
Confirm that:
The selected use case is accurate
Campaign description explains actual traffic
Samples resemble production messages
Brand identification appears appropriately
Opt-out language is included where required
Samples and description tell the same story
Confirm that:
Website loads publicly
Business identity is understandable
Opt-in pages work
Privacy policy is accessible
Terms are accessible
Messaging disclosures are visible where appropriate
The site does not contradict the registered use case
If one of these categories fails, fix it before submitting.
Do not immediately resubmit the same information.
First identify the rejection reason and trace it back to the underlying evidence.
If the rejection concerns the CTA, inspect the actual consent experience—not just the CTA paragraph you entered.
If the problem concerns sample messages, compare them against the campaign description and selected use case.
If the website is cited, check the website itself, including policy pages and the specific opt-in URL.
If identity verification fails, return to the underlying legal documentation.
Some vetting processes can also charge for additional review events, making repeated speculative resubmissions more than an inconvenience. Bandwidth, for example, currently warns customers to resolve all returned rejection reasons before resubmitting because additional vetting events can incur fees.
Fix the cause, not the wording around the cause.
10DLC Approval Does Not Guarantee Deliverability
This distinction is essential.
10DLC registration establishes the identity and declared purpose of the messaging program.
It does not make every future message trustworthy.
After approval, carriers can still evaluate live traffic signals and filter messages.
Poor consent practices, unexpected content, complaints, suspicious URLs, excessive opt-outs, traffic inconsistent with the registered campaign, or other risk signals can still cause problems.
So there are really two operating standards:
Before approval: make the campaign verifiable and internally consistent.
After approval: keep the live messaging consistent with what consumers agreed to receive and what the campaign was registered to send.
Teams running higher-volume programs should therefore treat registration as one part of a broader SMS compliance process, not as a one-time permission slip.
Final Takeaway
What carriers and their vetting partners want from a 10DLC submission is not complicated in principle.
They want to understand:
Who are you?
What are you sending?
Who will receive it?
How did those people agree to receive it?
Can that consent process be verified?
Do your sample messages accurately represent the campaign?
Does your website support what you submitted?
Can recipients easily stop the messages?
The strongest submissions make those answers obvious.
The weakest submissions force the reviewer to infer them.
Before submitting a campaign, read the registration as if you know nothing about the company. Follow the website links. Walk through the opt-in process. Compare the use case with every sample message. Check the legal identity against official records. Read the privacy policy and terms.
If every part describes the same business, the same consent process, and the same messaging program, the submission is much easier to evaluate.
That is the standard teams should aim for—not simply completing the form, but making the campaign verifiable from end to end.
