The number you text from has to be registered
The appointment reminders stopped arriving.
Not with an error, which is what makes this one hard. The dashboard shows them going out. The account is in good standing, the phone numbers are correct, nothing in the automation changed. The customers simply do not get them, and the only place the real reason appears is inside the record of one individual undelivered message.
In the United States, a business text is allowed onto the mobile networks only if the number it is sent from has been registered. An unregistered number is not throttled or slowed down. It is blocked.
This is a United States rule, from a standard the American carriers put in place, and it does not describe how business texting works anywhere else. If you send to US mobile numbers it applies to you wherever your company is. If you do not, nothing below is about your market.
Two pages of the same manual describe two different worlds
Here is what makes this so easy to miss. A business owner who goes looking for information finds the overview page first, and the overview page is reassuring.
Twilio's overview of the scheme says: "Registering for A2P 10DLC results in lower message filtering and higher messaging throughput." It adds that customers who skip it "will receive additional carrier fees for sending unregistered traffic."
The page does say registration is required: "Anyone sending SMS/MMS messages over a 10DLC number from an application to the US must register for A2P 10DLC." What it never says is what happens if you do not. The only consequences it names are heavier filtering and higher fees, and the words "block" and "blocked" do not appear on it at all.
Read that as a busy owner and the conclusion is obvious. Registering is an optimisation. Skip it and delivery is a bit worse and the bill is a bit higher. Something for later.
Now the page you reach only after messages start failing, which describes error 30034: "Twilio blocks messages to U.S. numbers when you send from a +1 10DLC number that is not associated with an approved A2P 10DLC Campaign."
Blocks. Not filters, not surcharges.
Both pages are live on the same vendor's site. The reason they disagree is history rather than dishonesty. In July 2023 that vendor announced "a gradual increase of message blocking" on unregistered US numbers, "ultimately leading to a full block of all unregistered U.S.-bound messages sent after August 31, 2023". The September entry records that it happened: "Messages sent to the U.S. using unregistered +1 10DLC numbers will be blocked." The friendly page describes the world before that date. Nobody rewrote it.
Which is a decent general lesson about vendor documentation. The overview is marketing's page, kept broadly true. The error page is operations' page, kept exactly true. When they disagree, believe the error page.
What "registered" actually means
Two things get registered, and the vocabulary is genuinely opaque, so here it is in plain terms.
A Brand is you. In the vendor's words, "You provide information about who is sending these messages so that carriers know you are a legitimate sender" - legal name, tax ID, address, the checkable facts about the business.
A Campaign is what you intend to send and how people agreed to receive it: "You provide information about how end users can opt-in, opt-out, and receive help. It also involves providing a description of the purpose of your messages."
Both go to a central registry, and you cannot approach it directly. The Campaign Registry states that brands "must work with one of the registered messaging service providers (CSP) who will handle your registration process on your behalf", and that "Brands and Campaign Service Providers (CSPs) are verified prior to being allowed to send messages."
So the chain is: you, your messaging provider, the registry, the carriers. Four parties, and you are in a position to hurry exactly one of them.
The messages you never sent are still billed
A detail that changes how urgent this feels. From the changelog announcing the full block: "Twilio messaging rates will still apply, even for blocked messages."
An unregistered reminder running nightly is not just silent. It is a silent invoice, charging you for messages nobody received, for as long as nobody looks.
This is the single strongest argument against the most common piece of automation design in the wild, which is to retry on failure. Error 30034 describes a registration state, not a temporary condition. No number of retries will change it, and every attempt costs money. If your workflow retries texts, exclude this one.
Approved is not the same as working
People finish the paperwork, get the approval mail, and are still blocked. The error page lists why, and it is worth reading the causes as a checklist rather than a wall of text.
The obvious one: "Your Brand or Campaign registration is not complete, so the number is still unregistered for U.S.-bound 10DLC traffic."
The one nobody expects: "The phone number is not in the Sender Pool of the Messaging Service linked to your approved Campaign."
That second cause is a registration that is genuinely approved, attached to a number that is not the one you are sending from. The campaign is fine. The number is a stranger to it. Everything in the account looks green.
And a third, specific to the smallest businesses: "You added multiple +1 10DLC numbers to a Sole Proprietor Campaign. Only one 10DLC number can be registered for that Campaign. Additional numbers remain unregistered."
Why it looks random when the block is absolute
Blocking is unconditional, which makes the intermittent version of this confusing. If unregistered numbers are blocked outright, why does anything get through?
Usually because it left from a different number. Registration attaches to numbers, not to accounts, and a messaging service can hold several. Two of the documented causes of the error are exactly this: "The phone number is not in the Sender Pool of the Messaging Service linked to your approved Campaign", and, on the smallest registration tier, "You added multiple +1 10DLC numbers to a Sole Proprietor Campaign. Only one 10DLC number can be registered for that Campaign. Additional numbers remain unregistered."
So the pattern is per sending number rather than per customer. Which number a given message went out from is not something anybody watches, and it is rarely visible in the tool that sent it.
There is a second reason not to trust an intermittent pattern as a diagnosis. Registration is not the only way a text disappears: error 30007 covers a message that was filtered, which is a judgement about content or traffic rather than about your paperwork. A business can finish registering and still be filtered, and the two look identical from the outside.
The historical version is worth knowing only so you do not misread older advice. While the rule was being phased in, over the summer of 2023, blocking really did ramp up gradually - one recipient getting the text and another on the same carrier not, the first message of a batch going through and the rest failing. Advice written then describes a transition, not today.
What has not changed is where the reason lives. The summary of a failed send says "undelivered"; the reason - error code 30034, the number is not linked to an approved campaign - is on the detail of the individual message. Note where you have to look. Not at the summary, at one message.
The wait is not yours to control
The honest answer to "how long does this take" is that nobody will give you one number, and you should distrust any source that does.
The vendor's own standard onboarding page said, when I read it, that "campaign reviews are currently taking 10-15 days". Its sole proprietor page says campaign vetting "might take several weeks". Microsoft's guidance for the same registry gives two to three business days for the brand and three to five for the campaign. The figures differ by a factor of ten, and they can all be true, because the queue depends on your provider, your paperwork and the registry's mood that month. What matters operationally is simpler:
You cannot text US customers while you wait. Registration is not something to start when texting stops working. It is something to start before you build anything that depends on texting - and the same goes for a business that already texts and has never checked, because the consequences of what your automation does are yours, including the consequences of it doing nothing.
The worst version of this is the one where the registration was started promptly and finished on the day the block landed, with texting down for the weeks in between. Registration that is under way is still registration that is not done.
No tax ID: the sole proprietor door and its ceiling
A common blocker for the smallest businesses is that the form asks for a business tax ID and there is not one.
There is a documented path for that. "Sole Proprietor registration is available for customers in the United States and Canada who do not have a business Tax ID." It comes with real limits, and they are worth knowing before you choose it rather than after:
- "Sole Proprietor Campaigns can only have one 10DLC phone number attached to them."
- A verification code arrives by text and "You must respond to this OTP within 24 hours for your Brand to be approved."
- The mobile number used for that verification is reusable "no more than three times" for sole proprietor registrations.
- Throughput is capped low. The vendor's figures put a sole proprietor brand at a thousand message segments a day to one large carrier, against two thousand for the low-volume standard tier. Note the unit: a long text is several segments, so the number of messages is lower than it looks. The cross-carrier totals the page gives alongside these are explicitly approximate.
If you do have a tax ID, this path is not yours to take - you register as a Standard or Low-Volume Standard brand. And if the tax ID is new, budget for it not to be findable yet: the vendor warns that a newly issued EIN can take 30 to 90 days to appear in the databases used to validate it.
Toll-free is not the way around it
The standard advice from someone who has just been blocked is to switch to a toll-free number. The error page itself offers it as a stopgap.
It is not an unregistered path. Toll-free numbers have their own verification,
and since 31 January 2024, "traffic from unverified Toll-Free numbers in
Restricted or Pending status is blocked", with its own error code, 30032.
There is no unregistered way into a US mobile phone. Every sender type has a gate; they differ in which queue you stand in.
| Code | What it means | Is retrying useful |
|---|---|---|
| 30034 | the sending 10DLC number is not in an approved campaign | no, it is a registration state |
| 30032 | toll-free number is unverified, restricted or pending | no, same |
| 30007 | the message was filtered, usually on content or traffic pattern | no, and it is a different problem from registration |
| 21610 | the recipient replied STOP and is on the blocked list | no, and sending anyway is the thing you must not do |
STOP is not a keyword you own
Opt-out is the part small businesses most often get wrong, because it feels like something their own system handles.
The provider handles it first. On long codes, the default keywords - "STOP, UNSUBSCRIBE, END, QUIT, STOPALL, REVOKE, OPTOUT, and CANCEL" - are processed automatically, and then, in Twilio's words, "When Twilio receives an Opt-out keyword from one of your users, it adds this phone number to a list of blocked numbers. Twilio checks this list before sending any future outgoing messages." Later sends to that number fail with error 21610.
Your CRM never sees any of this. If a customer texts STOP, your messaging provider knows and your contact record does not, so your list and the list that actually governs delivery drift apart quietly.
The industry body sets a higher bar than the keyword list anyway. CTIA's messaging principles say opt-out requests "with normal language (i.e., stop, end, unsubscribe, cancel, quit, 'please opt me out') should also be read and acted upon by a Message Sender except where a specific word can result in unintentional opt-out", and that validity "should not be impacted by any de minimis variances in the Consumer opt-out response, such as capitalization, punctuation, or any letter-case sensitivities."
The same document is worth two more lines while you are there. Consent does not travel: "A Consumer opt-in to receive messages should not be transferable or assignable. A Consumer opt-in should apply only to the campaign(s) and specific Message Sender for which it was intended or obtained." And bought lists are out: "Message Senders should not use opt-in lists that have been rented, sold, or shared to send messages."
Why campaigns get rejected
Four rejection causes come up again and again, and all four are avoidable before submission.
The consent evidence cannot be checked. A campaign is rejected when "Your opt-in evidence cannot be verified because the website is private, behind a login, incomplete, or missing publicly accessible screenshots of the consent flow." The reviewer needs to reach your consent form without an account.
Having the number is treated as consent. A messaging platform's own guidance puts it plainly: "Collecting a contact's phone number does not by itself establish consent to receive SMS messages", and "Do not preselect SMS consent checkboxes."
Shortened links from a free service. Campaigns are rejected for these: "you must use a dedicated, branded short domain that belongs to your business. You cannot use the sort of randomly-shortened URL typically furnished by a free service like bit.ly or TinyUrl; this will lead to rejection of the Campaign by TCR."
The description reads like personal texting. Rejection code 30912 exists for "The campaign description suggests personal communication between individuals instead of messages sent by a business application to end users", with the instruction "If your traffic is truly personal or peer-to-peer, do not submit it as an A2P 10DLC campaign."
That last one deserves a caution, because there is a tempting response to it: describe on the form the messaging the registry seems to want to hear, rather than the messaging the phone system actually sends.
It is an understandable impulse and a bad trade. Some campaign rejections are remediable and some are not, the fees are charged at submission and are non-refundable regardless of outcome, and a description that does not match what you actually send is a written record of that mismatch, filed with a registry, in your business's name.
What to check in your own setup
Find out whether the number you use is registered at all. Not whether you filled in a form once. Whether the number you actually send from sits in the sender pool of an approved campaign today. Those are different questions and the second is the one that governs delivery.
Open one undelivered message. Not the summary, the individual message. That is the only place the real reason lives. If your tool cannot show you carrier-level status per message, that is worth knowing before you need it.
Take retries off text sending. Registration failures and opt-out failures both survive any retry schedule, and both cost money each time. What you want is an alert to a human, once.
Reconcile your opt-outs. Ask your provider for the list of numbers it has blocked, and compare it with the unsubscribed flags in your own system. Any difference is either a customer you are still trying to text or a customer you have wrongly stopped talking to.
Check what your consent page looks like to a stranger. Log out, open it in a private window, and see whether somebody could screenshot the whole flow. If not, the campaign review cannot verify it either.
Register before you build. The dependency runs the wrong way round for most small businesses: they build the reminder flow, launch it, and discover the queue. Weeks is a normal wait, and the queue does not care that the flow is ready.
When this stops being a settings question
For one number, one type of message and a customer list you gathered yourself, the checks above are the whole job. Register, keep the consent evidence public, keep opt-outs in sync, and texting stops being something that surprises you.
It becomes a design question when texts are one channel among several. Then the questions are which messages must be texts at all, what happens to a customer who has opted out of texts but not email, what the system does on the day the registration lapses or the campaign is re-reviewed, and who finds out. None of that is a checkbox in a messaging tool, and none of it is visible until a channel goes quiet.
Working out which of those two situations you are in is what a process audit settles: $299, three business days, and a written map of which of your customer messages can actually leave the building, and what has to be registered before they can.