Your SMS delivery receipt is lying (and in which countries)
· 4 min read
If you send SMS through an API, your dashboard says delivered and you treat
the message as received. In Spain that is almost always true. Outside Spain,
often it is not: that delivered only means that the operator's network
accepted the message, not that it appeared on anyone's screen.
The difference looks like a technical detail. It is not: it is the reason a customer swears the verification code never arrived while you hold a record that says it did.
The four meanings of "delivered"
The delivery receipt —the DLR, delivery report— travels back from the mobile network to your provider, and not every network reports the same thing:
| What the receipt confirms | What you actually know |
|---|---|
| Delivery to the handset | The message reached the phone. This is the good case. |
| Acceptance by the network | The operator took charge of it. It may end up delivered, held or discarded. |
| Partial | Some networks in the country report real delivery and others do not. |
| No receipt | There is no information: the status stays at "sent" and that is the end of it. |
Spain, Portugal, Germany or the United Kingdom usually report delivery to the handset. Much of Latin America, Africa and Asia report network acceptance, and some destinations report nothing at all. A single prefix can show both behaviours: within +1 there are networks that report and networks that do not, so a rule for "+1" is simply false.
Why this costs money, not just accuracy
Three concrete consequences, in order of severity:
1. The automatic refund closes for good. If your platform treats
delivered as a final status —and it should— a network receipt closes the
case. The message never arrived, nobody retried it and the failure was
silent: no error, no alert, nothing to look at.
2. Your metrics lie upwards. For a destination that only reports acceptance, your "delivered" rate does not measure deliveries: it measures acceptances. If you make routing decisions with that number, you make them with data that does not say what you think.
3. OTPs get lost in silence. This is the most expensive case: the user
cannot log in, does not try again and leaves. You see a delivered and there
is nothing to investigate.
How to know what your provider is telling you
Ask this in writing, country by country, before agreeing on rates:
- Does the receipt confirm delivery to the handset or acceptance by the network?
- Which error codes do you return and what does each one mean?
- Does the receipt arrive by webhook with retries, or does it have to be queried?
- Do you rewrite the sender in any destination?
If the answer is "delivered means delivered", be wary: nobody who really operates international routes can say that without qualification.
What we do about this problem
At SMSverifica the receipt level of each destination is a piece of system data, not a note in an email. Every country has a declared statement of what its receipt confirms, with its source and its date, and that has three effects:
- You are warned BEFORE sending, in the dashboard and in the API, when the destination does not confirm delivery to the handset. Sending is not blocked: blocking a legitimate destination because of a third party's data would be worse.
- The warning is frozen into the message: a year from now you will know what was known on the day it was sent, not what we know today.
- Unknown data is never treated as good, and data verified more than six months ago downgrades by itself. If nobody publishes the receipt level of a destination, we say that it is not known.
And there is one place where a warning is not enough: in certified messaging, what is being sold is precisely the statement of delivery. There the system is strict: if the destination does not confirm delivery to the handset, the certificate is not issued. We would rather lose that sending than sign a document we could not stand behind before a third party.
What you can do in your integration today
- Do not treat
deliveredas proof for destinations that only confirm the network. Store the receipt level alongside the message. - For OTPs, add a second channel: if the SMS is not confirmed within 30-60 seconds, offer WhatsApp, a call or a resend. It is cheaper than losing the user.
- Measure by destination, not globally. An average rate hides exactly the country that is failing you.
- Ask your provider for the data in writing and keep it with its date: it changes over time and with the routes.
We publish the price of every destination and warn you about what its receipt confirms before you send. You can see it in prices and destinations or try it with your own code: once you verify your email, test mode opens and the API works without spending a single euro.