Sending an SMS is only half the job: the other half is knowing what happened to it. That information arrives in the delivery report (DLR), which states each message’s final status with standardized codes such as DELIVRD or UNDELIV. Understanding them is the difference between guessing and operating with data. Knowing your SMS delivery statuses lets you act before the customer complains.
Where the statuses come from
The SMPP protocol defines a set of states for each message, and by convention delivery reports include text in this format, which has become the industry’s de facto standard:
id:a1b2c3d4 sub:001 dlvrd:001 submit date:2611091432 done date:2611091432 stat:DELIVRD err:000Platforms offering a REST API map those same statuses to their webhooks, so the meaning is the same however you integrate. We explain it in what a webhook is and how to receive DLRs.
What each status means
| Status | Meaning | What to do |
|---|---|---|
DELIVRD | Delivered to the handset | Nothing: log the delivery and how long it took |
ENROUTE / ACCEPTD | In transit or accepted, without final confirmation | Wait for the final status; if it never comes, do not assume delivery |
UNDELIV | Permanently undeliverable: non-existent, inactive or network-rejected number | Do not retry the same number; flag it for review or cleanup |
EXPIRED | The validity period ran out before delivery, for example with the phone off or out of coverage | For critical messages, resend later or use an alternative channel |
REJECTD | Rejected before delivery was attempted | Review content, sender or destination restrictions |
DELETED | Deleted before delivery | Check with your provider |
UNKNOWN | The status could not be determined | Treat it as unconfirmed |
Besides the status, the err field usually carries a network- or platform-specific error code, useful to tell, for instance, a non-existent number from a suspended line.
Common mistakes when reading statuses
- Confusing “sent” with “delivered”. The API accepting a message does not mean it arrived; only the DLR confirms it.
- Retrying UNDELIV numbers. It only adds cost; those numbers should be cleaned up.
- Ignoring EXPIRED. For OTPs and alerts, an expired message is a user who did not receive something important.
- Not measuring times. The gap between send and delivery time reveals delays by destination or time of day.
How to use statuses in your operation
- Track delivery rate by message type and destination.
- Trigger an alternative channel when an OTP ends in EXPIRED or UNDELIV.
- Clean your database regularly using UNDELIV numbers, especially with Mexico’s CURP line registration under way.
- Keep reports as evidence for customer service and audits.
See also why an SMS is not delivered. At Grupo Tecnophone delivery reports are available in real time via webhook in our SMS API and as deliver_sm over an SMPP connection, at no extra cost. Talk to our team.
Sources
- “SMPP Delivery Receipt Format”, smpp.org. Read source
- “Short Message Peer to Peer Protocol Specification v3.4 (Issue 1.2)”, SMPP Developers Forum. Read source
