A2P SMS Destination File: Requirements, Evidence, and Owners

Why a coverage list is not enough to approve traffic

A destination appearing on a coverage list does not, by itself, prove that a specific type of traffic is authorized, that a sender is permitted, or that an operator will accept a campaign. Coverage, commercial terms, operator restrictions, and regulatory obligations are separate matters and should be documented separately.

An A2P SMS destination file turns that distinction into an operational practice: it brings together what is known, flags what is missing, and makes clear who verified each detail and when. It supports a launch decision; it does not guarantee coverage, acceptance, or delivery.

• Do not treat a commercial coverage statement as proof of authorization.
• Do not extrapolate conditions from one country, operator, or traffic type to another.
• Stop approval if a material condition depends on an unverified assumption.

What to record in each market file

Use one file per market and define its scope. Identify the country or territory, the operators under consideration, and the type of traffic you intend to send. If the scope covers only certain operators, senders, or use cases, state that explicitly; avoid generic titles that could be interpreted as approval for the entire destination.

ITU-T Recommendation E.164 is a relevant reference for identifying the international public numbering plan, but the available information does not support using it as proof of A2P permissions, sender requirements, or deliverability. Keep these matters in separate fields.

• Market and file scope, with creation and review dates.
• Operators included and any known limitations on scope.
• Proposed use case and traffic category, such as OTP, transactional, or marketing, without assuming that all are permitted.
• Proposed sender and verification or registration status, if applicable.
• Known restrictions, outstanding conditions, and the owner of each check.
• Sources used, date accessed, and evidence retained.

Document requirements with their source, scope, and confidence level

For each requirement, record the exact claim being assessed and the evidence supporting it. Note who publishes the source, its URL, the date accessed, its geographic and technical scope, and which operator, sender, or traffic category it concerns. Retain a copy or internal reference to the document consulted where your organization’s procedures allow.

Assign an understandable status, such as confirmed by a primary source, confirmed only for a limited scope, pending corroboration, or unverified. A confidence level does not replace evidence: it should explain what was checked and what uncertainty remains.

• Link each requirement to a specific source, not a general list of links.
• Distinguish the date accessed from the document’s publication or effective date, if known.
• Record what the source covers and what it does not cover.
• Identify who interpreted the evidence and who can approve the conclusion.
• If there is not enough supporting evidence, write “unverified” rather than filling the gap by inference.

Separate regulation, operator conditions, and commercial claims

Classify each detail by its origin. A regulatory obligation should be supported by an official source relevant to the market. An operator condition should be attributed to the operator and scoped to the service, traffic, or sender, as documented by the source. A provider’s claim about availability or coverage is commercial information: do not turn it into a confirmed requirement or regulatory evidence.

Technical references also have limits. The supplied 3GPP page is an index of specifications by series and does not establish national rules for A2P authorization. GSMA’s general mobile network resources do not, on their own, confirm sender registrations, permitted categories, or coverage in a specific market.

A provider’s A2P 10DLC guide mentions evidence of how numbers are collected and how consent is revoked in that context. Treat it as guidance limited to what it describes: it does not prove a universal obligation or one that applies in other countries.

• Regulation: prioritize official text and the competent authority for the market.
• Operator: retain communications or documentation attributable to the operator and note the stated scope.
• Provider: record the claim as commercial until it is corroborated with relevant evidence.
• Technical standard or guide: do not attribute regulatory effects that the source does not establish.

Flag gaps and discrepancies without treating them as confirmed availability

When two sources conflict, do not choose the more convenient one or average their conclusions. Record both claims, their dates, and their scopes; check whether they refer to the same operator, sender, service, and traffic type. The discrepancy may be due to differences in scope, but do not assume that without confirmation.

Escalate the question to the compliance owner, the operator contact, or the provider that supplied the information. If the response does not resolve the conflict, keep the detail pending and limit or pause the affected launch. A blank field is not authorization.

• Note the specific question that remains unresolved and who should answer it.
• Keep a record of conflicting sources and the steps taken to resolve the issue.
• Do not change the status to confirmed merely because a route appears available in a tool.
• Block the decision when the gap affects legality, the sender, or traffic acceptance.

Approval workflow and criteria for stopping a launch

Assign owners before completing the file. Operations can gather route and scope information; compliance can assess regulatory evidence; product can confirm that the use case and sender match the plan; and an authorized person can make the final decision. The specific assignments depend on the organization and should be documented.

Before approval, require sufficient evidence for the intended scope, an identified owner, and a review date. If applicable requirements cannot be confirmed using reliable sources, or material contradictions remain unresolved, stop the launch or reduce its scope to what is supported. Where appropriate, validate obligations against official sources and with local counsel.

• Define the market, operators, traffic, and sender covered by the request.
• Gather and classify evidence; record questions and source limitations.
• Obtain review from the responsible functions and document their decision.
• Authorize only the supported scope; make exclusions and open items explicit.
• Stop or defer if relevant evidence is missing, a conflict remains unresolved, or decision ownership is unclear.

Maintain the file without assuming automatic updates

A file can become outdated when sources, operator conditions, the sender, or the intended use change. Set a review date and assign an owner to check the relevant sources. Do not assume that a provider or platform will update information automatically unless that capability is documented and validated for the specific case.

Record decisions and their rationale alongside scope changes. This makes it possible to see what evidence was used to approve an operation and what questions remained open, without presenting an earlier review as current confirmation.

• Set an internal review schedule and define events that require the file to be reopened.
• Record changes to sources, scope, owner, or decision, with dates.
• Retain previous versions to reconstruct the approval context.
• Revalidate before expanding to another operator, sender, or traffic category.

Checklist and limits of what the file demonstrates

Before launch, check that the file answers who is sending what traffic, within what scope, and using which sender; which sources support each condition; what remains unverified; who reviewed the evidence; and who approved the decision. If an important answer depends on an assumption, keep it visible and resolve it before proceeding.

The file improves governance and traceability, but it does not, by itself, prove that a route is available, that an operator will accept the traffic, or that a message will reach a device. The available evidence also does not confirm the regulatory requirements for a specific destination or establish a universal list of A2P obligations by country.

• Scope and use case defined.
• Requirements and conditions separated by source type.
• Evidence, date, owner, and confidence level recorded.
• Gaps and contradictions identified, with resolution or launch holds documented.
• Official review and local advice considered where appropriate.
• Approval limited to what is actually supported, with no promises of coverage or delivery.