Three messages come back with three statuses: one says "delivered," one says "unknown," and one says nothing at all. Most people read the first as success, the second as failure, and the third as an error. All three readings can be wrong. The delivery receipt the DLR is the single most trusted signal in SMS and the one most people understand least, which is how businesses end up confidently reporting delivery numbers that don't reflect what actually happened.
A DLR (delivery report, or delivery receipt) is the status a mobile network returns after the fact, telling you what became of a message you sent. It sounds binary delivered or not but the reality is a set of statuses with specific meanings, a distinction between final and in-progress states, and an uncomfortable truth that some of these reports are inaccurate or outright fabricated. Reading them correctly is a skill, and it's the foundation of every reliable measurement, reconciliation, and troubleshooting decision you'll make.
This guide is the reference the glossary definitions aren't: what a DLR actually is, the real status taxonomy and what each state means, why "delivered" isn't always true and "unknown" isn't always bad, and how to build trustworthy measurement on a signal that isn't always trustworthy.
What a DLR actually is
When you send a message, two separate things happen, and confusing them is the first mistake. First, your message is accepted by your provider's API a synchronous response that says "I've received a well-formed message." That is not a DLR, and it is not delivery; the message hasn't touched a mobile network yet. If you're building an integration, the mechanics of that first stage belong to the HTTP API layer.
The DLR is the second answer, and it arrives later, asynchronously. After the message travels to the destination carrier and the network attempts to deliver it to the handset, the network sends back a status the delivery report describing the outcome. It typically reaches you through a webhook (a callback to your system) and carries the provider's message ID, a status code, a timestamp, and often an error reason. That status is what tells you whether communication actually succeeded, and it's the only real source of truth for delivery the API acceptance never was.
The status taxonomy: what the codes actually mean
Beneath the friendly words like "delivered" and "pending" sits a standard set of states, inherited largely from the SMPP protocol that underpins most SMS infrastructure. Knowing them is the difference between guessing and reading.
Status | Meaning | Final? | What to do |
DELIVRD | Delivered to the handset (per the network) | Yes | Count as success but see the caveat below |
UNDELIV | Undeliverable delivery failed | Yes | Investigate: bad number, route, or block |
EXPIRED | Validity period elapsed before delivery | Yes | Handset was unreachable long enough to time out |
REJECTD | Rejected by the network or a filter | Yes | Often filtering, unregistered sender, or bad content |
DELETED | Message deleted before delivery | Yes | Removed by the carrier; usually unrecoverable |
ACCEPTD | Accepted by the carrier (not yet delivered) | Sometimes terminal | Carrier took it; may be as far as you'll see |
UNKNOWN | Network can't or won't report a definite outcome | Yes-ish | Ambiguous not necessarily a failure |
ENROUTE | In transit, delivery still being attempted | No | Intermediate wait, don't act yet |
Two of these are the ones people misread most.
UNKNOWN is not the same as failed. It means the network isn't returning a definite outcome sometimes because the route or carrier doesn't provide reliable final reports, sometimes because the message genuinely can't be traced. On some destinations, a large share of real deliveries come back as UNKNOWN simply because that route doesn't report properly. Treating every UNKNOWN as a failure understates your delivery; treating it as success overstates it. It's an ambiguity to investigate at the route level, not a verdict.
ENROUTE and other intermediate states are not outcomes. A message that's still enroute hasn't finished its journey, and acting on an intermediate state marking it delivered or failed produces wrong numbers. Which brings us to the distinction that trips up most reporting.
Final versus intermediate states
Every DLR status is either final or intermediate, and only final states tell you what happened.
A final state DELIVRD, UNDELIV, EXPIRED, REJECTD, DELETED means the message's journey is over and this is the outcome. These are the states you count and report on.
An intermediate state ENROUTE and similar means the network is still trying. A message can sit in an intermediate state for a while, then resolve to delivered or expired. If you tally results before messages have reached a final state, or if you treat "accepted" as "delivered," your numbers will be wrong in ways that look plausible. The discipline is simple: reconcile on final states, and give messages time to resolve before you judge a campaign's delivery. A DLR that hasn't finalised isn't a result yet.
What "delivered" does and doesn't tell you
DELIVRD is the status everyone wants, and it's the most over-interpreted. Here is what it actually means and what it doesn't.
It means the network reported that the message reached the recipient's handset. That's genuinely useful. But it does not mean the person read the message SMS has no read receipt, and a DLR is not one. A delivered message can sit unread on a lock screen indefinitely. It does not mean the right person received it; if the number was reassigned or mistyped-but-valid, "delivered" just means it reached a handset. And the part that matters most it does not always mean the message truly arrived at all, because not every "delivered" status is honest.
The uncomfortable truth: not all DLRs are true
This is what the glossary definitions leave out, and it's the single most important thing to understand about delivery reports: some DLRs are fabricated.
On low-quality and grey routes, the intermediary carriers or aggregators in the chain sometimes return DELIVRD statuses for messages that never reached the handset because a route that reports high delivery looks good to whoever is buying it. The result is a beautiful delivery rate on your dashboard while a chunk of your traffic silently vanished. This is a direct consequence of how the aggregator routing layer works: the longer and cheaper the chain your message travels, the more places a false "delivered" can be inserted.
The practical implication is severe: you cannot fully trust a delivery rate built from the DLRs a cheap route reports about itself. A 98% delivered figure means nothing if some of those confirmations are invented. The only way to know a route delivers what it claims is independent verification confirming through test handsets on the actual destination network that messages reported as delivered genuinely arrive. For any route carrying important traffic, the DLR is a claim to be verified, not a fact to be trusted.
Why DLRs matter despite their flaws
None of this makes DLRs useless it makes them a signal to read intelligently. Used well, they drive four things nothing else can.
They are the basis of honest measurement: your real delivery rate, the foundation for judging whether any campaign or alert actually reached people. They enable billing reconciliation, letting you verify you're paying for messages that delivered rather than ones that failed. They power deliverability monitoring a sudden shift in the mix of statuses is the earliest warning that a route has gone bad. And they drive troubleshooting: the specific failure status on a message tells you whether the problem is a dead number, a filter, an expired validity, or a rejected sender. Turning that raw stream into insight is what DLR-driven campaign analysis is for.
How to use DLR data well
Reading DLRs correctly comes down to a handful of habits.
Match every DLR to its message. Attach a unique reference to each send so that when a DLR arrives possibly much later, possibly out of order you can tie it back to the original message and recipient. Without that thread, a stream of statuses is just noise.
Judge on final states, after they've settled. Don't compute delivery rates from intermediate statuses or before messages have had time to resolve. Give the batch time, then measure the final outcomes.
Read patterns, not individuals. One UNDELIV is a dead number; a spike of UNDELIV to one country is a route problem. The value of DLRs at scale is in the distribution of statuses over time, which is where a failing route or a filtered sender reveals itself.
Handle the failure states differently. A REJECTD often points to a sender or content issue you can fix; a persistent UNDELIV to specific numbers points to list hygiene, which a pre-send HLR lookup prevents; an EXPIRED cluster suggests unreachable handsets or slow routes. The status is a diagnosis, so treat each one as pointing at a different cause.
Verify what you can't trust. For critical routes, don't rely solely on self-reported DLRs confirm real delivery independently, so a route quietly returning false positives can't hide.
Limitations to keep in mind
A few realities keep DLRs honest in your own analysis. They arrive with latency, sometimes seconds, sometimes much longer, so real-time certainty isn't always available. Not every route returns them reliably some report only that a message was sent, never a final delivery status. They can be fabricated, as covered above. And they confirm receipt at best, never that anyone read or acted on the message. A DLR is a strong signal handled with these caveats and a weak one handled naively.
DLR reading checklist
To get reliable information from delivery reports:
Distinguish API acceptance from a delivery report only the DLR speaks to delivery.
Map each DLR to its message via a unique reference.
Report only on final states, after messages have had time to resolve.
Treat UNKNOWN as ambiguous and route-dependent, not automatically failed.
Read status distributions over time, not individual receipts, to catch route problems.
Treat DELIVRD from cheap routes as a claim, and verify critical routes independently.
Use specific failure states (UNDELIV, REJECTD, EXPIRED) to diagnose the underlying cause.
The bottom line
A DLR report is a precise, useful, and frequently misread signal. Delivered doesn't mean read, unknown doesn't mean failed, an intermediate status isn't an outcome, and a "delivered" rate from a cheap route can be partly fiction. Read that way final states only, patterns over individuals, verification for anything that matters delivery reports become the reliable backbone of measurement, billing, and troubleshooting they're meant to be. Read naively, they produce confident numbers that quietly lie to you.
SMSala provides genuine, verifiable delivery reporting on direct A2P messaging routes the kind you can actually build decisions on but wherever your DLRs come from, the value is in reading them correctly and verifying the ones that matter.
Frequently asked questions
What does a DLR of "DELIVRD" really mean?
It means the network reported that your message reached the recipient's handset. It does not mean the person read it SMS has no read receipt nor that the intended person received it if the number was reassigned, and on low-quality routes it doesn't even reliably mean the message arrived, since some routes return false "delivered" statuses. Treat it as a strong but verifiable signal.
Does "UNKNOWN" mean my message failed?
No. UNKNOWN means the network isn't returning a definite outcome, often because the route or carrier doesn't report reliably rather than because the message failed. On some destinations many genuine deliveries come back as UNKNOWN. Treat it as ambiguous and investigate it at the route level, rather than counting it automatically as a failure or a success.
Why do my delivery reports show high delivery but customers didn't receive messages?
Because some low-quality and grey routes return fabricated "delivered" statuses for messages that never reached the handset a route that reports high delivery looks good to buyers regardless of reality. The only reliable check is independent verification through test handsets on the destination network, rather than trusting the route's own DLRs.
What's the difference between a message being "accepted" and "delivered"?
Acceptance is your provider's API confirming it received a well-formed message the message hasn't reached a mobile network yet. Delivery, reported later in a DLR, is the network confirming the message reached the handset. Treating acceptance as delivery is a common mistake that makes delivery numbers look far better than reality.
Is a DLR the same as a read receipt?
No. A DLR confirms, at best, that a message was delivered to a device not that anyone opened or read it. SMS has no native read receipt, so a delivered message can remain unread indefinitely. If you need to know a message was acted upon, delivery reports can't tell you that; you'd measure it through clicks or responses instead.