Acceptance of International A2P SMS Destinations: Documentation and Validation
Declared coverage alone is not enough to enable A2P traffic. Learn how to document scope, check official requirements, and distinguish authorization, connectivity, and delivery evidence.
Declared coverage does not mean a destination is ready
A provider stating that it has coverage in a country does not, by itself, prove that the intended traffic is authorized, that the sender is acceptable, or that delivery capability has been demonstrated for each operator. The term “coverage” may describe commercial availability or declared connectivity; it should not automatically be treated as regulatory approval or a guarantee of receipt.
The evidence available here does not confirm authorization requirements, permitted senders, or content restrictions for any specific destination. The decision must therefore be based on sources applicable to the case and evidence tied to the exact scope of the traffic—not on a general statement of coverage.
- Do not enable a destination solely because it appears on a coverage list.
- Separate what a source confirms from what has not yet been verified.
- If you cannot confirm a relevant condition, record the uncertainty and escalate the decision rather than assuming it is permitted.
Define the traffic you want to enable
Define the scope before researching requirements. “Sending SMS to a country” is too broad for an operational assessment: the result may depend on the territory, destination operator, message purpose, sender type, and intended content. Numbering and network resources have their own technical documentation, but a general reference does not determine the rules applicable to a specific campaign or route.
Describe the intended use case precisely and avoid extending a validation to different traffic. A file for a transactional notification using a particular sender does not automatically validate promotional messages, another sender, or a different operator.
- Country or territory and the operators you intend to reach.
- Traffic type, such as OTP, transactional, or legitimate marketing messages.
- The identity and format of the intended sender, along with the content or template being assessed.
- The connectivity or route to be checked and the limits of the authorized test.
- The party responsible for sending and the entity that approves enablement.
Check requirements against applicable sources
Prioritize official documentation relevant to the destination and specific use: the competent regulator, mobile operator, and official documentation applicable to the service. Check that the source covers the sender, content, and traffic type you have defined. A general technical specification or network overview may provide context, but it does not replace a country- or operator-specific rule.
General references from 3GPP, ITU-T on E.164 numbering, and GSMA on networks are not, by themselves, sufficient to confirm authorization or A2P SMS restrictions in a destination. If a page refers to another policy or document, retain that reference and check whether it is still current and applicable to the case.
- Record the issuing entity, document title, URL or reference, date accessed, and publication date or version if available.
- Note precisely which condition the source supports and which territory, operator, sender, and traffic it applies to.
- Distinguish an explicit requirement from an internal interpretation or a condition communicated commercially.
- If you cannot find a sufficient official source, mark the requirement as unconfirmed and request clarification from the responsible operator, provider, or adviser.
Build a file for each destination
A practical file brings together verified conditions and makes gaps visible. It is not a legal certification or a delivery guarantee; it is a decision record that lets others review the basis for each conclusion and helps prevent a limited validation from being interpreted as general permission.
Include known restrictions, conditions declared by the provider, test results, and open questions. Record who supplied each piece of information and when it was obtained. If information has no verifiable source or does not cover the defined use case, classify it as pending, not confirmed.
- Identification and scope: intended destination, operator, traffic, sender, and content.
- Sources: entity, document, reference, access date, and the condition supported.
- Restrictions and conditions: confirmed requirements, known limits, and the source for each.
- Technical evidence: tested configuration, scope, date, and observed results—without presenting a DLR as verified receipt on the handset.
- Open items: uncertainties, who is responsible for resolving them, and the associated interim decision.
- Approval: the person or team that accepts, rejects, or escalates the case.
Separate authorization, connectivity, and delivery behavior
Documentary validation answers which rules and conditions could be confirmed. Connectivity indicates whether there is a technical possibility of routing traffic through a path. A test observation describes what happened in one specific execution. These are different questions, and none automatically replaces the others.
A DLR is a report associated with a message’s status in the messaging system; by itself, it should not be presented as independent proof that the person received or read the SMS on their handset. A test also has limits: its results apply to the destination, operator, sender, content, route, and time assessed—not to every future message.
- Documentation: which applicable condition is confirmed, and by what source?
- Connectivity: what technical scope was checked, and with what configuration?
- Observation: what responses and timings were recorded, and what are their limitations?
- Handset receipt: is independent verification available? If not, do not claim that receipt has been demonstrated.
Design controlled, legitimate tests
Tests must be limited to legitimate, consented traffic that complies with applicable rules. Beforehand, define who authorizes the send, which recipients are permitted, which sender and content will be used, which operator is being assessed, and what evidence will be collected. Do not use a test to infer permissions that have not been confirmed.
Record results as observations, not guarantees. Note the configuration and date, distinguish statuses reported by the route from any independent handset check, and limit conclusions to the scope actually tested. The available information does not establish a universal test method or technical acceptance thresholds for each destination; these must be agreed for the specific case.
- Obtain authorization for recipients and use consented, permitted messages.
- Keep relevant configuration constant during the test and document it.
- Record the reported result, incidents, and any independent checks available.
- Do not extend the test to different content, senders, operators, or volumes without an additional assessment.
Decide: accept, reject, or escalate
Define the decision before enabling traffic so the team does not treat the absence of objections as implicit approval. The criteria should cover documentary conditions, technical scope, and the uncertainties the organization is willing to accept.
Accept only the scope that has been assessed and approved by the appropriate owners. Reject or pause when an applicable condition prohibits the use case, a necessary authorization is missing, or a material discrepancy exists. Escalate when a source is ambiguous, the scope does not match, or the evidence cannot resolve a relevant question. These are prudent management criteria, not universal requirements imposed by any one jurisdiction.
- Accept: scope is defined, sources and conditions have been reviewed, responsible parties agree, and test limits are clearly recorded.
- Reject or pause: conflict with an applicable condition or lack of confirmation necessary for the use case.
- Escalate: contradictory information, insufficient sources, or an unresolved question about the sender, content, or use.
- Limit: if only one operator or sender was assessed, do not extend approval beyond that scope.
Maintain the file and review before expanding
A file can become outdated if sources, communicated conditions, operator, sender, content, or use change. Record incidents and discrepancies alongside their original evidence, and reassess the case before expanding traffic or changing any element that defined its scope.
The available information does not specify a universal review frequency. Set an internal schedule appropriate to the risk, and also review when a relevant signal appears, such as an official update, an operator instruction, or a persistent change in observed behavior. Document what changed and who authorized the resulting decision.
- Keep previous versions and access dates so changes in conditions can be understood.
- Reopen the assessment if the destination, operator, sender, content, or purpose changes.
- Link incidents to the route and configuration assessed; do not generalize from a single observation.
- Review and reapprove the scope before expanding it.
Frequently asked questions
Does a route marked as covered authorize any A2P traffic?
That cannot be concluded from a coverage statement alone. Check requirements applicable to the destination, operator, sender, content, and traffic type, and record any conditions that remain unconfirmed.
Does a DLR prove that the SMS reached the phone?
Not by itself. A DLR is a status reported in the messaging system and does not automatically equal independent verification of receipt on the handset.
Does a successful test allow other senders or message types to be enabled?
Not automatically. The conclusion must be limited to the operator, sender, content, route, and configuration assessed. A relevant change requires reviewing the scope and applicable conditions.
What should I do if I cannot find an official rule for the destination?
Record the lack of confirmation as an uncertainty, identify which part of the case remains unresolved, and request clarification from the relevant entities or operators. Do not treat information you could not find as authorization.
Sources consulted
- 3GPP specifications3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA