# DLR decoder.

- Canonical URL: https://www.broadnet.me/tools/dlr-decoder
- Language: en
- Last updated: 2026-10-21
- Publisher: BroadNet (https://www.broadnet.me)
- Markdown version of the page above, generated from the rendered page.

SMPP v3.4 · runs in your browser

Paste an SMPP delivery receipt or pick a stat value to decode what actually happened to a message — the final message state, the err code, and every parsed field. Based on the SMPP v3.4 receipt format.

Pick a stat value

8 fields parsed

| Field | Value |
|---|---|
| id | 0B7A2F91 SMSC message ID — matches the message_id returned in submit_sm_resp. |
| sub | 001 Number of short messages originally submitted. |
| dlvrd | 001 Number of those messages delivered. |
| submit date | 2407181432 → 2024-07-18 14:32 When the SMSC accepted the message (YYMMDDhhmm). |
| done date | 2407181433 → 2024-07-18 14:33 When the message reached its final state (YYMMDDhhmm). |
| stat | DELIVRD Final message state — the headline delivery status. |
| err | 000 Network/SMSC error code — vendor-specific; 000 usually means no error. |
| text | Your verificatio First 20 characters of the original message body. |

Message state

DELIVRD Delivered

message_state = 2 Final

The message reached the destination handset and the SMSC received positive acknowledgement from the network.

Success. This is the only stat that confirms handset delivery. Reconcile it against the message_id returned in submit_sm_resp.

err field

000 No error

SMPP v3.4 does not standardise err values — they are network- or SMSC-specific. Look up any non-zero code in your provider's documentation.

The short answer

## What is an SMPP delivery receipt?

A delivery receipt (DLR) is a status report the SMSC returns over SMPP in a deliver_sm PDU, telling you the final fate of a message you submitted. Its short_message field follows the informal format in SMPP v3.4 Appendix B — a run of key:value pairs. The headline is the stat keyword, which maps to one of seven message states. You only receive a DLR if you asked for one via registered_delivery on submit_sm.

### The seven SMPP v3.4 message states

| stat | state | Meaning | Final? |
|---|---|---|---|
| DELIVRD | 2 | Delivered | Final |
| EXPIRED | 3 | Expired | Final |
| DELETED | 4 | Deleted | Final |
| UNDELIV | 5 | Undeliverable | Final |
| ACCEPTD | 6 | Accepted | Transient |
| UNKNOWN | 7 | Unknown | Transient |
| REJECTD | 8 | Rejected | Final |

## Frequently asked questions

**What is an SMPP delivery receipt (DLR)?**

A delivery receipt is a status report the SMSC sends back over SMPP in a deliver_sm PDU, telling you the final fate of a message you submitted. Its short_message field follows the format in SMPP v3.4 Appendix B, carrying fields like id, stat and err. It arrives only if you requested it via registered_delivery on submit_sm.

**What does stat:DELIVRD mean?**

DELIVRD (message_state 2, DELIVERED) means the message reached the destination handset and the network acknowledged it. It is the only stat value that confirms handset delivery — a successful submit_sm_resp on its own does not.

**What is the err field?**

err is a short network- or SMSC-specific error code explaining why a message failed. SMPP v3.4 does not standardise its values, so the exact meaning depends on your operator or aggregator. A value of 000 (or 0) generally means no error; look up any non-zero value in your provider's documentation.

**Which statuses are final and which can still change?**

DELIVRD, EXPIRED, DELETED, UNDELIV and REJECTD are final — the message will not be retried. ACCEPTD and UNKNOWN are non-final: the message may still resolve to a different state, so do not count them as delivered.

**Why do the id in the DLR and the submit response sometimes look different?**

Some SMSCs return the submit_sm_resp message_id in decimal and the DLR id in hexadecimal (or vice versa), and intermediate aggregators may rewrite IDs entirely. If you cannot correlate them directly, ask your provider which representation they use, or track your own client-side reference.

**Does a successful submit_sm_resp mean the SMS was delivered?**

No. ESME_ROK on submit_sm_resp only confirms the SMSC accepted the message for processing. Final delivery to the handset is reported separately by the DLR, which carries its own stat such as DELIVRD or UNDELIV. Treat submit acceptance and delivery as two different layers.

**Are these stat values the same across every SMSC?**

The seven keywords and their message_state numbers are defined by SMPP v3.4 and are widely honoured. However, some SMSCs emit additional vendor-specific keywords or reuse the text field differently, so always confirm edge cases against your provider's own delivery-receipt documentation.

[SMS API REST + SMPP 3.4, Bearer-token auth, delivery webhooks.](https://www.broadnet.me/products/sms-api) [SMSC Gateway Carrier-grade SMSC over SMPP + SS7.](https://www.broadnet.me/operators/smsc-gateway) [Developer hub Quickstart, TypeScript SDK, references and tools.](https://www.broadnet.me/developers)

## Want clean, reliable DLRs?

BroadNet delivers real, end-to-end delivery receipts over direct SMPP 3.4 binds and delivery webhooks — not guesses. Talk to our team about routing.

[Developer hub](https://www.broadnet.me/developers) [SMS API](https://www.broadnet.me/products/sms-api)