A2P SMS Filtering: How to Investigate Content and Sender Blocks
An operational guide to distinguishing sending failures, reported statuses, and possible restrictions; gathering comparable evidence; and coordinating a responsible investigation without trying to bypass filters.
What it means when an A2P SMS may be filtered
An SMS that does not achieve the expected result does not, by itself, prove that its content or sender was blocked. There may have been a sending rejection, an acceptance or processing issue, an inconclusive delivery status, or a restriction somewhere further along the chain. Based on the information available, it is not possible to assign each case to a specific stage without consulting the records and definitions of the provider involved.
For this reason, treat “filtering” as a hypothesis to investigate, not an automatic explanation for every failure. Start by identifying which system generated each status and exactly what it means on that route.
- Separate messages that were not accepted for sending from those the provider reports as accepted.
- Record delivery statuses as reported and ask the provider for the applicable definition.
- Do not conclude that content or sender was blocked based on a single failure or uninterpreted code.
Rejection, acceptance, DLR, and receipt are not equivalent
A sending rejection indicates that a request was not accepted at that point in the process; the reason must be checked against the reported error. A provider’s acceptance does not confirm that the recipient’s phone received the message either. A DLR is a status reported within the chain, but its scope depends on how the provider generates and defines it. Do not present it as independent proof of receipt on the device.
If you need to know what a status means, ask for the documentation applicable to the route and provider. When a status cannot confirm what happened on the device, make that uncertainty explicit in your reports.
- Keep the sending response, subsequent statuses, and any additional available confirmation separate.
- Ask what event each DLR represents and which systems participate in generating it.
- Describe a result as “DLR reported” when there is no independent verification from the device.
Look for patterns before attributing a cause
Compare cases by destination, operator when that information is available, sender, content, and sending period. A recurring pattern can help narrow the investigation, but does not prove the cause on its own. Differences in route, configuration, or interpretation of statuses may also play a role; confirm these factors with the provider.
Use comparisons involving authorized, legitimate messages. If the issue appears only in a defined group, narrow down that group before making broad changes that could affect traffic that is working.
- Determine whether the issue affects all destinations or only some.
- Check whether it coincides with a specific sender or a family of templates.
- Compare equivalent time windows and note known operational changes.
- Do not interpret an isolated correlation as confirmation of filtering.
Gather comparable evidence
Prepare a set of examples that lets the provider review specific events. Delivery evidence, error details, sender records, and message content are useful elements to investigate; documenting them together avoids relying on general descriptions such as “it doesn’t arrive.”
Protect personal data and share only the information needed through authorized channels. Keep an internal reference that links each message to its events without exposing credentials or sensitive data in insecure communications.
- Message or request identifier, as provided by the system.
- Timestamps with time zone and destination in a standardized format.
- Sender used and exact text sent, keeping a controlled copy.
- Initial response, subsequent statuses, codes, and error descriptions.
- Provider or route involved and any known relevant changes.
Isolate the cause with controlled tests
A useful test keeps constant the variables that are not being investigated. First define an authorized population and a limited sample; then compare one element at a time, such as the sender or template, while keeping the destination, period, and route as comparable as possible. If you cannot control a variable, document that limitation.
Do not send test messages to recipients without authorization or generate unnecessary volume. Before running a comparison, agree with the provider on how the messages will be identified and which statuses can be observed.
- State a specific hypothesis, such as “the pattern occurs only with this sender.”
- Define what will remain the same and which variable will be compared.
- Use legitimate, authorized, limited traffic; record each send and its result.
- Stop the test if the impact increases or signs of operational risk appear.
Coordinate the investigation with the provider and operator
Send the provider a representative selection of identifiers, timestamps, destinations, sender, content, and received statuses. Ask them to confirm which stage each record covers, who originates the error code, and whether additional route information is available to narrow down the case. If the investigation requires operator involvement, ask the provider to specify the channel and required data.
Avoid asking for a binary conclusion when the data supports only a hypothesis. If it cannot be confirmed that the message reached the device, the response should preserve that distinction.
- Share specific, comparable examples, not just aggregate rates.
- Request documented definitions for the relevant statuses and errors.
- Clarify which checks the provider can perform and which depend on third parties.
- Agree on a next update and keep a record of conclusions and their limitations.
Make safe, traceable changes
Review the use of the sender and content against the requirements applicable to the destinations and the purpose of the message. Requirements may depend on the country, route, and traffic type; do not assume that a rule is universal. Confirm the conditions with the provider and, where applicable, the relevant official documentation.
If a change is authorized, apply it in a controlled way and record what changed, when, and for which traffic. Compare the results with the baseline and keep an approved version of the template. The goal is to maintain the message’s legitimacy and clarity, not disguise it to get through controls.
- Check that the sender and content match the legitimate purpose of the message.
- Validate applicable requirements before changing a sender or template.
- Change one variable per test and maintain traceability of versions and results.
- Assess the impact on successful deliveries before expanding a change.
What not to do and how to close the incident
Do not alter messages to evade filters or make changes that conceal the identity or purpose of the message. Do not blindly increase retries either: without knowing the reason for the failure and the route’s retry rules, you could generate repeated traffic without resolving the cause. Consult the provider before changing the retry policy.
Close the investigation once the cause has been narrowed down sufficiently, or document what information is missing. Record the affected scope, evidence, approved actions, observed results, and any remaining uncertainties. Continue tracking statuses without presenting a DLR as verified receipt.
- Do not use deceptive text or sender variations to get around controls.
- Do not resend automatically without reviewing the error and agreed policy.
- Do not promise receipt on the device when only a reported status is available.
- Keep an incident summary that can be used to compare future cases.
Frequently asked questions
Does an SMS that doesn’t arrive necessarily mean it was filtered?
No. A failure can result from different stages or conditions. Review the sending response, subsequent statuses, and error details before attributing it to a filter.
Does a DLR confirm that the message was seen on the phone?
It should not automatically be treated as independent confirmation of receipt on the device. Its meaning depends on the provider’s definitions and systems; ask for that information and describe the status accurately.
What information helps when opening an investigation with the provider?
Prepare identifiers, timestamps, destination, sender, the text sent, responses and statuses, as well as reported errors and the route involved when available.
Should I change the text to check whether that avoids a block?
Do not change messages with the aim of evading controls. If there is a legitimate reason to review the content, check the applicable requirements and make authorized, controlled, and traceable changes.
Should I increase retries when messages fail?
Not automatically or blindly. First identify the error and consult the provider about the route’s retry rules.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- SMS filtering investigation guidanceBird