Everything worth knowing, nothing that isn't.
What 'delivered' actually means
DELIVRD means the recipient's MSC has reported successful radio delivery to the handset — the network is satisfied. It does not mean the user read the message, opened the messaging app, or even had their screen on. Treat DLR as a network-level acknowledgement, not a read receipt. (For read receipts, use RCS or WhatsApp.)
The error codes you actually see
GSM Cause Codes 1–127 are the protocol-level reasons (absent subscriber, equipment failure, etc.). SMPP error codes 0x0000–0x00FF are the SMPP-level reasons (invalid source address, congestion). Operator-specific TLVs sometimes carry richer context (radio out of coverage, handset memory full). A good aggregator translates the noisy operator codes into a clean error taxonomy you can act on. BroadNet's DLR feed normalises across 200+ operators into a 25-code error vocabulary.
Why DLRs come back late
Many reasons. Roaming subscriber off-network for hours. SMSC store-and-forward retrying for the validity period (default 24 hours; up to 72 hours for some carriers). Operator A2P routing path going through three intermediate SMSCs each adding their own queue delay. Mature monitoring tracks DLR latency p50/p95/p99 by destination operator and alerts when a route degrades — see /products/dlr-monitoring patterns.
What to do with the DLR
Three actions. Mark the message as delivered/failed in your system of record. Trigger downstream business logic (cart recovery flow continues, OTP retry kicks in). Feed it back into a route-quality scoreboard so your aggregator can rebalance. The third is what separates a CPaaS from a wire — BroadNet uses your DLRs to drive route selection in real time.