HLR lookups before sending: when number validation pays for itself
HLR lookups query the live mobile network before you send: is the number active, and which operator serves it now. That beats static MCC-MNC tables once portability is in play. This article covers what a lookup returns, pure arithmetic against the published SMSRoute rate of US $0.0125 per message, and when validation pays—or does not.
What an HLR lookup is
An HLR lookup is a live network query against the Home Location Register path (or equivalent modern routing infrastructure) for a mobile subscriber. You submit an E.164 number—up to 15 digits, country code included—and the query asks the serving network stack whether that identity is known, whether it is presently reachable in routing terms, and which network currently owns the subscription for termination.
It is not a local format check and not a static table join on the first digits. Format validation only confirms that a string could be a number. An HLR-class query asks the network plane. That distinction matters for bulk SMS because send cost accrues per attempted message at the gateway, including attempts to numbers that will never accept traffic.
From an integration perspective the pattern is ordinary: authenticated HTTP request, idempotent query per MSISDN, parse a structured result, decide whether to enqueue the MT message. Expect standard HTTP outcomes such as 200 on a completed query, 429 under rate limit, and 500-class failures when the upstream query path is unavailable. Retry and backoff belong in your client; the lookup itself does not replace consent checks or content policy.
SMSRoute publishes its per-message rates openly (US $0.0125 all-in), which is what makes this arithmetic checkable.
What the response typically gives you
Providers differ in field names, but the useful signal clusters are consistent. You learn whether the number appears valid and active on a mobile network, whether it is absent or decommissioned from routing, and which network is indicated as serving it now—often expressed as operator identity rather than the original issuer. Some responses also surface roaming or reachability flags; treat those as advisory and provider-specific.
What you do not get is permission to message. HLR shows network-level reachability and current routing affiliation. It does not show opt-in state, preference flags, handset filtering, silent drops, or user intent. A number can be live on the network and still be wrong for your use case. Build suppression and consent stores separately; use HLR as a cost and routing pre-filter, not as a compliance oracle.
For SMS payload planning the usual segment limits still apply after you decide to send: 160 characters for a single GSM-7 segment, 153 per segment when concatenated, 70 for a single UCS-2 segment, and 67 per segment when concatenated UCS-2. HLR does not change encoding math. It only changes whether you spend a send attempt on that destination at all.
MNP and why static MCC-MNC allocation is not enough
Mobile Number Portability (MNP) lets a subscriber keep the same MSISDN when moving between networks. The national prefix and early digit groups that once mapped cleanly to one operator stop being authoritative after a port. Static MCC-MNC allocation tables—built from original number ranges—therefore mis-attribute a growing share of destinations.
If your pipeline picks routes, commercial terms, or sender features from range tables alone, ported numbers go down the wrong path. You may pay the wrong commercial bucket, hit a less reliable interconnect, or apply the wrong operator assumptions. An HLR-class query asks who serves the number now, which is the question portability forces you to reopen at send time.
Portability is not uniform in process or latency across markets, and not every destination country exposes the same richness of lookup data. The engineering stance is conservative: treat range tables as hints for defaults, and treat live lookup as the correction layer where your volume and dead-destination rate justify the extra round trip.
The SMSRoute country fact sheets carry each market's dated published rate for the same math.
Economics: when validation pays for itself
Use pure arithmetic against the published SMSRoute send price of US $0.0125 per message. Do not assume a universal dead-number share; that share varies by list source, age, and collection method. Write the waste term as: wasted_send_spend = list_size × dead_share × 0.0125. That is money spent on attempts that cannot produce a delivered SMS because the destination is not a live mobile termination target.
A validation pass costs its own per-query fee. Per-query fees vary by provider; this article does not invent a lookup price. Write lookup_spend = list_size × lookup_fee_per_number. Validation pays when the send waste you avoid exceeds what you spend to query: dead_share × 0.0125 > lookup_fee_per_number, for a single planned send to each surviving number. If you will message the same cleaned list multiple times, multiply the left side by the number of planned campaigns before the list ages again.
Worked example in symbols only. Suppose list_size is N and dead_share is D (a fraction you measure from your own samples, not an industry constant). Avoidable waste on one full send is N × D × 0.0125. If your provider’s lookup fee is L per number, the pass costs N × L. Break-even is D × 0.0125 = L, or D = L / 0.0125. When your measured D is higher than that break-even fraction, the pass pays on the first send. When lower, you lose money by querying everyone.
Practical measurement beats folklore. Sample a slice of any cold or aged list, run lookups on the sample, observe how many are non-reachable, and compute D from your data. Then plug in your actual L from the provider contract. The inequality is the whole decision. Gate full-list validation on that result rather than on habit. Also account for query failures: an HTTP 429 or 500 is not a network-dead number; do not suppress on transport errors.
When HLR validation does not pay
Fresh opt-in lists collected moments earlier through your own verified flows usually carry a low dead-share. If users typed a live handset number and confirmed it, D is often too small for dead_share × 0.0125 to clear a positive L. In that regime, skip blanket pre-send HLR and rely on bounce and delivery receipts to maintain suppression.
Transactional replies and tight session messages are another weak case for bulk pre-validation. The destination just interacted; the number was good enough to complete a step. Adding a lookup round trip increases latency and cost without much waste avoided. Reserve lookups for outbound campaigns to stored lists, re-engagement cohorts, and any file you did not collect first-party in the recent past.
Thin margins and one-time small sends can also fail the inequality simply because fixed integration cost and minimum query billing units dominate. If N is small, even a favorable D may not repay engineering time. Conversely, very large N with a measured mid-to-high D is where the arithmetic usually flips positive—again using your L and your D, not a brochure average.
Finally, if your send path already prices only on successful handoff under terms you have verified, re-read the contract before assuming every dead destination costs the full 0.0125. The published rate used here is US $0.0125 per message; apply the inequality to the unit cost you actually incur on failed destinations.
Operational notes and honest limits
Wire HLR as a pre-queue step: normalize to E.164, query, map outcomes to send, suppress, or retry-query states, then only enqueue MT traffic for numbers that clear your reachability policy. Log correlation IDs across lookup and send so you can audit why a destination was dropped. Respect provider rate limits; a flood of queries that draws HTTP 429 helps nobody.
HLR does not guarantee delivery. Nothing in the lookup path promises that a later SMS will reach the handset inbox. Downstream filtering, handset state, congestion, and content policy still apply. HLR also does not prove consent. Keep lawful basis and opt-in evidence in your own systems. Reachability is necessary for efficient sending; it is not sufficient for compliant sending.
Re-query cadence should track list age and portability churn in your markets. A clean result is a snapshot, not a lifetime certificate. For numbers you message often, receipts and error codes from the SMS path may already maintain a stronger live suppression list than repeated blanket HLR. Use lookup where snapshots are cheap relative to avoided sends; use delivery feedback where the conversation is ongoing.
Frequently asked
- What is an HLR lookup before sending SMS?
- It is a live network query on an E.164 mobile number that checks whether the identity is active in routing terms and which network serves it now. It corrects static MCC-MNC range assumptions broken by number portability, and it is separate from consent or spam-filter outcomes.
- When does HLR number validation pay for itself?
- When dead_share × send_cost exceeds per-query lookup cost. With SMSRoute at US $0.0125 per message, break-even is dead_share = lookup_fee / 0.0125 for one send per number. Per-query fees vary by provider; measure dead_share on your own list sample rather than assuming a fixed rate.
- Does HLR replace opt-in or guarantee SMS delivery?
- No. HLR indicates network reachability and current serving network signals, not permission to message and not final delivery. Consent stores, suppression, encoding limits (160/153 GSM-7, 70/67 UCS-2), and downstream filtering remain your responsibility.