SMS delivery report tool, how to read one and what it hides
Table of Contents
SMS DLR report explained, and what an SMS delivery report tool derives from it
SMS delivery rate benchmark India, and why an SMS delivery report tool has none
Submitted is not delivered
The single most useful thing an SMS delivery report tool does is separate those two words. Most dashboards blur them, and a campaign that shows ninety eight percent success at submission can land on far fewer handsets.
Submitted means your provider accepted the message. Delivered means the operator confirmed it reached a handset. Between those two sit the operator gateway, DLT scrubbing and the handset itself, and each can drop traffic without telling you plainly.
SMS DLR report explained, and what an SMS delivery report tool derives from it
DLR stands for delivery receipt. It is the status the operator sends back, and almost everything an SMS delivery report tool shows you is derived from it.
Status | What it means | What to do |
|---|---|---|
Delivered | The operator confirmed handset delivery | Nothing. This is the number that counts |
Failed | The operator rejected or could not deliver it | Read the sub reason, which is where the diagnosis lives |
Expired | Retries ran out, usually a handset off for too long | Normal in small volumes, worth checking if it climbs |
Rejected | Blocked before reaching the network, often template or header | Fix the registration, not the campaign |
Unknown | No receipt came back | The dangerous one. Not a success, and often counted as one |
That last row is where most reporting goes wrong. A report that counts unknown as delivered will always look healthy. Ask your provider directly how unknown is treated in the figure they show you.
What no SMS delivery report tool can tell you
Whether anyone read it. SMS has no read receipt, so any dashboard claiming an open rate for plain SMS is inferring it from link clicks, which is a different thing. If read status matters, that is an argument for RCS or WhatsApp, not for a better report.
SMS delivery failure reasons India
Four causes account for most of what an SMS delivery report tool flags, and they need different fixes.
DND registration. The number is on the national TRAI Do Not Disturb list for your category. Promotional traffic is scrubbed, transactional usually is not. Not fixable, and not a fault
Template mismatch at the gateway. What you sent does not match the approved DLT template, down to punctuation. These fail silently and look like network problems, which is why they are diagnosed late
Handset unreachable. Switched off, out of coverage, or storage full. Retries handle most of it
Invalid number. Wrong length, wrong prefix, or a landline in a mobile field. A list hygiene problem, not a delivery problem
The second one is the expensive mistake. The full process is in our DLT registration process India guide, and the short version is that a template drifting by one character stops the traffic.\
SMS delivery rate benchmark India, and why an SMS delivery report tool has none
Everyone asks an SMS delivery report tool for one number. There is not one, and anybody quoting a single national figure is guessing.
Delivery rate varies by traffic type, by operator mix in your list, by time of day and by how clean your database is. Transactional traffic to a recently active list behaves very differently from promotional traffic to a list bought two years ago.
The only benchmark worth tracking is your own trailing average. Record it weekly per campaign type, and treat a sustained drop against your own history as the signal. A number from a blog, including this one, tells you nothing about your list.
What to record from your SMS delivery report tool
Delivery rate split by transactional and promotional, never blended
The unknown share, tracked separately from failed
Failure reasons by cause, so a template problem is visible as a template problem
Time to delivery, not just whether it arrived
SMS delivery report API
An SMS delivery report tool you remember to check is worth less than a callback that reaches you. An SMS delivery report API pushes each status change to your own system as it happens.
What to ask a provider about theirs:
Does it push webhooks, or must you poll for status?
Does it carry the operator sub reason, or only a top level status?
How long are receipts retained and can you export the raw log?
Does it retry a failed webhook, and for how long?
The fourth matters more than it sounds. A provider that fires once and forgets will leave gaps in your records on the day your endpoint has a wobble.
What this means when choosing a provider
An SMS delivery report tool is where the difference between a direct carrier connection and a chain of intermediaries becomes visible. Each hop is a place where the sub reason gets flattened to unknown.
Ask how many hops sit between the API and the operator. That question, and the others worth asking, are in our CPaaS provider India guide. If you are comparing SMS vendors specifically, how to compare SMS services covers the rest.
Common questions
What does an SMS delivery report tool actually measure?
Operator delivery receipts. It shows whether the network confirmed handset delivery, not whether anyone read the message.
Is unknown the same as delivered?
No, and treating it as such is the most common reporting error. Ask your provider how unknown is counted in the figure you are shown.
What is a good SMS delivery rate benchmark India?
There is no reliable single figure. Track your own trailing average split by transactional and promotional, and watch for drops against your own history.
Why do messages fail with no clear reason?
Usually a template mismatch at the gateway, which fails silently and looks like a network fault. Check the approved template character by character.
Do I need an SMS delivery report API or is a dashboard enough?
A dashboard is enough at low volume. Past a few thousand a day you want webhooks, because nobody watches a dashboard at the moment a route breaks.
Where to start with Celitix
Celitix reports delivered, failed and unknown separately, passes the operator sub reason through rather than flattening it, and pushes status by webhook with retries.
Ask Celitix how unknown is counted