SMS delivery receipts vs HLR lookup: before or after you send

A delivery receipt (DLR) tells you what happened to a message after you sent it. An HLR lookup asks the recipient's home network, before you send, whether the number is assigned and reachable. The receipt is free with most sends but arrives late. The lookup costs a query but saves wasted sends. Many teams use both.

#What does each one answer?

Both come from the same mobile network machinery, at different moments. The comparison in one table:

The short version: a DLR is an outcome, an HLR lookup is a forecast. Our glossary has short entries on the delivery receipt and the HLR lookup.

#How does a delivery receipt work?

When you submit a message, your provider (or you, if you connect directly) can request a receipt. In SMPP, the protocol most message centres speak, you set a flag on the submission, and the message centre later sends back a receipt as a separate message. The SMPP 3.4 specification is blunt about it: "To determine the eventual outcome of the SMS delivery, the ESME must request an SMSC Delivery Receipt" (SMPP Developers Forum).

The specification lists the final message states a receipt can carry:

Two details matter in practice. First, the spec gives only a "typical example" of the receipt text and leaves the exact format to each message-centre implementation. Second, the err field "may hold a Network specific error code or an SMSC error code", and those codes are not standardized in SMPP (SMPP Developers Forum). Your provider translates them, or passes them through.

Inside the mobile network, the handset's acknowledgement travels back as an SMS status report, defined in 3GPP TS 23.040 (3GPP). That is where a real DELIVRD comes from.

#Is a DLR proof of delivery?

It is strong evidence, with caveats:

• Some routes answer early. An intermediary can report delivery when it hands the message on, not when the phone confirms. The result looks like a delivered message that nobody received.
• Receipts can be slow. Amazon notes that "depending on the destination phone number's carrier, it can take up to 72 hours for delivery logs to appear" (AWS).
• Delivered isn't read. The handset may file the message as spam or hide it.
• No receipt isn't failure. Missing receipts are common on some routes.

For OTP, the verification rate (codes entered ÷ codes sent) is a more honest delivery metric than receipts. For marketing and notices with consent, receipts are what you have. Watch them per route and per country, not only in total.

#How does an HLR lookup work?

Before an SMS can reach a mobile phone on another network, the sending side asks the recipient's home network where to deliver it. That routing query, part of the MAP protocol in 3GPP TS 29.002 (3GPP), is what an HLR lookup performs, without sending a message. The reply shows whether the number is assigned, whether the subscriber can be reached, and which network currently holds the subscription, so it also reveals porting.

It has limits. It works only for mobile numbers. Some operators block or mask external queries. And the raw reply contains identifiers, such as the IMSI and the serving switch address, that should never leave the telecom side. The HLR vs MNP vs number validation guide covers the wider comparison.

#What do the network errors mean?

Whether you meet them in a receipt's error field or in an HLR reply, the same MAP errors keep coming up. The names come from 3GPP TS 29.002. The codes are the MAP local error values in its error module (3GPP).

Your provider may show these under its own labels. The point is the category: not assigned (stop), temporarily unreachable (retry or switch channel), not allowed (stop), network trouble (retry).

#Should you run the lookup before or after sending?

It depends on what a failed send costs you. A decision table:

A rough rule: if you'd act differently depending on the answer, and you'd have to act before a receipt arrives, check before sending.

#What does MobileValidate offer today?

Today, validation and normalization run free on every request, and the carrier lookup returns line type, current carrier, country and, when a number was ported, the original carrier. The HLR lookup is coming soon. It is switched off for everyone, including test keys:

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900001"], "checks": ["hlr"]}'

{"error": {"code": "service_disabled", "message": "The check 'number.hlr' is currently unavailable.",
  "status": 403, "retryable": false, "param": "checks[0]",
  "doc_url": "https://mobilevalidate.com/docs/errors#service_disabled"}}

When it launches, number.hlr will return status (reachable, unreachable, invalid or unknown), ported, roaming as true or false only, network, mcc_mnc and country. It will never return the IMSI, the serving switch, cell or location. The test numbers are already defined on the test mode page, so you can write the handling code now.

On billing: reachable, unreachable and invalid will be conclusive and billed. You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate). Delivery receipts come from your messaging provider, not from us.

#How do you use both together?

The two signals complement each other, and the combination catches things neither sees alone:

1. Before sending: normalize, check line type, and (once available) check live status for high-stakes sends.
2. At send time: request delivery receipts and store the message ID with the number's checked_at.
3. After sending: classify receipt errors into stop, retry or switch channel.
4. Feed back: numbers with unknownSubscriber receipts go to a re-check or removal list. Numbers absent for weeks get re-confirmed.
5. Measure: track delivered-receipt rate and, for OTP, verification rate per country and route.

#How should you store and act on receipts?

Receipts are only useful if you can join them back to a number and a decision. A few habits make that easy:

• Store the message ID your provider returns, with the masked number, the country, the route or sender ID and the time of sending.
• Keep the raw status and error next to your own category (delivered, retry, stop, switch channel). Provider labels change. Your categories shouldn't.
• Set a deadline. If no final receipt arrives within your window (minutes for OTP, a day or more for notices), record "no receipt" as its own state instead of assuming success.
• Count per number over time. One failure is noise. Three unknownSubscriber answers in a row are a pattern worth acting on.
• Don't keep more than you need. Delivery logs contain phone numbers, so apply the same retention rules as for the rest of your customer data.

#What are the key takeaways?

• A delivery receipt reports the outcome after you paid. An HLR lookup forecasts reachability before you send.
• SMPP defines receipt states such as DELIVRD, EXPIRED and UNDELIV, but leaves the text format and error codes to each implementation.
• Receipts can be early, late or missing, so use verification rates for OTP.
• MAP errors fall into four groups: not assigned, temporarily unreachable, not allowed and network trouble. Act on the group.
• MobileValidate's carrier lookup is available now. The HLR lookup is coming soon and will never expose SIM or location identifiers.

For the full list of reasons a text doesn't arrive, read why SMS messages aren't delivered. For checking whether a number is in use at all, see how to check if a phone number is active.