Fake DLR: What It Is, How It Works, and How to Detect It

If you've landed here, something probably didn't add up. The delivery report looked fine — 98% delivered, supplier confirmed, nothing flagged in the logs — but the messages weren't getting through. A customer called about a missing OTP. You asked your supplier and got the same clean numbers back, with no explanation for the gap.

That experience is part of why TelQ exists. We've been running real-handset delivery tests since 2016, and fake DLRs — the gap between what suppliers report and what recipients actually receive — are the problem we see consistently, at scale, across every kind of route. It's not something we stumbled on while building a testing tool. It's one of the core reasons we built it.

What is a fake DLR?

DLR stands for delivery report — the status signal that travels back up the SMS routing chain when a message is processed. A real DLR reports what actually happened: the message reached the destination SMSC and was delivered to the handset. At each point in the chain — supplier, aggregator, enterprise platform — the confirmation arrives as evidence that the message got through.

A fake DLR looks identical. The message reaches the supplier's SMSC, the SMSC marks it delivered in its own system, and the delivery report fires back up the chain confirming success. The handset received nothing. The SMSC generated the report without ever delivering the message, and nothing in the report itself signals that anything went wrong.

This is what makes fake DLRs hard to catch without external verification. The report is technically well-formed. It arrives on schedule. It says the right things. The deception is in what was reported, not in how the report looks — and that decision doesn't have to happen at the destination SMSC. It can be introduced at any hop where someone controls what goes back upstream.

How fake DLRs happen

Suppliers are often measured — and paid — based on delivery reports. High reported delivery rates mean better terms, continued business, fewer questions from customers. A supplier route that actually underperforms has an economic incentive to compensate with its reporting: mark messages as delivered whether they arrived or not, and let the numbers speak.

(The industry has a restrained name for this — delivery metric inflation. Cleaner than "lying about whether your messages arrived," which is what it is.)

The mechanism can sit anywhere in the chain — at the supplier's SMSC, at an intermediate hop, at any point where someone controls what gets reported back upstream. The most common version: instead of waiting for handset confirmation, the SMSC generates a delivered status on receipt and fires it back through the chain. But a vendor anywhere along the route can alter the DLR before it reaches you. Either way, the result is indistinguishable from a legitimate delivery confirmation at every point above it.

Not every misleading DLR involves deliberate fraud. Some arise from architectural ambiguity: a DLR confirming delivery to an intermediate SMSC is technically accurate, but if the customer interprets it as delivery to the handset, the effect is the same. Others come from misconfiguration — a test mode that auto-confirms deliveries left active in production, or an SMSC timeout policy that generates a synthetic "delivered" status rather than reporting "unknown" when no downstream confirmation arrives. The commercially significant cases are deliberate. But the pattern is indistinguishable either way: the report says success, the handset received nothing.

Fake DLRs aren't a grey-route problem. They happen on routes that look legitimate — suppliers with real SMSC numbers, established relationships, clean-looking credentials — whenever the economic incentive to inflate delivery metrics is present. The route tier doesn't predict it.

Which means you also can't catch one by analyzing the DLR itself. The report came from the same infrastructure generating the fake. The only check that works is one that sits entirely outside that infrastructure.

Why fake DLRs are commercially damaging

For aggregators, the cost is direct: you're paying for messages that never arrived. If you're billing customers on delivery, you're absorbing supplier charges for non-delivery events and passing them on as legitimate. Since nothing flags the problem internally, the discrepancy can persist for weeks before a customer escalates.

The commercial cascades from there. An aggregator caught with a fake-DLR-heavy route faces customer attrition, renegotiation pressure, and reputational damage in an industry where word about supplier quality travels fast. The route looked clean on paper. The customer was paying for delivery that wasn't happening.

For enterprises running OTP or transactional traffic, the consequences are immediate. A customer who didn't receive their authentication code and sees a delivered status from their provider has nowhere to go but support. At scale, the numbers get uncomfortable — Juniper Research puts SMS fraud losses at $71 billion in 2026. An OTP that didn't arrive looks like a one-off. The same failure happening systematically across a route looks like the supplier's business model.

How to detect fake DLRs

The only reliable method: compare what the supplier reports against what actually arrives at a real handset.

You can't do this from within the supplier's own reporting infrastructure. The supplier controls the DLR; looking for signs of fraud in that data is the wrong tool for the problem. What you need is an external test number — a real SIM on a real device in the destination market — and a test message sent through the exact supplier route you're verifying.

A few things make detection harder in practice than it sounds. The source of fake DLRs isn't always the supplier — MNOs also generate false success statuses when they filter specific sender IDs or reject messages on throughput grounds but still report delivered. More commonly, suppliers apply fake DLRs selectively: some whitelist known test numbers, so the test passes clean while real traffic gets faked; others only generate false reports on bulk campaigns, which means a one-off test on the same route tells you nothing; others run fake DLRs on a random percentage of traffic, making any single clean result statistically inconclusive. The implication: the test infrastructure matters as much as the test itself. Test numbers that can't be associated with a testing service, real SIM cards on actual destination networks, and enough volume to surface a percentage-based fake are what make a result meaningful rather than reassuring.

The workflow: you send a test message through your supplier route, with TelQ's Test ID Text included in the message body. TelQ's real SIM in the destination market receives the message. TelQ records what arrived — whether the message came through at all, the content, the Sender ID as displayed, and the delivery latency — and compares it against your supplier's DLR. When the DLR claims success and the handset received nothing, the discrepancy is documented in the test result.

"Test SMS delivery that able to detect and rule out fake delivery report. We also can check either the SMS that we draft has the same output that received by the recipient." — Nurhana J., IT Consultant, Information Technology and Services (TelQ customer)

"The TelQ platform allows us to easily identify which SMS have been successfully delivered, whether we have received a false DLR, and if there are any changes to the sender id or content of the SMS." — Connor C., TelQ customer

TelQ runs this across 180+ countries and 1,500+ networks, using physical handsets with real SIM cards on destination networks. Since 2016, TelQ's platform has processed 100M+ SMS delivery tests using this real-handset approach. For context on how fake DLR detection fits within a broader SMS delivery testing workflow, the SMS Testing Guide covers the full methodology. One note on test conditions: the SMS whitelisting guide covers cases where suppliers detect and treat test traffic differently from production — relevant when interpreting results on routes you suspect are flagging test messages.

For continuous route monitoring, TelQ's Tests Scheduler runs automated tests at configured intervals, catching fake DLR behaviour as it develops rather than after a customer complaint surfaces it.

If you're auditing a new supplier route or investigating unexpected delivery gaps, TelQ's real-handset tests give you an independent source of truth. Test your routes for fake DLRs with TelQ.