How to Investigate A2P SMS Rejections Without Exposing Data or Jumping to Conclusions
An operational guide to narrowing down rejections, selecting useful samples, correlating records, and documenting hypotheses without mistaking signals for confirmed causes.
A rejection is an observed status, not a complete diagnosis
A record classified as “Rejected” indicates that the system reporting it assigned that status to the message. On its own, it does not necessarily identify which component rejected it, at what stage the rejection occurred, or what the definitive cause was. The label and associated code are clues to investigate, not a conclusive explanation.
It is useful to distinguish three layers: the result reported by an application or platform, the response recorded by the provider or route, and confirmation of receipt on the device. A DLR is a status report; it should not automatically be presented as independent verification that the message appeared on the handset. If the evidence cannot confirm that final step, document the uncertainty.
- Technical rejection: a response or status indicates that the send was not accepted or did not proceed at a particular stage. Verify which system generated the response and which request it relates to.
- Content filtering: this may be a hypothesis when the logs or provider indicate it; do not treat it as proven solely because it coincides with a rejected message.
- Uncertain outcome: if the logs cannot distinguish between rejection, a pending status, or delivery confirmation, preserve that distinction and do not turn uncertainty into a cause.
Define the question and limit the data extraction
Before consulting logs, write down what decision the investigation should support. For example: determine whether an increase in rejections is concentrated in one destination, compare an affected template with a legitimate one, or check whether a provider response matches the platform status. A specific question helps avoid collecting complete histories that do not contribute to the analysis.
Set the period, relevant destinations and senders, traffic types included, and criteria for deciding whether an event is in scope in advance. If comparing before and after a change, note the dates and what changed. Do not attribute causality simply because two events occurred in the same period.
- Start with a focused query for rejected events and expand it only if the evidence leaves a question unresolved.
- Separate OTP, transactional traffic, and legitimate marketing traffic when their flows, templates, or sending conditions differ.
- Record who requested the investigation, its purpose, the period covered, and who is authorized to access the data.
Design a useful sample and explain how it was selected
A list of conspicuous cases may help diagnose an incident, but it does not show that the pattern is common. To explore an issue, stratify records by relevant dimensions: destination, operator where available, sender, template or traffic type, and time window. Compare equivalent groups and record how many events were included in each group.
The available evidence does not establish a universal sample size that guarantees representativeness. If you need a descriptive sample, explain the selection criteria and their limitations. You can supplement a systematic selection with specific cases that show different responses, but identify those as examples, not as a measure of frequency.
- First define the groups that could explain the observed difference; avoid combining destinations or senders without checking that they are comparable.
- Include events from different parts of the time window if you are looking for a change, and record how they were selected.
- Keep the denominator: state the volume reviewed for each group where available, and do not extrapolate from a small sample to all traffic.
- If the platform supports filtering by status and reason code, use those filters to locate records; the code remains a signal that must be corroborated.
Correlate records using necessary fields, not full content by default
To compare evidence, you need to link the application event to the platform record and, where appropriate, to the provider response. Available fields vary by integration, so there is no universal minimum schema that can be asserted for all systems. Select only the identifiers and metadata necessary to answer the question.
As a starting point, check whether you can correlate using a message or request identifier and a timestamp. Add only the attributes needed to segment the case, such as destination, sender, traffic type, reported status, reason code, and source system. Confirm the meaning of each field with the platform or provider documentation.
- Avoid exporting the full message body if a template reference, category, or version is sufficient.
- If content inspection is necessary, limit access to the justified subset and avoid including it in general reports.
- Do not treat similar field names as equivalent: verify whether they represent a request, a send, a response, or a later status.
Minimize exposure and document access
Messaging logs may contain personal data or information sensitive to operations. An investigation should collect only what is strictly necessary for its purpose, restrict who can access the data, and document the retention and deletion criteria applicable within the organization. The specific period depends on relevant obligations and policies; there is no single timeframe that can be recommended for every case.
Where feasible, use substitute identifiers in analysis notes and separate working materials from data that could identify a person. Avoid copying logs to channels or documents with broader access than necessary. If a legal or contractual obligation requires certain information to be retained, follow the applicable process and record that need.
- Define the purpose and the people who will have access before sharing an extract.
- Record what was exported, who accessed it, and when its retention should be reviewed, in accordance with applicable policies and obligations.
- Mask or remove fields that are unnecessary for correlating and analyzing the pattern.
Corroborate records and keep hypotheses distinct
Trace an event end to end as far as your systems allow: the application request, the platform’s acceptance or response, and the status reported by the provider. Check that the identifiers and timestamps correspond to the same send, and preserve the original responses along with their source system. Differences between records may reveal an observability gap, an integration discrepancy, or an explanation requiring validation; by themselves, they do not establish the cause.
Contact the provider with a focused set of correlatable examples and a specific question. Ask for clarification about the code’s meaning and where the response was generated. Until there is sufficient confirmation, describe the finding as a hypothesis or an observed discrepancy, not as a proven fact.
- Observed signal: “In the sample, these events appear as rejected on the platform.”
- Hypothesis: “The pattern may be related to the response indicated by the provider; its origin and meaning have yet to be confirmed.”
- Confirmed conclusion: use this only when consistent records and relevant validation support the explanation.
- If the provider or platform cannot confirm receipt on the handset, state that explicitly.
Document tests, limitations, and actions
A useful report lets someone else understand what was reviewed and what remains unknown. Record the question, scope, selection method, log sources, status definitions, and results by group. Distinguish observations, hypotheses, tests performed, and conclusions, and indicate what evidence could change the interpretation.
If the analysis points to an integration issue or a compliance requirement, address that aspect and verify the outcome using authorized controls. Do not alter legitimate messages to try to evade filters. If filtering is suspected, ask the provider for an explanation and review the relevant compliance and configuration before changing the flow.
- Include the period and inclusion and exclusion criteria, without publishing unnecessary content or identifiers.
- Record codes and statuses verbatim, along with the system that reported them; do not translate them into unconfirmed causes.
- Record agreed actions, owners, and the evidence required to close the investigation.
- Reassess the sample if the pattern changes by destination, sender, traffic type, or period.
Frequently asked questions
Does a “Rejected” status identify who blocked the SMS?
Not necessarily. It identifies the status reported by the system displaying it. The reason code may help guide the investigation, but its meaning must be verified and records corroborated to determine where and why it occurred.
Does a DLR confirm that the message reached the phone?
That should not be assumed automatically. A DLR is a status report; the available evidence may not independently confirm that the message was received or appeared on the handset. Document which system issued it and what uncertainty remains.
How large should the sample be?
There is no universal sample size supported for every case. Define groups and selection criteria, retain the volume reviewed, and avoid generalizing to all traffic if the sample is limited or unrepresentative.
Should I store the full text of every message?
Not by default. Retain message content only if it is necessary to answer the question, and restrict access. When sufficient, use a template reference or category and minimize other data.
Should I change the text to avoid a rejection?
Do not modify legitimate messages to evade filters. If a filtering issue is suspected, validate the hypothesis with the provider and review the relevant compliance and integration.
Sources consulted
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA network resourcesGSMA
- Comprender los mensajes rechazadosSinch Support
- Estudio del servicio de mensajes cortos Aplicación a Persona (A2P)Instituto Federal de Telecomunicaciones (IFT)