DLR fabrication: how to tell real delivery from aggregator theatre

DLR fabrication: how to tell real delivery from aggregator theatre

A delivery receipt is a factual claim: this message was delivered to this handset at this time. In the A2P SMS industry, that claim is often partially true, frequently exaggerated, and occasionally invented. The difference between a genuine handset-level delivery report and a fabricated one is not visible in the JSON payload that lands on the application's webhook. It is visible in the statistics of many payloads read together, and it is visible at the signalling layer that the aggregator did not show you.

This post describes what an honest DLR actually reports, the four classes of receipt that all tend to be called "delivered," the statistical fingerprints of fabrication, and why the distinction matters for any authentication or notification flow that depends on the receipt being true.

The four classes of "delivered"

The word "delivered" in A2P SMS covers four meaningfully different states.

Class one (accepted at the SMSC): the application submitted the message, the SMSC acknowledged receipt, and the SMSC took responsibility for onward delivery. This is almost always what a basic SMPP submit_sm_resp indicates. It is an acceptance acknowledgement rather than a delivery receipt. Many dashboards that display a "99% delivery rate" are showing the submit_sm_resp success rate and labelling it as delivery.

Class two (buffered by the terminating network): the originating SMSC handed the message off to a terminating network's SMSC, and the terminating SMSC accepted it. This is the second-hop acknowledgement. It confirms the message has reached a network that can potentially deliver it. It does not confirm the handset has received anything.

Class three (delivered to the SMSC of record): the terminating operator's SMSC has the message and is ready to attempt delivery to the handset. In some operator implementations, this is reported as a delivery receipt. It is an intent-to-deliver notification rather than a completed delivery.

Class four (delivered to the handset): the MAP MT-Forward-SM operation returned success to the originating network, which means the subscriber's MSC delivered the message to the handset and the handset acknowledged receipt at the RP layer. This is the only class that reflects a true end-to-end MAP delivery event. It is the class an authentication flow needs if it is going to use "delivered" as a precondition for anything that matters.

The gap between class one and class four is where fabrication lives. An aggregator can report class one on the outbound leg and claim it is class four. If the terminating network is opaque to the aggregator (because the route is grey, because the aggregator does not have a direct SMPP session with the terminating SMSC, or because the route goes through two or three intermediate aggregators), class four simply is not observable. The report is either a probability estimate, a default assumption, or an outright fabrication.

What an honest receipt contains

A receipt that reflects a MAP MT-Forward-SM delivery carries a specific set of fields. The originating network has a timestamp for when the terminating MSC returned RP-ACK, a state code indicating handset-level success or a specific failure reason, and in some implementations the cell or location area at which delivery occurred. These fields are produced by the signalling layer, not by a heuristic applied at the aggregator level.

The MAP operation itself is well documented: SRI-for-SM returns the serving MSC's global title, the SMSC forwards the message via MT-Forward-SM to that MSC, and the MSC either delivers it and acknowledges, or fails and returns a reason code. The protocol is not secret and has not changed in its fundamentals since the SS7 specifications of the 1990s. Anyone who has direct SS7 or SIGTRAN connectivity, with a signalling point code of their own, can observe these operations as a first-class participant.

Aggregators without such connectivity are observing the system from above. They see what their upstream reports, and they either pass that report through with integrity or they synthesise a report that looks plausible. The synthesis is the fabrication risk.

Statistical fingerprints of fabricated DLRs

Fabricated DLRs leave statistical traces even when each individual report looks fine. Several of these traces are documented in engineering practice and form the basis of any serious DLR-integrity audit.

Latency distribution: a genuine handset-level DLR has a latency shaped by the physical reality of paging, handset ACK, and network-to-network signalling roundtrip. The distribution has a floor around a few hundred milliseconds and a long tail extending into seconds when the handset is in a poor coverage area or in power-saving mode. Fabricated DLRs often have an implausibly tight distribution, like a narrow band clustered on a round number such as five seconds, or a suspiciously uniform distribution across a range, because they are generated by a timer rather than by a signalling event.

Error-code entropy: a genuine delivery path produces a rich mix of failure reasons including subscriber absent, subscriber busy, handset memory full, equipment detached, and delivery failure at the radio link. Fabricated DLR streams tend to produce only two or three distinct failure codes, because the fabricator has coded a simplified state machine and did not bother to emit the full spectrum.

Time-of-day coupling: real delivery rates vary by time of day in predictable ways, driven by when subscribers are awake and when their handsets are on. Fabricated DLR streams are either suspiciously uniform across the day or have a synthetic diurnal curve that does not match the known subscriber distribution of the terminating network.

Geography coupling: real delivery rates vary by cell area, operator, and country. Fabricated streams tend to be either uniform across destination operators or to reflect the fabricator's idea of what the variance should look like, which often differs from the actual variance the terminating operator is reporting internally.

Receipt-without-signal correlation: the most direct fingerprint is a receipt that claims delivery on an MSISDN which, at the time of the claimed delivery, had no active IMS or circuit-switched registration. This is visible only from the operator side. If claimed delivery times can be cross-referenced against the HLR's record of the subscriber's attach state, a fabricated receipt may claim delivery at a moment the subscriber was not attached to the network. Aggregators cannot run this check because they cannot see the HLR attach state. Operators can.

None of these fingerprints are definitive on a single message. They are forensic at scale. If an application pipes its DLR stream into a monitoring pipeline and compares the distributions against expected shapes, the fabricated streams become visible. The audit pattern is the same one used in other telecom fraud research, where the signal lives in the distribution of many events rather than in any single event.

When aggregator DLRs are fine, and when they aren't

Not every aggregator-mediated DLR is fabricated. Many aggregators relay honest class-three receipts from their upstream and label them class three. The issue is the combination of opacity with commercial incentive, not universal dishonesty.

The commercial incentive is straightforward. An aggregator whose customers judge them on delivery rate has a reason to make the delivery rate look high. If the aggregator's route terminates through a chain of other aggregators, the original class-four information is not available, and the aggregator closest to the application has a choice: report the degraded information accurately and show a lower delivery rate, or report a confidently labelled "delivered" based on a probabilistic inference and show a higher delivery rate.

In markets with low information asymmetry, buyers push back and accurate reporting wins. In markets where every provider reports 98 percent delivery and the buyer cannot audit, the pressure runs the other way. SMS interconnect in emerging markets is often in the second regime. The literature on non-service-related SS7 signalling and on SMS integrity at the protocol level is consistent on the underlying point: the fidelity of a delivery receipt is a function of the path it came through, and paths that include intermediate aggregators are lower fidelity than paths that resolve at the home operator.

How TensorConnect ships delivery receipts

Tensormobile's A2P SMS delivery carries receipts with an explicit class label when Tensormobile is the terminating operator or has a direct SMPP session with the terminating operator. The class is one of: accepted, buffered, delivered-to-SMSC, or delivered-to-handset. Where class four is available (the home network, direct interconnects), the receipt carries the RP-ACK timestamp from the MSC, the reason code where failure occurred, and the terminating operator identity. Where class four is not available (routes that include intermediate aggregators), the highest observable class is reported and labelled as such, not as class four.

The integrator can configure the delivery pipeline to require class four for specific use cases such as an authentication flow that needs to confirm OTP delivery before timing out a login step, and to accept class three or lower for other use cases like a marketing broadcast where the buffered acknowledgement is sufficient. The distinction sits in the receipt structure rather than hidden behind a single "delivered: true" field.

The integrator can also pull the delivery-class distribution by route. That is the operator-side version of the statistical audit described above. If a route is producing 100 percent class-four receipts on traffic that cannot plausibly be resolving at the terminating network, the distribution makes the anomaly visible. If a route is producing the expected mix of class-four, class-three, and failure states, the distribution looks ordinary.

The specific claim worth making about TensorConnect's DLRs is narrow: they reflect MAP MT-Forward-SM handset acknowledgements where the delivery path is operator-direct, and each receipt is labelled with the class of information it represents. That claim is auditable. For applications whose downstream logic depends on the receipt (timeouts, fallbacks, retry schedules, fraud holds), class-labelled receipts mean the application knows what the underlying signal actually represents. Authentication flows in particular are sensitive to this. An OTP flow that uses a "delivered" signal to decide when to show a fallback input is only as correct as the signal it acts on.