SMS Delivery Receipt Statuses

When your platform reports that a message was "delivered," it is tempting to treat that as confirmation the recipient saw it. In practice, an SMS delivery receipt (DLR) is a far more limited signal than its label suggests — and misreading it can distort your campaign analytics, lead to unnecessary retries, or create false confidence in your outreach.

This article explains exactly what a DLR is, what each status code means, what "delivered" actually proves and does not prove, why status reliability varies across carriers and number types, and how to handle failed and undelivered messages correctly.

What is an SMS delivery receipt (DLR)? A delivery receipt is a status callback generated by the carrier network — specifically the Short Message Service Centre (SMSC) — that reports the disposition of a message after it leaves the sending platform. DLRs confirm whether the SMSC accepted the message, whether it was handed off to the destination handset, or whether it failed permanently or expired without delivery. They do not confirm that the recipient opened, read, or acted on the message; no SMS standard provides read receipts.

The Message Journey and Status Checkpoints

An SMS message passes through several systems between the moment your application submits it and the moment it appears on a recipient's device. Each handoff point produces a status event that your platform may expose. Understanding the sequence makes each status meaningful.

Queued

The message has been accepted by your sending platform or CPaaS provider and placed in an outbound queue. It has not yet been submitted to the carrier SMSC. This state is entirely internal to the sending platform. It often reflects brief throttling when large volumes are submitted simultaneously, or when the carrier's ingestion endpoint is momentarily saturated. A message in queued state has not yet touched the carrier network.

Sent (Submitted)

The message has been handed off to the carrier SMSC. This is a significant milestone — the carrier has accepted responsibility for delivery — but it explicitly does not confirm that the message reached the recipient's handset. "Sent" in SMS terminology means submitted to the SMSC, not delivered to the device. Many platforms label this state "submitted" to reduce confusion, but "sent" is the more common term in CPaaS dashboards.

If a DLR is never returned after this point, the outcome is unknown. The carrier may have delivered the message silently, the message may still be in transit, or the carrier may not support DLR callbacks for that destination.

Delivered

The destination handset sent an acknowledgment back to the SMSC confirming it received the message, and the SMSC forwarded that acknowledgment to your platform as a positive DLR. This is the strongest confirmation the SMS protocol can provide. It means the message arrived at the device layer.

However, "delivered" has important limitations that the next section addresses in detail.

Failed

The message encountered a permanent, unrecoverable error. Common causes include an invalid or non-existent destination number, a carrier-level rejection due to content filtering or spam classification, a number that has been ported out and is now inactive, or a destination that explicitly blocks the sender. Failed messages should not be retried — the underlying condition will not resolve on its own. The appropriate response is to flag the number for suppression, investigate the error code returned, and, if a spam filter triggered the failure, review the message content and sender registration.

Undelivered

The message was submitted to the carrier SMSC and accepted, but the SMSC did not receive a delivery acknowledgment from the destination handset within the message's validity period (typically 24 to 72 hours, depending on carrier settings). Undelivered is frequently a temporary condition: the recipient's device may have been powered off, out of coverage, or otherwise unreachable. The SMSC queues undelivered messages and retries delivery when the device comes back online, up to the validity period limit.

When the validity period expires without a successful delivery ack, the SMSC reports the message as undelivered and stops retrying. At that point the status is final — but during the validity window, an undelivered message may still deliver. This is an important distinction from Failed: undelivered is a timeout, not a permanent rejection.

What "Delivered" Actually Proves — and What It Does Not

A delivered DLR confirms that the SMSC received an acknowledgment from the destination handset indicating the message was received at the device layer. This is meaningful: it tells you the message is not sitting in a carrier queue, it did not bounce on a bad number, and it was not rejected by a spam filter.

What a delivered DLR does not prove:

It does not confirm the recipient read the message. SMS has no read-receipt mechanism in the standard protocol. The delivery acknowledgment is generated by the mobile device's messaging layer when it accepts the incoming message segment — not when the user opens the messaging app or reads the content.
It does not confirm the number is actively used. A number assigned to a device that is powered on and connected will generate a delivery ack even if that number belongs to someone who no longer uses that device, has changed SIMs, or has that device set to silent indefinitely.
It does not confirm message content was rendered correctly. Character encoding issues, unsupported characters, or message segmentation problems may result in a garbled message that still generates a delivered DLR.

There is an additional complication with international destinations: some carriers in certain regions return synthetic delivery receipts — DLRs generated by the carrier's gateway without a real handset acknowledgment. These carriers report "delivered" based on their own internal queue acceptance, not on an actual device-level confirmation. This means a delivered status from certain international routes may carry much less certainty than the same status from a US Tier 1 carrier.

The practical implication: treat delivered as "the message almost certainly arrived at the device" rather than "the recipient saw it." For engagement measurement, use click-through rates, reply rates, or conversion events — not DLR status alone.

Intermediate vs Final States

DLR statuses fall into two categories: intermediate and final.

Final states are terminal — the message's lifecycle is complete and no further status updates will arrive. Delivered and Failed are final states. Once a message reaches either, no additional DLR callbacks will be issued for that message.

Intermediate states indicate the message is still in transit or being processed. Queued and Sent are intermediate. Some carriers emit additional intermediate callbacks, such as "accepted by carrier" or "queued at SMSC," before eventually settling on a final state. These can be useful for distinguishing between "the platform hasn't submitted it yet" and "the carrier has it but hasn't delivered it," but they should not be treated as outcome confirmations.

If your webhook endpoint receives an intermediate status, the message's story is not over. Build your workflow logic to wait for a final state before making downstream decisions — suppressing a contact, logging an outcome, or triggering a fallback channel.

One nuance: Undelivered occupies a grey zone. When first set, it may be intermediate (the message is still within its validity window and still queued for retry at the SMSC). When returned after the validity period has expired, it is effectively final. Some platforms emit an Undelivered callback only after the validity period expires; others emit it each time a retry fails. Check your platform's documentation to understand which model it uses.

Why DLRs Differ Across Carriers and Countries

DLR reliability is not uniform. Several factors determine how trustworthy the status you receive actually is.

US Tier 1 carriers

AT&T, Verizon, and T-Mobile support genuine device-level DLR acknowledgments for messages delivered to their subscribers. When one of these carriers returns a delivered status, it reflects a real handset ACK propagated back through the SMSC chain. DLR reliability on these networks is high for compliant, registered senders.

International carriers

DLR support varies widely outside the US. Carriers in some regions return genuine device-level ACKs; others return synthetic DLRs at the gateway; others return no DLR at all, leaving the sending platform to either assume delivery or report the message as unknown. When sending internationally, higher delivered counts do not automatically indicate better actual delivery — it may simply reflect a higher proportion of routes that generate synthetic acknowledgments.

Number type affects DLR reliability

The type of sender number also influences DLR fidelity:

Short codes (5–6 digit numbers) are provisioned specifically for application-to-person (A2P) messaging and generally receive the most reliable DLR handling from US carriers. The dedicated provisioning relationship between the short code and the carrier creates a well-defined delivery path.
10DLC numbers (10-digit long codes registered for A2P use) have improved DLR reliability substantially since carrier-mandated A2P registration was introduced. Unregistered long codes historically experienced higher filtering rates and less consistent DLR reporting.
Toll-free numbers verified for SMS use also offer reasonably reliable DLR handling for A2P traffic, though delivery rates can differ from short codes in some scenarios.
Unregistered long codes sent through standard person-to-person (P2P) paths are subject to carrier filtering and may see inconsistent DLR reporting.

Handling Failures and Undelivered Messages

Not every non-delivered message warrants a retry, and not every retry warrants the same approach. A structured handling policy reduces carrier complaints, avoids re-messaging opted-out contacts, and keeps your sender reputation intact.

Distinguish failed from undelivered before retrying

Failed messages should go to suppression, not retry. The carrier or SMSC has rejected the message for a reason that will not change — an invalid number, a hard content rejection, or a spam block. Retrying a failed message with the same content to the same number typically results in another failure and may worsen your sender reputation.

Undelivered messages are candidates for retry, but with limits. The device may come back online. A reasonable retry policy caps retries at two or three attempts, uses exponential backoff between attempts (for example: 15 minutes, then 1 hour, then 4 hours), and abandons further attempts if the message remains undelivered after the validity period.

Check opt-out status before any retry

Before retrying an undelivered message, verify that the recipient has not submitted an opt-out request. An STOP response may have arrived while the original message was in flight. Retrying to an opted-out number is both a compliance risk under TCPA and a potential carrier complaint trigger.

Consider a fallback channel

If a message remains undelivered after exhausting retries, evaluate whether a fallback channel is appropriate for the use case. A time-sensitive appointment reminder that went undelivered via SMS may warrant an email fallback if you have a valid address. Promotional content generally should not be escalated to an alternate channel without separate consent for that channel.

Suppress after hard failure

Add numbers that return permanent failure codes to a suppression list immediately. Continuing to send to invalid or carrier-rejected numbers raises your failure rate, which is a signal carriers use when evaluating sender trustworthiness.

DLR Webhooks

Most CPaaS platforms deliver DLR status updates via HTTP webhook callbacks rather than requiring you to poll an API. When a message status changes — from Sent to Delivered, for example — the platform makes an HTTP POST request to a URL you configure, containing the message ID, the new status, and any error codes.

Key considerations for DLR webhook implementations:

Idempotency: Platforms may retry webhook delivery if your endpoint returns a non-2xx response or times out. Your endpoint should handle duplicate callbacks for the same message ID without double-processing.
Response time: Return a 200 OK quickly — before doing heavy processing. If your endpoint takes too long to respond, the platform may treat the delivery as failed and retry. Enqueue the event and process asynchronously.
Status ordering: Webhooks do not always arrive in chronological order. A Delivered callback may arrive before a Sent callback due to network timing. Use the timestamp in the payload, not arrival order, to sequence events.
Signature verification: Most platforms sign webhook payloads with an HMAC signature. Verify this signature before processing to prevent spoofed status updates.
Platform retry behavior: If your endpoint is unavailable (500 error, timeout, network issue), the platform will typically retry the webhook several times with backoff before abandoning the delivery attempt. Design for endpoint availability — a missed DLR callback means a status you cannot act on.

Webhook-based DLR handling gives you near-real-time status visibility without polling overhead, but it requires a reliable, publicly accessible HTTPS endpoint on your side.

Frequently Asked Questions

Can I tell if someone read my SMS message? +

No. The SMS standard does not include a read-receipt mechanism. The delivered DLR confirms the message arrived at the device layer — it is generated by the device's messaging subsystem when the message is received, not when the user opens the app or reads the content. There is no SMS protocol equivalent of email read receipts. If you need to measure engagement, track click-through rates on links within the message, monitor reply rates, or measure downstream conversion events.

What is the difference between undelivered and failed? +

Failed is a permanent rejection — the carrier or SMSC determined the message cannot be delivered and will not try again. Typical causes include an invalid or disconnected number, a content-based spam block, or a carrier-level sender rejection. Undelivered means the message was accepted by the carrier SMSC but no delivery acknowledgment was received from the handset within the message's validity period. Undelivered is often a temporary condition (device offline, out of coverage) that may still resolve before the validity period expires. Failed messages should go to suppression; undelivered messages may be retried with appropriate limits.

Why do some international messages show "delivered" immediately? +

Some international carriers generate synthetic DLRs — delivery receipts produced at the carrier's gateway level rather than based on a real handset acknowledgment. These carriers report "delivered" as soon as they accept the message into their own network, without waiting for confirmation from the destination device. The result is an immediate delivered status that does not actually reflect device receipt. When you see implausibly fast delivered callbacks on international traffic — or unusually high delivered rates on routes known for poor coverage — synthetic DLRs are a likely explanation. This is a limitation of the global SMS ecosystem, not a platform error.

How long does a carrier retry an undelivered message? +

The retry window is determined by the message's validity period, which is typically set when the message is submitted. Common values are 24 hours, 48 hours, or 72 hours. During this window, the SMSC queues the message and retries delivery whenever the destination device reconnects to the carrier network. Once the validity period expires without a successful delivery acknowledgment, the SMSC stops retrying and reports the final undelivered status. Some platforms allow you to configure the validity period at submission time; shorter windows reduce the chance of a stale message delivering after it is no longer relevant.

Do DLR webhooks always arrive in order? +

No. Webhook callbacks can arrive out of chronological order due to network latency differences between the carrier network and your endpoint, platform retry behavior, and the asynchronous nature of the callback chain. A Delivered webhook may arrive before a Sent webhook for the same message. Do not rely on arrival order to sequence status events. Instead, use the event timestamp included in the webhook payload to determine the correct order, and design your status-tracking logic to handle out-of-order updates gracefully — for example, by only updating a stored status if the incoming event's timestamp is later than the last recorded update.

Understanding delivery receipts is one layer of a broader business SMS strategy. For a complete guide to sending business text messages — including consent requirements, number types, and 10DLC registration — see Business SMS: The Complete Guide. If you are deciding between SMS and MMS for specific use cases, SMS vs MMS for Business covers the protocol differences, content capabilities, and cost considerations for each. For opt-out keyword handling and how it intersects with delivery status, see SMS STOP and HELP keywords. And for understanding how encoding affects message cost and segment count, see SMS character limits, encoding, and segments.

SMS Delivery Receipts: Delivered, Failed, and Undelivered Explained