A2P SMS Routing Policy by Destination: An Auditable Framework for Route Decisions
A robust A2P SMS routing policy turns compliance requirements, traffic profile, quality evidence, capacity, and cost into reviewable rules by destination. This framework helps select, monitor, and switch routes without confusing a DLR with a universal guarantee of handset receipt.
What a destination-based routing policy is and why a price list is not enough
An A2P SMS routing policy by destination is a documented set of rules for deciding which routes may carry a specific message, under which conditions, and with which controls. Its objective is not simply to find the lowest price, but to make reproducible decisions that respect traffic eligibility, compliance requirements, available capacity, and observed technical evidence.
A price list can be an input, but it should not be the complete decision mechanism. An economically attractive route may not be suitable for a particular sender ID, an OTP profile, or a promotional campaign. Likewise, a route with acceptable historical results may not have enough capacity during a critical operational window.
E.164 numbering makes it possible to structure an international destination by country or country code, but a prefix alone does not summarize the operational context. The decision may also require the effective network where confirmed, traffic profile, sender behavior, market requirements, and the current rules of the contractual relationship.
- Use price as a ranking criterion among eligible routes, not as a substitute for eligibility.
- Treat country, network, traffic profile, and sender ID as separate attributes.
- Document both approved and excluded routes, along with the reason for each exclusion.
Decision units: country, range or network, traffic type, sender, and operational window
The minimum unit of a policy should rarely be a country alone. A useful rule may apply to a country, an E.164 range, a confirmed network, or a combination of these attributes. Granularity should reflect the available evidence: an effective network should not be asserted when only the country or numbering range is known.
Each destination should be associated with message attributes. These include the traffic profile, permitted or expected sender ID type, sender behavior history, validity window, and operational priority. This prevents a route designed for low-risk notifications from being applied to a time-sensitive OTP flow.
The operational window matters especially when the value of a message expires. An OTP that reaches a final status after the code is no longer useful may provide a positive technical signal, but it does not meet the business objective. The policy should define the point at which latency becomes unacceptable for each profile.
- Destination: country, E.164 range, and network only when sufficient confirmation exists.
- Message: OTP, transactional alert, operational notification, or consented marketing.
- Sender: sender ID type, applicable registration, and expected behavior.
- Time: validity period, priority, and internal usefulness limit.
- Context: expected capacity, operating hours, and applicable compliance rules.
Separate price, quality, capacity, and compliance as independent dimensions
A robust matrix treats compliance, traffic-profile suitability, observed quality, capacity, and cost as independent dimensions. Combining them into a single score without prior constraints can allow a low price to improperly offset a regulatory, contractual, or operational exclusion.
Compliance and eligibility should operate as filters. If a route does not support the applicable traffic type, sender ID, or terms of use, it should not enter the economic comparison. After filtering, the organization can rank eligible alternatives using defined technical and commercial criteria.
Quality should not be reduced to a single number either. It is useful to distinguish connection availability, DLR behavior, time to final status, integration errors, and signals related to sender or content behavior. Interpretation should retain the context of the route, destination, and observed period.
- Filter 1: required compliance and documentation.
- Filter 2: suitability for traffic profile and sender ID.
- Filter 3: available operational capacity.
- Comparison: observed technical evidence and contractual cost.
- Ongoing control: review of changes, incidents, and subsequent results.
What evidence to collect before approving a route
Before approving a route, collect both declared evidence and observed evidence, and keep them separate. Declared evidence may include terms of use, sender ID restrictions, supported traffic profiles, and communicated capacity. Observed evidence comes from controlled testing and subsequent operational monitoring.
Tests should be reconstructable. For each test message, preserve the correlation between the internal identifier, message identifier, destination handled according to applicable privacy rules, route used, timestamps, received DLR, final status, and error code. In SMPP, the receipt format contained in the short message of a delivery receipt may include a message identifier, submit date, final status date, final status, and error; its availability and practical semantics depend on the implementation and provider.
Evidence should be assessed in comparable segments. It is not prudent to combine results from different traffic profiles, senders with different behaviors, or incompatible time windows into a single conclusion. A small sample should also not be turned into a permanent rule.
- Declared route origin and terms.
- Communicated traffic, sender ID, and content restrictions.
- Controlled tests with complete event correlation.
- Raw DLR, normalized status, and original error code.
- Time to final status and connection availability.
- Date, size, and scope of the assessed sample.
How to interpret DLRs and delivery tests without treating them as a guarantee of handset receipt
Mobile-terminated SMS, or SM-MT, transfers a message from a service center to a mobile station and may provide delivery or failure reports. However, a DLR must be interpreted according to the semantics of the interface and network issuing it. It is not universal proof that the message was read, nor is it a uniform guarantee of handset receipt.
SMPP v3.4 includes final statuses such as DELIVRD, EXPIRED, UNDELIV, ACCEPTD, UNKNOWN, and REJECTD. In addition, error codes may be network- or SMSC-specific. Therefore, the policy should retain the received raw value, the internally used normalized status, the error code, the timestamp, and the source that issued the event.
Some provider documentation distinguishes between upstream carrier acceptance, delivery confirmation, and, where available, handset confirmation. This distinction illustrates a general operational principle: do not aggregate acceptance, submission, and reported delivery into a single success rate. Compare each stage separately and explicitly describe what each metric confirms.
- Do not interpret a DLR as confirmation that the message was read.
- Differentiate provider acceptance, submission, reported delivery, and non-delivery.
- Retain original statuses and errors before normalizing them.
- Measure time to final status, not only the presence of a status.
- Record the source and context of every DLR.
Define traffic profiles and eligibility rules
Traffic profiles should be kept separate because they change time utility, operational risk, and consent obligations. A practical classification may include OTP, transactional alerts, operational notifications, and consented marketing. This is an internal operational taxonomy, not a universal regulatory classification, and it should match the actual purpose of the message rather than the commercial label selected by the sender.
For OTP, define a validity period and an internal latency limit compatible with the code's useful life. For transactional alerts and operational notifications, define the priority, permitted content, and escalation criteria. For consented marketing, incorporate consent controls, opt-outs, and campaign restrictions before a route is considered eligible.
CTIA distinguishes conversational, informational, and promotional traffic, with different permission expectations. In contexts where these practices apply, promotional marketing requires especially rigorous consent management. The route does not replace obligations that apply under the relevant jurisdiction, operator, and messaging program: if required evidence is missing, the policy should exclude the send or route it for review.
- OTP: validity, priority, and usefulness cutoff point.
- Transactional: specific purpose and content rules.
- Operational: urgency, authorized recipients, and escalation.
- Consented marketing: consent evidence, opt-out management, and campaign controls.
- Conversational: relevant response to a consumer-initiated interaction where applicable.
Create an auditable decision matrix by destination
The decision matrix should turn the policy into an operational tool. Each row may represent a combination of destination and profile, for example: country or E.164 range, network where confirmed, traffic type, and sender ID type. Eligible routes, excluded routes, prerequisites, available evidence, and owners are associated with that combination.
Define internal thresholds only when they are supported by a stable methodology. It is not necessary to publish or invent figures to work with discipline: the matrix can record that a route requires a minimum internal sample, a defined observation window, the absence of specific errors, or additional review when behavior changes. The essential requirement is that the threshold, its owner, and its rationale are documented.
Every decision needs an effective period and review. Route information can change because of operational conditions, integration, sender behavior, or market requirements. For that reason, an approval should not be indefinite: include the approval date, review date, supporting evidence, and reversal condition.
- Policy identifier and version.
- Country or E.164 range; network only if confirmed.
- Traffic profile and sender ID requirements.
- Eligible, preferred, and excluded routes.
- Technical, contractual, and compliance evidence.
- Applied internal thresholds or criteria.
- Approver, effective date, and review date.
- Reversal conditions and escalation path.
Controlled route changes and fallback routing
A route change should be handled as a controlled change, not as a simple replacement in a table. Start with pre-change tests and a clear hypothesis: which destination, profile, and condition will be evaluated; what evidence will determine whether to proceed; and which signal will require the change to stop or be reversed. Maintain event correlation so that the comparison is reproducible.
When operations allow it, roll out the change gradually. Compare results within equivalent segments and over a defined window. If signals appear that are incompatible with the policy, apply the reversal condition, record the incident, and communicate the change to affected internal functions.
Fallback routing can protect continuity, but it is an exception that needs governance. Define which final statuses, errors, or conditions can trigger an alternative. Do not remove the initial failure from the record or attribute a fallback delivery in a way that prevents evaluation of the primary route. If fallback is activated persistently, it should trigger a review rather than normalize the problem.
- Define the hypothesis, scope, and success criteria before making a change.
- Test before rollout and preserve correlated identifiers.
- Apply gradual rollout when the operational context allows it.
- Set explicit stop and reversal conditions.
- Record the reason, primary route, and alternative route for each fallback.
- Escalate repeated fallback activations as a potential incident.
Frequently asked questions
Does a DLR with a delivered status prove that the user read the SMS?
No. A DLR is a status signal whose semantics depend on the interface, network, and available information. It may indicate confirmation from an upstream carrier and, in some cases, from the handset, but it does not prove that the recipient read the message.
Is a phone number prefix enough to select an A2P SMS route?
No. E.164 structures international numbering, but a routing decision may require country, range, confirmed network, traffic profile, sender ID, validity window, and compliance requirements.
Should cost determine the preferred route?
Cost should only be compared among routes that have already passed compliance, traffic-profile eligibility, sender ID, and capacity filters. A lower price should not offset a compliance exclusion or operational incompatibility.
When should fallback routing be activated?
Only under predefined conditions, such as certain final statuses, error codes, or availability incidents. Activation should retain evidence of the original failure and trigger a review if it becomes recurrent.
What should be retained to audit a route change?
The policy version, scope of the change, approvals, test results, message identifiers, raw DLRs and errors, timestamps, rollout decision, reversal condition, and subsequent results.
How can BulkSMSMarket help with this process?
BulkSMSMarket is developing an enterprise platform to discover, compare, buy, sell, and manage A2P SMS capacity. Marketplace operations, authentication, balances, billing, and live routing features are not public. Its internal testing platform performs daily checks across routes, destinations, and operators, observing delivery, DLR consistency, latency, availability, and sender and content behavior; these observations are internal, not real-time commercial data or a performance guarantee.
Sources consulted
- ITU-T Recommendation E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)
- 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3GPP / ETSI
- 3GPP TS 23.040 specification record3GPP
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- Messaging Principles and Best PracticesCTIA
- Messages resource: message status definitionsTwilio Developer Documentation