SMS deliverability is the share of the messages you send that a carrier accepts and delivers to the handset — measured against messages submitted, not against messages you hoped would work. It is not the same as throughput. Throughput is how fast you are allowed to send (messages per second, per sender); deliverability is how much of what you sent survives carrier filtering, registration checks, and spam classification on the way in. A pipeline sustaining 30 messages per second with a 72% delivery rate has a throughput problem nobody cares about and a deliverability problem that is quietly costing it a quarter of every campaign. This playbook is the operating manual for the second number.
Deliverability is not throughput — get the definition straight first
Teams routinely conflate four distinct numbers, so separate them before anything else:
- Throughput — the carrier-granted send rate for a sender or campaign (for example, the messages-per-second cap a US 10DLC campaign receives at registration).
- Acceptance — the platform handed the message to a route and received a submission acknowledgment. Acceptance says nothing about the handset.
- Deliverability — of the messages accepted, how many returned a delivered receipt from the terminating carrier. This is the number that decides whether a campaign worked.
- Engagement ratio — the split between outbound (MT) and inbound (MO) traffic on a sender. Carriers read a sender that only ever broadcasts and never gets replies as a spam pattern, and filter it accordingly.
A campaign can have full throughput, 100% acceptance, and 60% deliverability — the failure happens downstream of everything your send-side metrics show. That is why deliverability work is a distinct discipline, not a subheading of "how fast can we send."
The pre-flight checklist: register, pool, and balance before you scale
Deliverability failures are almost always pre-flight failures discovered late. Run these three checks before raising volume on any sender.
1. Brand and campaign registration (10DLC and its non-US equivalents)
In the US, application-to-person SMS over local long-code numbers runs through 10DLC registration: the carrier ecosystem knows who the brand is, what use case each campaign declared, and what volume that use case was approved for. Unregistered traffic is not "slower" traffic — it is progressively filtered to nothing, and in most cases carriers now block it outright. The same pattern repeats internationally under different names: sender-ID registration regimes across much of Europe, the Middle East, and Asia, and DLT registration in India. The operational rule is identical everywhere: no promotional or notification volume moves until the registration for that use case is approved, and the declared use case has to match what you actually send — a campaign registered as "account notifications" that ships marketing content gets its deliverability destroyed, then its campaign suspended.
2. Sender pool hygiene
Long codes and toll-free numbers carry a reputation, and that reputation is shared. One abusive use case on a sender poisons every other campaign routed over it. Pool hygiene means:
- Separate pools by use case. OTP/verification traffic, transactional notifications, and marketing campaigns each get their own sender set. A marketing campaign that provokes complaints cannot drag your OTP delivery down with it.
- Retire contaminated senders. A number that has been filtered or blocked for one use case does not recover by reusing it for another — rotate it out of the pool.
- Keep pools proportional to volume. Spreading 5,000 messages a day across 50 long codes reads as snowshoeing (distributing volume to evade per-number filters) and gets the whole pool flagged. Pool size should track real volume within the registration's declared throughput.
3. Throughput vs the bidirectional ratio
Even a fully registered, cleanly pooled campaign falls over if it only ever talks and never listens. Carriers weigh the MT/MO ratio on a sender as a spam signal: legitimate programs collect replies, STOP requests, and keyword responses; abusive ones are pure broadcast. Operationally this means: send on numbers that can receive, route inbound replies to somewhere they are actually handled, and process opt-outs immediately — an unanswered STOP is the fastest way to get a sender's filtering tightened. And never buy throughput by over-registering senders to multiply per-sender caps; carriers treat that as evasion and it converts a throughput limit into a pool-wide block.
Observable delivery: the campaign route is measured, not assumed
Deliverability work only exists if failures are visible per campaign, per route, and per sender pool. Orbit's outbound SMS terminates over Devotel's own wholesale softswitch, with direct interconnects across 500+ global carriers — and every message returns a delivery receipt that lands back on the same account. In the dashboard, the campaigns view breaks each outbound campaign down into delivered, failed, and pending states, and every failure carries the carrier's reject reason in plain terms rather than a raw code — so a spike in "unregistered route" or "content filtered" failures is visible in the campaign itself, not inferred from a drop in customer replies. The per-message receipt stream behind those views is the same one described in the delivery-log guide, so anything the dashboard shows can also be pulled into your own reporting over the API.
A worked example: the weekly per-pool delivery report
The deliverability review that catches problems early is boring by design — one table, every week, per sender pool:
| Sender pool | Submitted | Delivered | Deliverability | Failed — top reject reason |
|---|---|---|---|---|
| OTP / verification | 182,400 | 181,905 | 99.7% | 420 invalid destination |
| Transactional notifications | 96,300 | 95,150 | 98.8% | carrier filtering — content |
| Marketing — spring promo | 240,900 | 198,100 | 82.2% | unregistered campaign use case |
Read it like this: OTP and transactional pools are healthy (98–99%+ delivered; their residual failures are mostly invalid numbers, a list-hygiene issue, not a carrier issue). The marketing pool at 82.2% with "unregistered campaign use case" as the dominant reject reason is a registration problem — the campaign was booked under a use case that does not match what was sent, so the carriers filtered the discrepancy. The corrective action is upstream: re-register the campaign under the correct marketing use case, keep the pool isolated from OTP traffic, and watch next week's number move. That cadence — measure per pool, classify the dominant reject reason, fix the upstream cause, re-measure next week — is the entire discipline. Everything else is a variation on it.
Frequently asked questions
What is SMS deliverability, in one sentence?
SMS deliverability is the share of submitted messages that carriers accept and deliver to the handset — a measure of what survives carrier filtering and registration checks, distinct from throughput, which only measures how fast you are permitted to send.
How is deliverability different from throughput?
Throughput is the carrier-granted send rate for a sender or campaign — messages per second. Deliverability is the fraction of what you sent that actually reached a handset. High throughput with poor deliverability means you are failing more messages per second, not reaching more customers.
What is the single most common cause of poor SMS deliverability?
Registration mismatch: sending a use case (typically marketing) over a route or campaign that was never registered for it — unregistered 10DLC traffic in the US, or an unregistered sender ID in markets that require it. The messages are filtered progressively, so it shows up as a slow deliverability decline rather than a hard block.
What is sender pool hygiene?
Keeping each use case on its own sender set (OTP separate from transactional separate from marketing), retiring senders that have been filtered or blocked, and sizing the pool to real volume — because carrier reputation attaches to the sender, and one abused use case poisons every campaign sharing it.
Why does the outbound-to-inbound ratio matter?
Carriers read a sender that only broadcasts and never receives replies as a spam pattern and filter it accordingly. Legitimate programs collect replies, keywords, and STOP requests; keeping senders two-way capable — and acting on opt-outs immediately — protects the sender's filtering reputation.
How do I measure deliverability week over week?
Group sends by sender pool, divide delivered receipts by submitted messages, and rank the failures by carrier reject reason. The reject-reason distribution tells you which upstream fix to make — registration, content, or list hygiene — and next week's same table tells you whether it worked.
Published 24 August 2026. Part of the Orbit resources library — foundational guides for teams building on communications infrastructure. For the provider shortlist to run this playbook on, see the [top 10 SMS APIs comparison](/es/blog/top-10-sms-apis-2026) and the [best SMS API providers guide](/es/compare/best/best-sms-api-providers-2026).