SMS Delivery Receipts (DLRs) Explained Simply

A delivery receipt (DLR) is the status report that travels back up the SMS chain after you send a message: a notification from the carrier network indicating what happened to the message, delivered to the handset, still pending, failed, expired, or rejected. DLRs are how senders know whether a text arrived, which makes them the ground truth (with caveats) behind every delivery-rate dashboard, every retry policy, and every list-hygiene process in organizational messaging.

They are also widely misunderstood. "Delivered" does not mean "read." "Sent" does not mean "delivered." And a clean-looking delivery rate can hide filtering that a proper read of DLR statuses would expose. This guide explains where receipts come from, what each status actually asserts, the honest limits of the mechanism, and how to put DLRs to work.

Key takeaways:

• A DLR is generated by the network, not the recipient: it reports handset delivery (or failure), never reading or attention.
• The two grades of receipt, handset-confirmed versus intermediate/carrier-level, differ enormously in evidentiary value; know which your provider gives you.
• The standard status vocabulary (delivered, undelivered, expired, rejected, unknown) comes from the messaging protocols that connect providers and carriers, notably SMPP.
• The operational uses are concrete: measuring true deliverability, triggering fallbacks, cleaning dead numbers, and detecting filtering early.

Where a DLR comes from: the message's round trip

Follow one message through the chain and the receipt explains itself:

1. Submission. Your platform hands the message to its gateway or aggregator, which routes it toward the recipient's carrier. Status at this point: submitted or sent, meaning only "accepted for delivery."
2. Carrier processing. The carrier accepts the message, applies its filtering and routing, and attempts delivery to the subscriber's handset via its signaling network.
3. Handset delivery. The phone acknowledges receipt to the network. The carrier generates the delivery confirmation and passes it back up the chain, arriving at your platform as the DLR.
4. Failure paths. If the phone is off or out of coverage, the carrier retries for a validity period (commonly up to about 72 hours, configurable) before reporting expiration. Invalid numbers, filtering, and policy blocks produce failure statuses instead, sometimes immediately.

The plumbing between providers and carriers commonly speaks SMPP (Short Message Peer-to-Peer), the long-standing industry protocol, whose receipt format defined the status vocabulary most platforms still surface; web APIs translate the same states into friendlier webhook payloads.

The status vocabulary, translated

Status (SMPP-style)	Plain meaning	What it actually asserts
DELIVRD / delivered	Handset confirmed receipt	The message reached the device; nothing about reading
ACCEPTD / sent	Accepted by the carrier	In transit; final outcome unknown yet
ENROUTE	Moving through the network	Interim state, normal for seconds to minutes
UNDELIV / undelivered	Delivery failed	Invalid number, filtering, or network refusal, see error codes
EXPIRED	Retries ran out	Phone unreachable for the whole validity period (off, no coverage)
REJECTD / rejected	Carrier refused it	Policy, filtering, or registration problem; investigate, do not just retry
UNKNOWN	No definitive answer	Some routes and destinations simply do not report reliably

Providers attach error codes to failures (invalid destination, carrier block, spam filtering, roaming issues); the codes vary by provider and carrier but are the difference between "delivery rate dipped" and "T-Mobile is filtering our shortened links," so surface them, do not average over them.

The honest limits of delivery receipts

Four caveats keep DLR data honest:

• Delivered is not read. SMS has no read receipts; a DLR ends at the device. Reading, attention, and action are inferred from replies and clicks, not receipts.
• Not all "delivered" is handset-confirmed. Some routes report intermediate receipts, the carrier accepted the message, upgraded optimistically to delivered. Cheap gray routes are notorious for flattering receipts; ask providers whether DLRs are handset DLRs.
• Filtering can be quiet. Some filtering returns clean failure codes; some absorbs messages with a delivered status while the text never renders (content filtered downstream), and some destinations barely report at all. Corroborate DLRs with reply rates and link clicks; diagnosing gaps is the subject of the SMS deliverability guide.
• Timing is elastic. Receipts arrive seconds to hours after send, and expired statuses by definition arrive days later. Dashboards should treat delivery rate as settling over about 72 hours, not final at send time.

Putting DLRs to work

Receipts earn their keep in five operational loops:

1. True deliverability measurement. Track delivered, failed, and expired as distinct rates, per carrier and per campaign. A delivery rate that ignores expirations overstates reach; one that lumps rejections with dead phones hides fixable problems.
2. Fallback triggering. For messages that must arrive, appointment reminders, payment failures, critical notices, an undelivered or expired DLR should trigger the fallback: retry later, switch channel to email or voice, or flag for human follow-up.
3. List hygiene. Numbers that consistently return invalid-destination failures are dead: disconnections and typos. Automated suppression keeps you from paying to text the void and protects your sending reputation. Numbers reassigned to new owners are a consent problem as well as a delivery problem; US senders can check the FCC's Reassigned Numbers Database.
4. Filtering detection. A cluster of rejections or a delivery-rate drop on one carrier is the early-warning signature of content filtering or a registration issue (10DLC campaign mismatch, unregistered route). DLR monitoring catches it in hours; complaint-driven discovery takes weeks.
5. Compliance evidence. Delivery logs, receipts, timestamps, and message copies, document what was sent and what arrived, which matters when reminder programs face disputes. Platforms should retain DLR history alongside consent records.

For teams building on raw APIs, receipts arrive as callbacks or webhooks per message, and designing the handlers (idempotent, tolerant of late and duplicate receipts) is part of the integration work; the trade-offs are covered in the SMS API build-vs-buy guide. Teams on managed platforms should expect the same data surfaced as per-message status and exportable reporting, with the webhook plumbing hidden.

Reading a delivery report like an operator

A practical triage order when a campaign's numbers look wrong:

1. Delivered rate down, failures up with invalid-number codes: list decay; run hygiene.
2. Failures concentrated on one carrier with rejection codes: filtering or registration; check content (links, prohibited categories) and 10DLC campaign alignment.
3. Expired climbing: you are texting phones that are off, wrong hours for the audience, or a stale list segment.
4. Delivered flat but replies and clicks collapsed: suspect optimistic receipts or downstream filtering; test against real handsets on that carrier.
5. Everything unknown on an international destination: that route may simply not report; judge by engagement instead.

Frequently asked questions

What is an SMS delivery receipt (DLR)?

A DLR is a status notification returned by the carrier network after a message is sent, reporting the outcome: delivered to the handset, undelivered, expired after retries, rejected, or unknown. It is generated by the network infrastructure, not by the recipient.

Does "delivered" mean the person read my text?

No. SMS has no read receipts; a delivered DLR means the handset acknowledged receiving the message, nothing more. Reading and attention can only be inferred from behavior such as replies and link clicks.

Why do some messages show "sent" but never "delivered"?

"Sent" means the carrier accepted the message; final status may still be pending, and phones that are off or out of coverage keep the message in retry until it expires (commonly up to about 72 hours). Persistent sent-without-delivered patterns can also indicate quiet filtering or routes that report poorly.

What causes an SMS delivery failure status?

The usual suspects: invalid or disconnected numbers, carrier spam filtering, registration problems (such as 10DLC campaign mismatches), prohibited content or links, roaming and coverage gaps, and expired retries on unreachable handsets. Provider error codes distinguish the cases; read them per carrier rather than averaging.

How should organizations use delivery reports?

Four loops: measure real deliverability per carrier and campaign, trigger fallbacks (retry or channel switch) for must-arrive messages, automatically suppress dead numbers, and monitor failure codes as an early-warning system for filtering. Retained DLR logs also serve as delivery evidence.

Conclusion

The delivery receipt is SMS telling you the truth about itself, partially. It will confirm the handset, name the failure, and time-stamp the outcome, and it will never tell you about reading, and occasionally flatter you on filtered routes. Treat DLRs as instrumentation: read the statuses separately, corroborate with engagement, wire the failures to fallbacks and hygiene, and your delivery rate stops being a vanity number and starts being an operations tool.

Want delivery visibility without building the plumbing? Contact the FRANSiS team to see per-message status, failure handling, and deliverability monitoring built into an organizational messaging platform.