OTP Delivery Rates: Why Your Provider is Lying to You

Every SMS gateway on the market advertises a delivery rate of 99% or higher. They are not lying exactly. They are just measuring something different from what you think they are measuring. This is what they are counting, what they are not, and three tests you can run against your own provider in under an hour to see the truth.

The two definitions of "delivery"

There is no industry standard for the term "delivery rate." Providers have settled on the most generous possible reading. Here are the two most common:

Definition A (the honest one): handset receipt

The carrier confirmed that the recipient's phone accepted the message and stored it on the SIM. The user will see it. This is what you actually want.

Definition B (the marketed one): carrier handoff

The gateway successfully delivered the message to the destination carrier's SMSC. The carrier then has to find a handset, which may or may not happen — the user could be out of range, the phone could be off, the number could have been recycled to a different person, or the destination could be an MVNO that has a known routing problem. The gateway still calls it "delivered" because the message left its hands successfully.

The gap between A and B is usually 3-8 percentage points. On a 99% advertised rate, that means your real delivery rate is somewhere between 91% and 96%. For a transactional OTP flow where every failed code is a locked-out user and a support ticket, that gap is your entire weekend.

Why providers prefer the wider definition

Once a message is in the carrier's network, the gateway's visibility drops to whatever the carrier's DLR (delivery receipt) tells it. And carriers have their own incentives:

• The carrier gets paid per handoff regardless of whether the handset receives the message.
• Some carriers' SMSCs are slow to send back the negative DLRs that would prove non-delivery, so the gateway's logs simply never hear about a problem.
• MVNOs that the gateway routes through on a wholesale basis can silently drop messages, and the upstream gateway sees only a successful carrier handoff.

None of this is fraud. It is just the natural incentive structure of a multi-party network. But it means the number on the homepage is structurally biased upward.

What you can actually measure

Forget the provider's dashboard. The only delivery rate that matters is the one you measure yourself, end to end, on your own traffic, against your own definition. Three tests, in increasing difficulty:

Test 1: The closed loop (5 minutes)

For OTP specifically, you have a built-in feedback signal: did the user complete the verification? Send 1,000 codes, count the conversions within 5 minutes, account for users who never enter the code in the first place (UI friction, abandoned sessions). If 92% of codes reach a user who actually attempts to enter them, your real delivery rate is somewhere near 92%.

This is the most honest number you will get. The provider can claim whatever it wants; the funnel tells the truth.

Test 2: The HLR sweep (20 minutes)

Before sending the message, run an HLR lookup on each number. HLR (Home Location Register) is the carrier's own database that says whether a number is currently active, which carrier it is on, and whether it has been ported. The HLR does not lie. If the number is dead, no SMS to that number will ever reach a human being.

Typical findings on a 10,000-number list:

• 3-5% are dead or disconnected (sending is wasted spend and a deliverability hit)
• 1-3% are on networks with known routing issues (reachable but slow)
• 0.5-2% have been ported to a different carrier (works, but the gateway's "intelligent routing" was making a wrong assumption)

Drop the dead numbers before sending. Your delivered-to-attempted ratio jumps by the same amount.

Test 3: The synthetic monitor (1 hour to set up, then continuous)

Set up a cron job or scheduled task that, every 15 minutes, sends a single test SMS to a known-good number on each of the top 5-10 carriers in your market (AT&T, T-Mobile, Verizon, Vodafone, Orange, Reliance Jio, MTN, etc.). Log the delivery receipt and the time-to-receipt. Alert when delivery rate drops below 95% or latency exceeds 10 seconds.

This is the test that catches the silent degradations. A gateway that works fine on Tuesday can be quietly routing 15% of US traffic through a misconfigured aggregator on Wednesday. Without synthetic monitoring, you only find out when your conversion rate drops and you spend two days blaming the front end.

The real failure modes

When a delivery fails, the DLR will tell you one of these codes. These are the ones that actually matter:

Code 27 — Absent Subscriber

The phone is off, out of range, or the SIM is inactive. Not the gateway's fault; nothing can be done. Most providers retry the message for up to 24-48 hours, but for OTPs specifically you should not wait — re-prompt the user.

Code 13 — Memory capacity exceeded

The SIM card is full of unread messages. Common on cheap prepaid SIMs in emerging markets. Same fix: re-prompt the user, optionally offer a voice fallback.

Code 11 — Destination busy / temporary failure

Transient network issue at the carrier. A retry within 30-60 seconds almost always succeeds. This is one you actually want automatic retry logic for.

Code 1 — Unknown subscriber

The number is dead. HLR would have caught this. Drop the number, do not retry.

No DLR at all

The gateway says "delivered" (carrier handoff) but the carrier never reports back. This is the gap between definitions A and B above. The only fix is to use a gateway that has direct carrier integrations and a tight DLR loop, and to monitor with your own synthetic tests.

What "good" looks like in 2026

For an OTP flow on a clean list (HLR-validated, no dead numbers), the honest target is:

• 95-98% first-attempt delivery to a working handset in developed markets
• 90-95% first-attempt delivery in emerging markets (more carrier fragmentation, more off-network handsets)
• 99%+ delivery after a single retry on transient errors

If your provider claims 99.9% as their headline number, that is the carrier-handoff number. Your real number is lower, and the difference is the support tickets you are about to receive.

The check you can run today

Sign up with a second provider, fund it with $20, and send 1,000 OTPs through it to your own users as an A/B test. Tag the messages. After a week, you have an honest, apples-to-apples comparison of two real delivery rates on your real traffic. The provider with the higher rate becomes your primary. The other one becomes your failover. You will not go back.