What "delivered" means (and what it doesn't)

The delivery report says delivered at 14:02:11. The customer, on the phone at 14:40, says she never got anything. Both can be true, and working out how is the whole subject of what a receipt is.

A delivery receipt is one word and a timestamp standing in for a chain of handshakes between your provider, an operator's message centre and a handset. Two standards define those handshakes, one for each end of the chain. Neither of them says what most people assume "delivered" says.

Two standards, one word

The phone end is 3GPP TS 23.040, "Technical realization of the Short Message Service", the document that has defined SMS since the GSM days and is now at version 19.0.0 (October 2025). It describes the message centre (the SC, for service centre, which the operator runs), the short message entity (the SME, which for our purposes is the phone), and the status report the SC can send back about a message it was asked to deliver.

The business end is SMPP, the Short Message Peer to Peer protocol, which is how an SMS provider's gateway talks to a message centre. The version everyone still implements is 3.4, Issue 1.2, dated 12 October 1999 and published by the SMPP Developers Forum. It defines the delivery receipt: the message the SMSC sends back to the provider once it knows what became of a text.

So "delivered" in your dashboard is a translation of an SMPP receipt, which is itself a translation of a 3GPP status report, which is the operator's record of a handset acknowledging a message. Each step is well defined, and the chain ends at the handset's acknowledgement, with nothing after it.

What the phone tells the network

TS 23.040 section 3.2.9, "Status report capabilities", says the SC can tell the sender one of two things about a message: it was "Successfully delivered to the SME", or "The SC was not able to forward the message to the SME", with the reason being permanent (its examples are "validity period expired, invalid SME address") or temporary ("SC-SME connection being down, SME temporarily unavailable"). The section also says the whole facility "is optional, i.e. the choice of whether to offer status report or not is left to the SC operator".

The detail is in section 9.2.3.15, the TP-Status field: one octet, with its values grouped into four classes.

Three outcomes count as the transaction completing. The first is "Short message received by the SME", which is the one your dashboard turns into "delivered". The second is "Short message forwarded by the SC to the SME but the SC is unable to confirm delivery", a value that exists precisely because the SC sometimes hands a message on and never hears back, and the standard wanted an honest code for it. The third is "Short message replaced by the SC".

Then six temporary errors where the SC is "still trying to transfer" the message: congestion, SME busy, no response from SME, service rejected, quality of service not available, error in SME. Then ten permanent ones where it has stopped: remote procedure error, incompatible destination, connection rejected by SME, not obtainable, quality of service not available, no interworking available, validity period expired, deleted by the originating SME, deleted by SC administration, and "SM does not exist". And six more temporary errors where the SC has also given up.

The shape of a receipt follows from that list. Every one of the 25 outcomes is about the transfer of the message to the phone. There is no value for opened, displayed, read or understood, and there couldn't be, because the handset acknowledges receipt of the message, and nothing in the protocol asks it to report what the person did next.

What the message centre tells your provider

On the SMPP side, a provider asks for a receipt when it submits the text, using the registered_delivery field. Section 5.2.17 gives the options: no receipt (the default), a receipt "where final delivery outcome is delivery success or failure", or a receipt only on failure. There's also a bit for an "intermediate notification", which the spec says the SMSC "may" send to report, for instance, "the outcome of the first delivery attempt that has failed but the message is still held in the SMSC for further delivery attempts", and which it then declares "beyond the scope of this specification".

The receipt comes back as a deliver_sm, the same operation the SMSC uses for an inbound text, with the receipt in the message body. Appendix B lays out the format: the message id the SMSC assigned at submission, counts of messages submitted and delivered, a submit date and a done date (the time the message "reached it's final state", apostrophe the spec's own), a seven-character stat field, a three-character err field for a network or SMSC error code, and the first 20 characters of the original text. Table B-2 lists the seven values stat can hold.

The full list of message states in section 5.2.28 adds ENROUTE, value 1, for a message that's still in transit, which never appears in a final receipt but does appear if the provider queries the message. That's the state a text is in while an operator retries a phone that's switched off.

Two things about this table matter for reading your own reports. First, DELIVRD is the only success state, and it means the SMSC was told the message reached its destination, which on a GSM network means the 3GPP "received by the SME" above. Second, the receipt has one line for a reason, the err field, and the spec says those codes "are Network or SMSC specific and are not included here". So when your provider shows a failure reason, it's interpreting a code the standard deliberately left to each network. The names are consistent; the explanations are a best effort.

The read receipt that exists on paper

SMPP does have a concept of "read". Alongside the SMSC delivery receipt, section 5.2.17 lets the sender request an "SME Delivery Acknowledgement", and the overview explains that, "despite its name", it "is not an indication that the short message has arrived at the SME, but rather an indication from the recipient SME that the user has read the short message". For a phone, it says, that acknowledgement "is sent when the MS user or MS application has read the message from the SMS storage unit (e.g. SIM card)".

That requires the phone to originate a message back, of its own accord, saying the text was read. The 3GPP status report, which is what the operator's SC can produce without the phone's cooperation, has no such value. A read acknowledgement is a thing the handset would have to volunteer, and a delivery report built from SMSC receipts has nowhere to put one. Which is why no delivery report you'll see shows "read", and why the "98% open rate" on every vendor's homepage has no measurement behind it.

What "delivered" proves, and what it never can

Put the two standards together and a receipt reading delivered proves a specific, narrow thing: the operator's message centre received an acknowledgement that the message was handed to the handset associated with that number, and the time at which it did. That is worth having. It rules out the number being dead, the message sitting in a queue, and the operator rejecting it, and it gives you a timestamp you can put next to a customer's "I never got it".

What it doesn't prove is anything after the handset. It doesn't show that a notification appeared, that anyone saw the message, that the person who saw it was the account holder, or that it was read. Nor, strictly, that it reached a particular device: the SME is "the destination", and if the number's SIM is in a drawer in a different phone, that's where "delivered" points.

The opposite case matters too. A report that isn't delivered doesn't always mean the text failed. "Forwarded by the SC to the SME but the SC is unable to confirm delivery" is a completed transaction in the standard; a provider may show it as sent, or delivered, or as something in between, depending on how it maps the code. And an operator that doesn't return status reports at all (the standard allows this) leaves the provider with nothing but its own "sent" to show.

Reading a real report

GOV.UK Notify's API documentation is a good public example of a provider being careful with these words, because it has to be: it has sent 5.7 billion texts for public bodies. Its text message statuses are created ("placed the message in a queue, ready to be sent to the provider"), sending ("sent the message to the provider"), pending ("waiting for more delivery information"), delivered ("The message was successfully delivered"), and three failures. A permanent failure means the provider could not deliver, for example because "the phone number is wrong or the network operator rejects it". A temporary failure means it could not deliver because the phone is "off, has no signal, or the inbox is full". A technical failure is a fault between Notify and its provider, and it's the only one Notify doesn't charge for. The documentation also says the provider "may try delivery for up to 72 hours" while a message sits as sending or pending.

Set that against the standards and it maps cleanly. Pending is ENROUTE. Permanent failure is the 3GPP permanent class. Temporary failure is the temporary class, and the 72 hours is, in effect, the validity period during which the SC keeps trying. Delivered is "received by the SME". There's no read status because there's nothing to populate it from. The one quality figure Notify publishes on its performance page is the share of messages "sent within 10 seconds", 100.00% on each day shown when I read it on 17 October 2026, and even that word is "sent", meaning handed to the provider, which is as far as Notify can speak for itself.

What to do with your reports

Treat delivered as the ceiling, and treat its timestamp as the fact. If a customer says they never got the text, the honest reply is that the network confirmed it reached the phone registered to that number at that time, and then to ask whether the number is right and the phone is the one they're holding. The receipt doesn't let you say more than that, and saying more loses the argument.

Watch permanent failures, because they're the receipt doing its most useful job: each one is a number that doesn't work, and sending to it again tells you nothing new. Let a temporary failure run its course (Notify's provider allows up to 72 hours) before you resend, or you'll deliver the same reminder twice when the phone comes back on. And where the text needs an answer, ask for one in the text. "Reply C to confirm" turns a delivery receipt into something the standards can't give you: proof a person read it.

CaptiFi Connect shows every text as a timeline, with the sent, delivered and failed events as they arrive from the network, and sends the same events to your own systems as signed webhooks. The words on that timeline are the SMPP words above, with the time the network gave them.

The oddest of the seven receipt states in the 1999 spec is ACCEPTED, which means the message "has been manually read on behalf of the subscriber by customer service". It's the closest the standard comes to a read receipt, and what it describes is a member of staff reading the text for the subscriber.