SMS Delivery Receipts Not Arriving: Tracing DLR Failures on a Multi-Port Gateway

Delivery receipts that never arrive are usually reported as a messaging failure and are often nothing of the kind. The message frequently reached the handset while the receipt was lost on the way back, which makes the fault a reporting problem rather than a delivery one.

This guide traces the receipt path end to end: what a receipt actually confirms, the three places it can be lost, how to establish whether the message was accepted at all, the flags that decide whether a receipt is generated, and the identifiers you need in order to correlate anything at volume.

What does a delivery receipt actually confirm?

That the network reported an outcome, not that it was read.

A delivery receipt confirms the status the network assigned to the message, which in most cases means it reached the destination equipment, and it says nothing about whether anyone opened it.

This distinction determines what an absent receipt means. Where receipts are missing across a whole campaign, the likely cause is configuration or a lost return path rather than a delivery failure, because a delivery failure would produce receipts with failure statuses rather than no receipts at all. The status report mechanism itself is part of the short message framework defined in ETSI TS 123 040 and its 3GPP counterpart 3GPP TS 23.040, and reading the status semantics there is quicker than inferring them from behaviour.

The practical consequence is that the absence of a receipt and the presence of a negative receipt are different observations with different remedies. Conflating them sends teams to investigate delivery when they should be investigating reporting.

Where can a receipt be lost?

Before submission, inside the network, or in your parser.

A receipt can fail to be requested, fail to be generated by the network, or be generated and lost between the network and your application.

The first is a configuration matter. If the submission does not ask for a receipt, none will come, and no amount of investigation downstream will find one. The second is outside your control and is the reason receipts are best treated as best-effort: not every network generates a status report for every message, and some generate one only on certain outcomes. The third is where most multi-port deployments actually lose receipts, because a parser that handles one format well can silently discard another.

A fourth possibility is worth keeping in mind even though it is not a place so much as a timing effect: the receipt can arrive after the investigation has finished. Some networks report an outcome minutes or hours later, particularly for messages that were retried internally, so a check performed two minutes after submission can conclude that no receipt will arrive when one is still in progress. Where the deployment’s receipts usually arrive within seconds, a delayed one looks exactly like a lost one until it appears.

Separating the three is a matter of testing the path in stages. Submit one message with receipts explicitly requested to a destination you control, watch the gateway’s own record, then watch what arrives at your application. Where the gateway recorded a receipt and the application did not, the fault is in transfer or parsing rather than in the network.

Where it is lost	Evidence	Who can fix it
Not requested at submission	No receipt recorded anywhere, including the device	Your configuration
Not generated by the network	Other messages at the same time do produce receipts	The operator, if at all
Lost between gateway and application	Device record present, application record absent	Your middleware
Discarded by the parser	Format differs from the one the parser expects	Your middleware

Was the message accepted at all?

Check the submit response before the receipt.

The submission itself returns an outcome, and that outcome tells you whether the network accepted the message for onward delivery — which is a different question from whether it was delivered.

Teams frequently skip this step because the submission always succeeds in normal operation, and then treat the missing receipt as the first evidence of a problem. In practice the submit response is the earlier and cheaper signal: if submission failed, no receipt was ever going to arrive, and the receipt path is irrelevant. If submission succeeded and no receipt followed, the message may still have been delivered.

Record both outcomes separately. A single delivery-status field that merges submission and receipt information cannot distinguish an acceptance problem from a reporting problem, and that ambiguity is what makes these investigations long. Sending a test to a number you control, and confirming arrival independently of the receipt, is the fastest way to establish whether delivery is actually affected.

Registered delivery flags and their defaults

The request for a receipt is a flag, and its default is not always on. Where the flag is unset, the network has no reason to generate a status report, and the deployment experiences what looks like total receipt loss while delivery continues normally. Defaults vary between platforms and between client libraries, so the value that matters is the one in force rather than the one in the documentation.

Two related settings change the behaviour further. Some platforms request receipts only for failures, on the reasonable assumption that success is the norm, which produces exactly the pattern most likely to be misread as delivery failure. Others request receipts for every message, which raises the volume of returning traffic and makes correlation harder at scale.

Confirm what the deployment requests, then confirm that the request survives every path into the platform. A deployment with several submission paths — an API client, a scheduling tool and a manual interface — often has different flag settings on each, which is why the symptom appears to come and go depending on which path sent the message. Where the equipment itself exposes the underlying command set, the relevant specifications are 3GPP TS 27.005, which covers the command interface for short messages.

The receipt formats you will see

Three formats, and they do not look alike. A protocol-level submission returns a status report as a structured message with its own fields. An HTTP callback delivers a request to an endpoint with parameters. A management interface displays a record intended for a person.

The format matters because middleware written for one will usually not handle another, and a deployment that adds a path without adding a parser experiences partial receipt loss that correlates with the path rather than with the destination. Where the equipment exposes several of these at once, a useful test is to send to the same destination through each path and compare what each one records.

Normalise the identifiers and the status values at the point of entry rather than deep in the application. Recipient addresses should be stored in the form described by the ITU-T E.164 numbering plan, and status values should be mapped to a single internal scale, so that reports from different paths can be compared without a translation layer in every consumer.

How do you correlate receipts to message IDs at volume?

By storing your own identifier alongside every other one.

At volume, the only reliable correlation key is one you generate and keep, because the identifiers assigned by each layer differ and are not always returned unchanged.

Record the client reference at submission, the identifier the platform returns, and the identifier the network uses, and keep all three in one row. Where a receipt arrives carrying one of them and not the others, the row can still be found. Where only the network identifier is stored, a receipt arriving for an unknown identifier is unassignable, and the message becomes one of the missing ones even though the receipt arrived.

Duplicate receipts are the second volume problem. Retransmission is normal, so the same outcome can be reported more than once, and a system that counts receipts as deliveries inflates its own figures. Deduplicate on the message identifier and keep the first outcome unless a later one contradicts it, in which case keep both and note the sequence.

Where the network reports a failure, the cause codes belong to the operator’s vocabulary, and ITU-T Q.850 is a useful reference for interpreting them when a support conversation requires it. Getting the terms right is usually what turns a vague report into an answerable question.

What to log so an SMS delivery receipt failure on a multi-port gateway is provable

Log the request and the outcome and keep them joined. For every message, record the submission timestamp, the destination in normalised form, the receipt request flag, the submission outcome, the client reference, the platform identifier, the network identifier, and any receipt received with its own timestamp.

That set makes the question answerable in one query: was a receipt requested, was the message accepted, and did anything come back? The fields are unexceptional individually and decisive collectively, and guidance on the retention and structure of operational records is available in NIST SP 800-92.

Two details make the record survivable. Keep the raw receipt payload alongside the parsed fields, because a parser change that fixes a mapping problem will not recover data it already discarded. And keep the flags per message rather than per deployment, since a dropped flag on one submission path is exactly the kind of partial failure this record exists to expose.