How to Investigate DLR Discrepancies in A2P SMS Without Confusing Delivery with Human Receipt

The Right Question: What Does Each Piece of Evidence Actually Prove?

An investigation into A2P SMS DLR discrepancies begins by separating facts that are often combined into a single status field. Submission acceptance, progress through the delivery chain, the status reported by an SMSC, and an observation on a handset are not equivalent.

In SMPP, a successful submit_sm_resp indicates that the SMSC processed the operation and assigned a message_id. Something comparable happens in an HTTP API when a resource is created or accepted and an identifier is returned. This proves technical acceptance at that point in the chain, not delivery to the destination.

Subsequent statuses arrive asynchronously. In SMPP, an SMSC receipt may be received through deliver_sm or data_sm. That DLR represents the status maintained or reported by the SMSC. It must not automatically be attributed to the handset, the user, or every previous stage of the chain.

An independent observation—for example, receipt recorded by a controlled test device—is a separate type of evidence. It may support or contradict the DLR, but on its own it does not prove the identity of the person using the device or allow the result to be generalized to an entire route.

• API acceptance or submit_sm_resp: the receiving endpoint accepted or processed the request and returned an identifier.
• Temporary status: indicates progress, queuing, or transit; it does not necessarily close the lifecycle.
• Final DLR: a technical statement from the chain based on the semantics documented for the connection.
• Independent observation: a separate signal obtained outside the DLR flow; its method and scope must be documented.
• Human reading: cannot be universally inferred from an SMS DLR.

Why DELIVRD Does Not Prove Reading or Identity

SMPP includes DELIVERED among its states, but a traditional DLR may use text whose format is specific to the SMSC provider. The applicable specification and the official documentation for each connection must therefore be consulted before mapping values such as DELIVRD.

3GPP explicitly distinguishes receipt by the mobile station from delivery to the user. Even when mobile-station confirmation exists, it does not prove that a person saw, opened, or understood the message. SMS also does not universally provide read receipts.

A status reported as delivered may come from confirmation by an upstream operator and only include handset confirmation when it is available. The exact source must be retained with each event rather than transformed into a stronger claim.

It also does not prove the human identity of the recipient. A technical destination or device may receive the message without proving who controls the number, who is holding the handset, or who views the content. An OTP must be handled according to the service’s complete security design, not as proof of identity based solely on the DLR.

Another terminology mix-up should also be avoided: the SMPP ACCEPTED state does not mean ordinary reading or initial transport acceptance. The specification describes it as manual reading on behalf of the subscriber by customer service. Initial submission acceptance is recorded separately.

• Write “DLR reported as DELIVRD” rather than “user reached” when no additional evidence exists.
• Retain the provider, connection, and mapping version that converted the original value into an internal status.
• Do not present DELIVRD as proof of reading, identity, consent, or universal assurance of handset receipt.
• Keep delivered, device observation, and read separate when a channel supports read events.

A Minimum End-to-End Traceability Model

Reliable correlation requires a record for each logical message, each segment when concatenation is involved, and each event received. The internal identifier must be retained together with the message_id or identifier assigned by each SMSC, API, or partner. The id field in an SMPP DLR refers to the identifier assigned by the SMSC to the original submission.

Do not correlate exclusively by SMSC address. 3GPP warns that resilience and load-balancing architectures may cause a report to originate from an address different from the one used for the original submission.

Normalize records into a common schema, but preserve the original event and its source. Normalization makes queries easier; raw data allows parsing errors and format changes to be audited. The destination can be retained in a normalized E.164-based representation alongside the original value received.

Every timestamp must include its semantics, source, and explicit relationship to UTC through Z or an offset. Do not overwrite the provider-declared time with the callback arrival time. Keep the independent observation as a third timestamp as well. Before interpreting an impossible sequence, rule out misaligned clocks.

• Internal identifier for the logical message and identifier for each segment.
• Request identifier, SMSC or provider message_id, and event or callback identifier, when available.
• Local submission timestamp, source-declared timestamp, callback receipt time, and independent observation time.
• Time zone or offset, available precision, source system, and the clock that produced each timestamp.
• Provider, connection, declared route, original and normalized destination, observed or declared operator, and sender.
• Normalized content or a controlled fingerprint, encoding, length, and number of segments, according to the applicable retention policy.
• Original status and error, normalized internal status, and the version of the mapping applied.
• Attempt number, reason for retry, test or production environment, and analytical exclusions.

A Reproducible Discrepancy Taxonomy

Precise labels prevent observability problems from being prematurely attributed to the route. Each case should have a verifiable rule, a documented time window, and an investigation status.

The internal taxonomy must distinguish temporary, final, and inconclusive statuses. SMPP defines ENROUTE, DELIVERED, EXPIRED, DELETED, UNDELIVERABLE, ACCEPTED, UNKNOWN, and REJECTED, among others, but the effective semantics must be verified in the connection documentation.

• Missing: no correlatable DLR exists within the observed window. This does not automatically mean delivery failed.
• Duplicate: more than one copy of the same event or status is received. Deduplicate by identifier and time window before aggregation.
• Delayed: the DLR arrives after the expected timeframe for that operational segment, without changing the meaning of the status.
• Contradictory: two sources or final events assign incompatible outcomes to the same message or segment.
• Uncorrelatable: a DLR exists, but its identifier cannot be securely linked to the original submission.
• Invalid sequence: a transition violates the documented state machine, or the times appear impossible.
• Partial result: a concatenated message contains both successful and failed segments; this must not be hidden under a single simple outcome.
• Unknown taxonomy: a status or code appears that is not covered by the active mapping version.

Step-by-Step Investigation Procedure

First, define the incident without mixing different populations. Specify the start and end times, use case, destination, operator, sender, provider, connection, declared route, traffic type, encoding, and exact inclusion criteria. Also record the sample size and potential biases.

Next, validate observability. Confirm that the callback endpoint was reachable, persisted the request before responding, accepted the received schema, and returned a valid HTTP response. An overly strict validator may reject new fields. Review queues, ingestion errors, storage, retries, deduplication, and clock synchronization.

Then reconstruct the timeline for each message and segment: request, initial response, temporary statuses, final DLR, technical retries, and independent observation. Compare original and transformed values without blindly ordering events generated by different clocks.

Finally, assign the most likely domain: your own integration, observability, status mapping, provider connection, declared route, network, or destination. If the evidence does not isolate the issue, keep the classification as undetermined rather than forcing a cause.

• 1. Freeze the scope, query, and exclusions so the analysis is reproducible.
• 2. Select representative examples and retain their original records.
• 3. Verify callback receipt, response, and persistence.
• 4. Reconcile pending messages through the official query mechanism, if the connection provides one.
• 5. Correlate all identifiers without relying solely on the destination or SMSC address.
• 6. Review timestamps, offsets, clock drift, and the semantics of each time value.
• 7. Apply the correct mapping version and verify transitions.
• 8. Separate integration, route, and destination issues; document uncertainty and missing evidence.

Timeouts, Temporary States, and Operational Closure

An API, connection, or callback timeout does not prove that the SMS was not delivered. The operation may have continued after the response was lost. Look for a later receipt and, when officially supported, reconcile it through a status query.

Temporary errors and in-transit statuses must not be converted into final failures while the service center continues its attempts or the applicable validity period remains open. Likewise, a pending message must not be changed to delivered simply to complete a report.

Define a closure window tied to the use case and configured validity period. For an OTP, usefulness may end quickly even if the technical status arrives later. A non-urgent notification may allow a different window. Functional expiration, analytical closure, and technical status are separate fields.

TP-Discharge-Time must not always be interpreted as the time of successful delivery either: depending on the status, it may represent delivery, the last attempt, or the service center’s disposition of the message.

• Retain the original technical status after operational closure.
• Use the label “no DLR at closure” rather than automatically reclassifying the message as failed.
• Allow late reconciliation without silently rewriting reports that have already been issued.
• Version the closure logic and explain how it relates to validity and the use case.

Synthetic Testing and Production Traffic

Synthetic tests allow control over the device, time, content, sender, and observation method. They are useful for reproducing problems and comparing DLRs with observed receipt. However, a controlled sample does not necessarily reproduce the distribution of destinations, handsets, availability, filters, and profiles found in real traffic.

Production traffic provides scale and diversity, but usually offers less control over the handset and must not be used to infer reading or identity. It must also be handled in accordance with applicable consent, purpose, and record-retention rules.

BulkSMSMarket performs daily internal checks across routes, destinations, and operators to observe delivery, DLR consistency, latency, availability, and sender and content behavior. These observations serve as quality signals, not as a universal guarantee of receipt or reading. Public numerical cards are illustrative until contractual route data is connected.

Do not combine tests and production into a single rate. Label synthetic traffic, technical retries, and concatenated messages separately. If sources are compared, document differences in their selection, volume, and methodology.

• Synthetic: greater control and better reproducibility, but less universal representativeness.
• Production: greater diversity, but less certainty about what happened on the handset.
• Use legitimate, consented messages that comply with applicable regulations.
• Do not extrapolate from one test device to an entire route without sufficient evidence.

Useful Metrics Without Creating False Certainty

Do not reduce acceptance, DLR coverage, latency, and outcome to a single score. They are separate dimensions. DLR coverage may be defined as the proportion of eligible messages with at least one correlatable event; it must remain separate from the proportion reported as delivered.

Calculate latency using percentiles and clearly defined milestones. For example, acceptance to callback receipt is not the same as submit date to done date. Report the source of both endpoints, the offset, and how missing values are handled.

Before aggregation, deduplicate by message or event identifier and time window. Exclude or separately label tests, retries, and concatenated messages to avoid double counting. For concatenated messages, also measure successful and failed segments.

Build baselines segmented by destination, operator, sender, traffic type, declared route, comparable time period, and integration version. Analyze sustained changes rather than isolated fluctuations. With low volume, show the sample size and uncertainty instead of apparently precise rankings.

Periodically review the quality of the data itself: lost callbacks, misaligned clocks, incomplete fields, reused identifiers, future timestamps, ingestion errors, impossible transitions, and abrupt taxonomy changes.

• DLR coverage: eligible messages with any correlatable DLR divided by eligible messages.
• Consistency: the proportion of events that comply with the defined correlation, taxonomy, and sequence.
• Latency: percentiles by milestone pair and comparable segment, not only an average.
• Age of pending messages: distribution across intervals from the selected milestone.
• Uncorrelated: proportion and volume of DLRs without a secure link to the submission.
• Contradictions and duplicates: volume before and after deduplication.
• Recommended dashboard: status distribution, percentile trends, backlog by age, coverage, and data quality.
• Visible methodology note: source, scope, exclusions, window, sample, mapping version, and limitations.