Number Portability in A2P SMS: Why the Prefix Is Not Enough to Choose a Route
Prefixes help interpret a number, but they do not confirm the routing information currently applicable to a ported subscriber. This guide outlines an A2P routing policy based on signals, local requirements, and operational evidence.
What Prefix Analysis Solves in A2P SMS Routing
In A2P SMS, analyzing a number before sending makes it possible to classify the number and apply an initial decision logic. The international E.164 format and its digits provide a basis for identifying the country and, depending on the applicable national numbering plan, for contextualizing the type of number resource or range to which it belongs.
This information is useful for initial controls: validating the format, determining the national destination, associating local operational requirements, and avoiding route selection without at least a basic number classification. However, a prefix should not be treated as proof of the routing information currently applicable to the subscriber.
The reason is operational: a numbering plan describes digit structure and analysis for routing, but the relationship between a range and the routing information applicable to a specific subscriber can change when number portability exists.
- Use the prefix as a classification signal and starting point.
- Validate E.164 normalization before applying routing rules.
- Do not turn a range’s historical assignment into certainty about current routing information.
- Keep number analysis logic separate from the final delivery decision.
What a National Prefix Represents and What It May Suggest
A prefix may suggest how a national numbering plan is organized and, in certain destinations, provide context about a number category or a historical range assignment. For a routing team, that information can support initial country-level rules, identify unexpected formats, or associate known restrictions with the destination.
The value of a prefix depends on the country and the quality of the numbering table used. Even where a range assignment is known, that data describes the range or its original assignee; it does not demonstrate that every individual number in the range continues to have the same routing information.
The prudent approach is to label the data for what it is: an inference based on numbering. It should remain distinct from a routing signal obtained through a lookup and from observed behavior after sending.
- Country and numbering structure.
- Number category or national context, where the plan allows it.
- Historical or range assignment, where a reliable source is available.
- Not: confirmation of portability, identity, consent, ownership, or delivery.
What Number Portability Is and Why It Changes the Relationship Between Range and Current Network
Number portability allows a customer to keep their number when changing providers, subject to the conditions applicable in each market. As a result, the MSISDN no longer necessarily identifies the current subscription network.
This has a direct implication for A2P SMS: a table linking a range to a historical operator may be correct as an assignment reference while still being insufficient for deciding how to reach a ported subscriber.
In the United States, for example, the portability process relies on a query to the NPAC/SMS database to obtain a Location Routing Number, or LRN, associated with the switch serving the customer. This example illustrates the general principle, but it should not be extrapolated directly to international A2P SMS flows: each market may use its own portability mechanisms and data sources.
- The original range and current routing information may not match.
- Portability applicability and mechanisms depend on the market.
- Portability information is used for routing; it is not a complete subscriber record.
- Recent portability activity should not be confused with a full number history.
Risks of Routing Only by Historical MCC/MNC, Prefix, or Original Assignment
A rule that selects a route solely by prefix, historical MCC/MNC, or original assignment assumes that the number and subscription network remain stably linked. In an environment with portability, that assumption can fail for individual numbers.
The risk is not purely technical. Incorrect classification may lead to applying the wrong local conditions, using a route that does not match the available routing signal, or interpreting a later result without distinguishing which routing hypothesis was used.
The alternative is not to remove range tables. They are useful as a reference and fallback layer. The improvement is to prevent a single historical signal from independently finalizing a decision that should consider more context.
- Treat historical MCC/MNC and prefix data as reference information.
- Prioritize a recent routing signal when available and relevant.
- Apply country, sender, and traffic-type requirements before sending.
- Record discrepancies between historical inference and number intelligence.
- Measure the technical outcome of the chosen route to review the policy.
Distinguishing the Original Assignee, Routing Signal, Destination Network, Delivery Route, and Delivery Outcome
A clearer routing policy begins by separating concepts that are often conflated. The original range assignee refers to the historical or administrative relationship for that range. A routing signal describes contextual technical information obtained through number intelligence or portability mechanisms, where available. Depending on the market and method, it may refer to a technical identifier, an MSC, an LRN, or other routing information; it should not be assumed to identify a commercial operator conclusively.
The destination network is the network associated with the destination in the relevant technical context. The delivery route or interconnection path is the contracted and authorized path through which traffic is carried. Neither should be assumed to be identical to the original assignee or to a technical lookup response. Finally, the delivery outcome is the status reported after sending or delivery processing.
This separation prevents both language and operational errors. Range data may be valid, a lookup may provide a useful routing signal, and a route may be correctly authorized, yet the message outcome must still be evaluated as a separate, later event. The meaning of a DLR depends on the route, interconnection, and returned code or status, so it should not be interpreted uniformly across providers.
- Original assignee: historical or administrative reference for the range.
- Routing signal: a dated, contextual technical signal.
- Destination network: the network associated with the destination in the relevant technical context.
- Delivery route or interconnection path: a commercial and operational path for carrying traffic.
- DLR or returned status: a reported outcome whose semantics depend on its source and status code.
- Handset receipt: should not be assumed from a DLR sent by a route.
What an HLR Lookup May Provide and Its Limits
In GSM/MAP-based signaling flows where SRI_SM is used for mobile-terminated SMS, it is a signaling query that an SMSC can use to obtain routing information for the destination subscriber. In the technical flow described for this type of query, the HLR may return information that enables the querying node to attempt to reach the destination, including routing context used in the delivery process.
Commercial products described as “HLR lookup” are not necessarily direct MAP SRI_SM queries and may not return the same fields. The type of data returned, its availability, its reliability, and the criteria for considering a query successful depend on the query method, implementation, agreements, network, country, regulation, provider, and time of the query. An HLR lookup should therefore not be treated as interchangeable with every other number-intelligence or portability mechanism.
For A2P routing, the prudent use is to turn the result into a decision input with an operational expiry, not a permanent attribute of the number. If the signal contradicts the historical range, the discrepancy should be visible and governed by an explicit rule.
- It may provide technical information useful for routing.
- It may help identify that range-based inference is insufficient.
- Its date and time, source, query method, and normalized result should be retained.
- It does not replace local validation, compliance controls, or subsequent observation.
- Its usefulness depends on the technical context and the time of the query.
- A commercial HLR lookup may use a method other than a direct MAP SRI_SM query.
Why an HLR Lookup Does Not Prove Consent, Identity, Ownership, or Guaranteed Delivery
Number intelligence and routing lookups serve a technical purpose: helping analyze a number or obtain useful information to carry a message. They are not mechanisms for proving consent, civil identity, line ownership, or message reading by a person.
Consent for A2P communications must be retained in the appropriate compliance and customer relationship systems. It must not be inferred from a number having a valid structure, a lookup returning routing information, or a provider being able to attempt delivery.
A favorable HLR/SRI_SM response should not be equated with guaranteed final delivery either. The routing lookup and SMS sending process are separate events. Likewise, a submitted DLR reports a status returned by the delivery chain; its meaning depends on the route, interconnection, and returned code or status, and it is not independent verification of receipt on the handset.
- HLR does not prove consent.
- HLR does not prove identity or ownership.
- HLR does not prove that the recipient read the message.
- A routing signal does not guarantee final delivery.
- A DLR must be analyzed according to its semantics, source, route, and returned status.
Decision Framework for Combining Prefixes, Number Intelligence, Local Requirements, and Observability
An operational policy should organize signals instead of searching for a perfect signal. The prefix is used for classification; portability or routing information, when available, can refine the hypothesis; local requirements determine whether the sender, content, and use case are permitted under the applicable jurisdiction and policies; and subsequent observability makes it possible to assess how the decision performed.
The exact priority depends on the destination, contracted capabilities, and applicable rules. What matters is defining which data is mandatory, which discrepancies block or downgrade a decision, and which outcomes require a policy review. A technical route review alone does not validate regulatory compliance or authorization to send.
For legitimate, consented messages that comply with applicable regulations, the framework should be reproducible: two operators reviewing the same sending record should be able to understand which signals were used, which route was selected, and which status was received. The storage, access, retention, and processing of these records should comply with applicable privacy, security, and retention requirements.
- 1. Normalize and validate the number in E.164 format.
- 2. Classify the country, number type, and range as a reference.
- 3. Determine whether portability applies to the destination.
- 4. Query number intelligence when available and relevant.
- 5. Validate local sender, content, traffic-type, authorization, and compliance requirements.
- 6. Select an authorized route for the destination and use case.
- 7. Capture technical statuses and review discrepancies or anomalies.
Frequently asked questions
Can a prefix identify the current network of a mobile number?
It may provide context about the national numbering plan or a range’s historical assignment, but it does not by itself confirm the routing information applicable to a subscriber where number portability exists.
Does an HLR lookup guarantee that an A2P SMS will be delivered?
No. It may provide technical routing information useful for attempting delivery, but it is not a guarantee of final delivery or confirmation of receipt on the handset.
Does an HLR result validate consent to send a message?
No. Consent must be retained and managed in compliance and customer relationship systems. Numbering and routing data do not establish permission to contact the user.
What should I record when a network lookup influences routing?
At a minimum, record the query date and time, source, query method, normalized result, selected route, sending identifier, and returned DLR or technical status. Storage, access, retention, and processing of these records should comply with applicable privacy, security, and retention requirements.
What should I do if the historical range and number intelligence conflict?
Do not turn either isolated signal into certainty. Record the discrepancy, apply a fallback rule using an authorized route for the country and traffic type, and assess the subsequent technical outcome to review the policy.
Sources consulted
- ITU-T E.164 (02/2026): The international public telecommunication numbering planInternational Telecommunication Union
- ITU-T E.164 (02/2026): SummaryInternational Telecommunication Union
- 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3GPP
- G-Port Feature Description: Mobile-Terminated Based GSM SMS Number PortabilityOracle Communications
- Feature Overview: Mobile Number Portability and MSISDN routingOracle Communications
- Portability Check for Mobile Originated SMSOracle Communications
- FCC: Numbering Resource Utilization in the United StatesFederal Communications Commission
- FCC: Current Local Number Portability ProcessFederal Communications Commission