A2P SMS Route Evidence: How to Document It for Sound Decisions
A practical method for recording observations, platform data, and provider statements without confusing them with delivery guarantees.
Why routing decisions need traceable evidence
A decision about an A2P route may be based on different sources: what a provider states, what a platform records, and what a test observes. If the source and context of each data point are not retained, a later review will not be able to determine what was known, which destination or sender it applied to, or what limitations it had.
Traceability does not, by itself, prove that a route will deliver messages. It helps reconstruct the reasoning, compare observations made under identifiable conditions, and review whether the decision remains appropriate. Keep the available evidence separate from the operational decision made on its basis.
- Record each piece of evidence as a separate item, with an identifier and capture date.
- Link the decision to the items considered and note who approved it.
- Describe the conclusion as valid for a defined context, not as a general guarantee.
Distinguishing provider statements, platform data, and independent observations
A provider statement documents what the provider communicates about a route; it is not the same as an independent measurement. Data generated by a platform reflects what that platform received or recorded, according to its capabilities and configuration. An independent observation comes from a check conducted by a party that is not merely repeating the provider’s statement; even so, it depends on the method, sample, and conditions used.
Identify the source type explicitly. For example, a delivery status reported by a system should not be described as verified receipt on a phone unless that was actually checked. A sent or received DLR provides a technical signal, but it should not automatically be presented as proof that the intended recipient saw the message.
- Classify the source: provider statement, platform record, or independent observation.
- Note who produced the data and who captured it; these may be different parties.
- Explain what the result represents and what it does not allow you to conclude.
Metadata to record for interpreting and reproducing a measurement
A useful record makes it possible to answer what was observed, where, when, and by what method. As an operational framework, include the source, period, destination, operator if known, sender, traffic classification, capture method, limitations, owner, and planned review date. Add a route identifier or internal reference if available, without assuming that all systems expose the same information.
The ITU’s E.164 recommendation relates to international numbering, but the information provided does not establish a complete A2P route audit model or prescribe these fields. This list is therefore a practical documentation proposal, not a regulatory requirement attributed to E.164.
- Source: the party, system, or document that generated the evidence.
- Context: destination, known operator, sender, traffic type, and route assessed.
- Method: the test or record used, period covered, and person responsible for capture.
- Limitations: missing data, incomplete sample, uncertainty, and unchecked conditions.
- Currency: planned review date and reason for checking again.
Linking evidence to destination, operator, sender, and traffic
An observation can only be interpreted in relation to the context in which it was obtained. Record the destination and operator only to the degree of certainty available: if the identification comes from a provider statement, say so; if it has not been confirmed, mark it as unknown. Do not turn an observation for one destination into a conclusion about other destinations.
Also document the sender and traffic classification—such as OTP, transactional, or legitimate marketing—when relevant and defined. Differences in sender, content, configuration, or test conditions may limit comparison. Do not attribute causation to any one of these variables if the method does not allow it to be isolated.
- Use explicit values such as “confirmed,” “stated by provider,” or “unknown.”
- Keep evidence from different contexts separate rather than combining it without explaining the differences.
- Retain only information that is necessary and comply with applicable privacy and compliance obligations.
Recording samples, periods, and limitations without hiding uncertainty
Specify the observation period and describe the sample well enough to make clear what it included. Note any exclusions, capture failures, or conditions that prevent a fair comparison. If these details are unavailable, state that they are missing rather than filling in the record with assumptions.
Delivery, latency, availability, or DLR consistency metrics describe observations under specific conditions. They are not promises of future results. A reported DLR should also not be confused with an independent check of receipt on the device.
- Specify the start and end of the period, along with the time zone if known.
- Record the sample size or description only if it has been measured.
- Note exclusions, capture errors, and factors that may affect interpretation.
- Describe uncertainty clearly; do not replace it with an unsupported score or claim.
Retaining reviews, changes, and approval owners
Maintain a history that distinguishes the original evidence from its revisions. If a classification, interpretation, or decision changes, retain the previous version and record when it changed, who made the change, and the documented reason supporting it. Avoid overwriting the record in a way that erases what was known when the route was approved.
Link each decision to the evidence considered, the responsible person, and the scope of approval. If the decision depends on a condition—for example, a specific destination or sender—write it down. The technical material available does not set a universal retention procedure or mandatory period, so the organization should define these according to its needs and applicable obligations.
- Keep previous versions and clearly mark which one is current.
- Record the author, date, reason, and references to related evidence.
- Distinguish between approved, pending review, and revoked decisions.
When evidence becomes outdated
The information available does not set a universal period after which route evidence expires. Define a review date or expiry condition appropriate to how the evidence will be used, and explain the criteria so the team can apply them consistently. Old evidence does not automatically become false, but it may no longer represent current conditions.
Consider starting a new check when a central element of the context changes, a material discrepancy is found, or the internal review period ends. If the measurement has not been repeated, retain the evidence as historical and avoid presenting it as a current observation.
- Define the owner and a review date or condition.
- Reopen the check when changes to the destination, operator, sender, traffic, or configuration could affect the conclusion.
- Mark evidence as expired for current decisions without deleting its historical value.
Operational template and common mistakes
To get started, create one record for each piece of evidence and another for each decision. Use this template as a guide: ID; evidence type; source; capture date; observation period; destination; operator and certainty level; route or internal reference; sender; traffic classification; method; sample and known exclusions; observed result; limitations; owner; review date; linked decision and approver. If a field is unknown or not applicable, state that explicitly.
Common mistakes include treating statements and observations as equivalent, generalizing a test to other contexts, describing a DLR as verified receipt, omitting limitations, and overwriting history. A careful record makes uncertainty visible and helps determine whether the evidence is sufficient for the specific purpose or whether further checks are needed.
- Before approval: are the source and method identified?
- Do the destination, operator, sender, and traffic match the scope of the decision?
- Do the results include an interpretable period, sample, and limitations?
- Is the evidence still current, and are the decision owner and review documented?
Frequently asked questions
Does a DLR prove that the recipient received the SMS on their phone?
Not necessarily. A DLR is a status reported by a system. It should not be described as verified receipt on the device unless an independent check was performed.
Is there a standard period after which A2P route evidence expires?
The technical information available does not establish a universal period. Define a review period or expiry condition based on the intended use and the rules applicable to your organization.
Does the E.164 recommendation define how to audit A2P routes?
The available evidence identifies E.164 as an international numbering recommendation, but does not provide an A2P route audit framework. Avoid attributing unverified traceability fields or requirements to it.
Does a test in one destination let you claim that the route works the same way in others?
Not on its own. Record the destination and context tested, and limit the conclusion to that scope unless additional evidence supports generalization.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- Configuración del canal SMSAdobe Experience League