A support team runs a password-reset campaign and the dashboard reports 97% delivered. The same week, the helpdesk fills with customers saying the code never arrived. Both numbers are "true." The dashboard is reporting what the route told it, and the route was lying.
This is the part of the direct-versus-grey-route conversation that most articles skip. They compare the two on price, reliability, and compliance, then move on. But for anyone who actually depends on delivery data to make decisions, the more important question is narrower: can you believe the delivery receipt the route hands back? On a direct route, usually yes. On a grey route, often no. Understanding why requires looking at what a delivery receipt really is before comparing where it comes from.
What a delivery receipt actually is
A delivery report, or DLR, is not a guarantee that a person read your message. It is a status message that travels back up the same chain your SMS travelled down. When you send an A2P message, your platform submits it over a protocol (most commonly SMPP), and the receiving system returns a receipt object containing a message ID, a final status, an error code, and timestamps for when the message was submitted and when it was "done."
The status field is the one everyone watches. Under the SMPP standard it carries a small set of defined values, and each means something specific:
DLR status | message_state | What it should mean |
DELIVRD | 2 | Handset acknowledged receipt to the network |
EXPIRED | 3 | Validity period passed before delivery |
UNDELIV | 5 | Network could not deliver (bad number, blocked) |
ACCEPTD | 6 | Accepted by the network, no final confirmation yet |
REJECTD | 8 | Operator or firewall refused the message |
UNKNOWN | 7 | No status information available |
The word "should" is doing real work in that table. The value DELIVRD is only meaningful if it originated from the destination carrier's own systems, which received a delivery acknowledgment from the handset. A status is a claim, and a claim is only as trustworthy as whoever generated it. That single distinction is the entire grey-route problem.
The chain the receipt has to travel
To see where trust breaks, follow the message on each route.
On a direct route, the path is short and named. Your platform hands the message to a provider that holds a direct interconnect with the destination mobile operator. The operator delivers to the handset, the handset acknowledges, and the operator generates a genuine delivery receipt that flows straight back:
Your app → Provider → Destination carrier → Handset. The DLR returns along the same line, generated by the party that actually did the delivering.
On a grey route, the message takes an unofficial path that was never intended for commercial A2P messaging. It might be injected through international roaming agreements meant for person-to-person texts, or pushed through banks of physical SIM cards ("SIM farms") that dress commercial traffic up as ordinary personal messages. The chain looks more like this:
Your app → Aggregator → Wholesale broker → Roaming/SIM injection → Destination carrier → Handset
Every hop in that chain is a place where the real delivery status can be lost, and where an intermediary has both the opportunity and the commercial incentive to invent one.
The four ways a grey route corrupts your DLR
The failure is rarely a blank report. A blank report would at least be honest. The damage comes from receipts that look normal and are wrong.
Fabricated final states. When a grey-route intermediary loses visibility of the real outcome, some simply return DELIVRD anyway. This happens constantly, because SIM-farm and roaming injections often can't collect a genuine handset acknowledgment. Returning a success keeps the delivery percentage attractive and the contract renewed, so you receive a confident "delivered" for a message that was silently dropped.
Missing intermediate transitions. A healthy delivery usually moves through states: accepted, then en route, then delivered. Grey routes frequently collapse this into a single instant "delivered," because the intermediate signalling that would produce those transitions never happened. Receipts that arrive suspiciously fast, with no journey, are a signature of a synthesized status rather than a real one.
Silent operator blocking. Carriers and their SMS firewalls actively hunt for grey traffic. When they catch it, they often discard the message without returning an error the upstream broker will pass back to you. The block is real; the DLR still says delivered. This is why grey-route delivery numbers can stay high for weeks and then collapse the moment a carrier tightens filtering.
Sender identity rewriting. To evade detection, grey routes may overwrite or randomize your Sender ID. Even if the message reaches the handset, it arrives from an unfamiliar or numeric sender. The DLR reports success, and it is technically correct that something was delivered, just not the branded, trusted message you paid for. For OTPs and alerts, a message the recipient distrusts is close to a message that failed.
Direct versus grey, compared on what the receipt is worth
Most comparison tables in this space rank the two routes on cost and reliability. Here is the comparison that matters if you make decisions from delivery data.
Dimension | Direct route | Grey route |
Source of the DLR | Destination carrier's own systems | Any intermediary in the chain |
DELIVRD reliability | High; reflects handset acknowledgment | Low; may be synthesized |
Intermediate states | Present and traceable | Often collapsed or absent |
Sender ID integrity | Preserved as registered | May be rewritten to evade filters |
Behavior under carrier filtering | Errors surface as real UNDELIV/REJECTD | Blocks hidden behind false DELIVRD |
Cost per message | Higher | Lower, until the route dies |
Stability over time | Consistent | Degrades without warning |
The cost gap is genuine, and it is why grey routes exist. But the saving is borrowed against the reliability of your own reporting. A cheaper message that reports success it didn't earn is not cheaper. It is a message you will resend, investigate, or lose a customer over, while your analytics tell you everything is fine.
How to test whether your own DLRs are real
You do not have to take a provider's word for it. Delivery data can be audited, and a handful of controlled checks will expose a grey route quickly.
Start with a seed-number test. Send to a set of handsets you physically control, across the carriers and countries you actually target. Compare three things for each: whether the message arrived at all, what Sender ID it displayed, and what status the DLR reported. A DELIVRD receipt for a message that never reached the seed phone is the clearest possible proof of a fabricated status.
Then look at timing distribution. Pull the gap between submit time and done time across a real campaign. Genuine deliveries scatter: some in two seconds, some in thirty, with a tail that retries for minutes. If almost every receipt reports "delivered" within an identical, implausibly short window, the statuses are likely generated in bulk rather than collected from handsets.
Watch the error-code vocabulary. Direct routes produce a varied spread of honest failures: absent subscribers, full memory, blocked numbers, network timeouts. A route that returns almost nothing but DELIVRD, with failures rounded away, is reporting the outcome it wants you to see.
Cross-check with an independent signal. An HLR lookup tells you whether a number is even active and reachable before you send; comparing that against your delivery rates reveals whether "delivered" statuses are landing on numbers that can't actually receive. Sustained gaps between reachable numbers and reported successes point at the route, not the audience.
A short checklist you can run this quarter:
Send to controlled seed phones on every target network and confirm physical arrival.
Verify the displayed Sender ID matches what you registered.
Chart submit-to-done timings and look for unnatural uniformity.
Confirm your failure codes include a realistic spread, not just successes.
Reconcile delivery rates against HLR reachability on a sample.
The trap most teams don't know they're in
Here is the uncomfortable part. You can buy a "premium" route and still receive grey traffic. Many providers blend routes dynamically, sending the first portion of a campaign over a clean direct connection and quietly overflowing the rest onto cheaper grey capacity when volume spikes or margins tighten. Your test messages, sent in small numbers, sail through the good route. Your real campaign, sent at scale, does not.
This is why a one-time test at onboarding is not enough, and why the role of SMS aggregators matters so much. An aggregator that is transparent about which carriers it terminates on, and that keeps direct interconnects rather than reselling wholesale bulk, is fundamentally different from one that optimizes only for the lowest per-message cost. The question to ask a provider is not "do you use grey routes," because everyone says no. It is "which carriers do you have direct connections with in my target markets, and can you show me route-level delivery data?"
Where regulation removes the choice entirely
In several markets, the direct-versus-grey decision has already been made for you by law, and grey routing is not a cost trade-off but a compliance failure.
India is the clearest example. Under the TRAI framework, commercial messages must move through registered principal entities, approved templates, and blockchain-based DLT registration. A grey route bypasses that system by definition, which means non-delivery, penalties, and blocked sender identities rather than savings. Similar registration and sender-verification regimes now govern traffic across the Gulf, and carriers there increasingly reject unregistered A2P messages outright.
For regulated industries such as banking, healthcare, and government services, the stakes compound. A one-time passcode that arrives late or not at all is a locked-out customer and a support cost. A message that violates local routing rules is a liability. In these contexts the accuracy of the delivery receipt is not a reporting nicety; it is the evidence you rely on to prove a notification was sent and received.
Choosing a route when the receipt has to be trusted
Not every message needs a Tier-1 direct route. A low-stakes marketing blast to an engaged list can tolerate more variance than a bank's login OTP. Match the route to the consequence of a false "delivered."
Use this rough framing:
Transactional and time-critical (OTPs, security alerts, appointment confirmations): direct routing is effectively mandatory. The cost of a fabricated success is a failed login or a missed appointment, and you need honest failure codes to trigger fallbacks.
Regulated-market traffic (India, GCC, and similar): direct and registered is the only compliant option, full stop.
High-value promotional (launches, flash sales, re-engagement): direct routing protects Sender ID trust and gives you the accurate delivery reports you need to measure what actually worked.
Low-stakes, non-branded bulk: grey routes may appear economical, but budget for the reality that reporting will be unreliable and the route can vanish mid-campaign.
The decision ultimately rests on one question: if this message silently fails but reports success, what does it cost you? The higher that number, the less you can afford a route that guesses at delivery.
Reading your delivery data going forward
Better routing changes what your dashboard is worth. When receipts come from carriers rather than intermediaries, the numbers become something you can act on: segmenting unreachable numbers, timing retries against real failure patterns, and using delivery data to lift your genuine SMS deliverability instead of admiring a fabricated one.
This is where working with a provider that maintains direct carrier relationships earns its cost. SMSala operates on direct routes with carrier-level connectivity, which is what makes handset-accurate delivery reporting possible in the first place. The reports are only as honest as the path the message took to earn them.
Frequently asked questions
Can a grey route ever return an accurate delivery report?
Sometimes, by coincidence. If a grey-injected message happens to reach the handset and the intermediary happens to have visibility of the acknowledgment, the DELIVRD status can be real. The problem is that you cannot tell the real ones from the fabricated ones without independent testing, which defeats the purpose of having a report at all.
Why do grey-route delivery rates look higher than direct routes?
Because failures are often hidden. A direct route surfaces real UNDELIV and REJECTD codes, so its "delivered" percentage reflects reality. A grey route that converts silent drops into false successes will always look better on paper, right up until a carrier tightens filtering and the rate collapses.
Is a numeric or unfamiliar Sender ID always a sign of a grey route?
Not always, since some countries mandate numeric sender formats. But if your registered alphanumeric Sender ID arrives rewritten or randomized without a regulatory reason, that rewriting is a common grey-route evasion tactic and worth investigating.
How often should I test my routes?
Test at onboarding, then re-test at production volume, then spot-check periodically, especially before high-stakes campaigns. Route blending means a provider that passed a small test can still overflow real traffic onto cheaper capacity, so occasional checks at real scale matter more than one clean result at signup.
Does a higher price guarantee a direct route?
No. Price is a weak signal in both directions. The reliable signals are provider transparency about carrier interconnects, route-level delivery data you can inspect, and consistent seed-test results at real volume.