When bulk SMS stops delivering, the fastest path to a fix is a diagnostic tree: check the SIM, check the message, check the sender, then check the carrier. Most failures trace to one of four layers, and each layer has recognizable symptoms and fixes. This guide helps operators of an SMS gateway diagnose non-delivery in minutes rather than guessing.
The Diagnostic Tree
Start at the top and work down. Is the message even submitting? If not, the problem is the gateway or software layer. Is the SIM healthy and in rotation? If not, the problem is the SIM layer. Is the content or sender triggering filters? If likely, the problem is the content and compliance layer. Is the carrier rejecting or silently dropping?
If yes, the problem is the carrier layer. Each layer has its own fix, so misdiagnosis wastes days.
Common DLR Statuses and What They Mean
Status labels vary by carrier, route, and SMPP provider, so map your provider's definitions before reporting. Delivered means the network accepted the message for the handset; expired means the validity window passed; undelivered means the route or number failed; rejected means the carrier refused the message, often for content or registration reasons. A missing DLR is itself a signal, usually pointing to DLR support not being enabled on the route.
| Status | Meaning | Next step |
|---|---|---|
| Delivered | Accepted for delivery | No action |
| Expired | Validity window passed | Check retry and expiry settings |
| Undelivered | Route or number failed | Check number validity and route |
| Rejected | Refused by carrier | Check content, sender, registration |
| No DLR | Report not returned | Confirm DLR support on the route |
Layer 1: SIM and Hardware
The most common silent killer is the SIM layer. Check balance and status for blocked, suspended, or low-credit cards, signal strength on the port, rotation settings to see whether one SIM is carrying everything, and port health in the gateway dashboard. Fixes include topping up or replacing the SIM, improving antenna placement, enabling rotation, and taking unhealthy SIMs out of rotation automatically.
A worked example: a campaign that was delivering well drops from 95 to 60 percent overnight, and the DLR mix shows a rising rejected count. The diagnosis starts at the SIM view, where two cards show blocked status after the carrier throttled them for volume.
Rotation had been configured but one card carried most of the load, so the fix is rebalancing rotation, confirming the plan allowance, and adding a spare card before the next campaign. The layer was SIM, and the symptom was rejected status.
Layer 2: Content and Compliance
Carriers filter on content patterns. Trigger words, all-caps, excessive punctuation, too many links or URL shorteners, high complaint rates from previous campaigns, and unregistered sender IDs all reduce delivery. Fixes include cleaning the copy, registering sender IDs per market, honoring opt-outs, and reviewing complaint history before the next send.
Content checks are fastest with a control test: send the same message to a small list of numbers you control, change one content variable at a time, and compare delivery. If the copy without the link delivers and the copy with the link does not, the link or its reputation is the variable. The same method isolates emoji, capitalization, and sender-ID effects without guessing.
Layer 3: Sending Behavior
Behavioral problems look like carrier problems. Sending faster than the carrier allows per SIM, sending at 3 a.m. local time, retrying permanent failures, and duplicate submissions all reduce delivery. Fixes include enabling pacing, respecting quiet hours, configuring retry rules, and deduplicating by message ID.
Layer 4: Carrier and Route
When layers one through three are clean, the carrier or route is the suspect. Carrier outages and maintenance windows, route-quality drops on an aggregator route, and number portability or DND registry issues all fit here. Fixes include checking carrier status, failing over to a backup route, and testing with a control number in the same market.
Carrier-side checks need a control number that is known to be clean: a number you own, on a plan that permits the traffic, and historically reliable. When that control fails the same way as the campaign, the problem is systemic and upstream; when it succeeds, the problem is number-specific or list-specific. The control test is the fastest way to separate the two.
The runbook closes the loop. After each incident, record the symptom, the layer found, the fix applied, and the time to resolution; after a few incidents, the runbook predicts the cause from the symptom, and the escalation path is already written.
Teams that document incidents this way reduce both mean time to fix and the number of repeated tickets, because the knowledge lives in the runbook rather than in one person's memory.
Runbook quality is a management choice, not an accident. Assign an owner, review it quarterly, and test the escalation path with a drill at least once a year. A runbook that is written and ignored is decoration; one that is owned, reviewed, and drilled is the operating advantage that separates teams that recover in minutes from teams that recover in days.
Prevention is the final layer. Most of the failures in this guide share causes that monitoring catches early: SIM balance crossing a threshold, queue depth growing, delivery rate falling, or a route's DLR latency rising. Set alerts on those leading indicators, and the diagnostic tree becomes a rare event rather than a weekly ritual, because the operation fixes problems while they are still small.
The prevention layer also includes the list itself: number validation, opt-out processing, and complaint tracking happen before the send, not after the failure. A clean list with honest consent and current numbers prevents a large share of undelivered and rejected traffic, which makes list hygiene the cheapest fix in the entire diagnostic tree.
Keep the diagnostic tree visible to the whole team: a one-page poster of the four layers, the status table, and the control-test method turns a support ritual into shared knowledge. When everyone operates from the same tree, diagnosis is consistent, tickets get resolved faster, and the runbook stays current because the team uses it daily.
The final habit is calibration: after each incident, ask whether the monitoring would have caught it earlier, and adjust the alert thresholds accordingly. Diagnosis improves delivery, and calibration improves diagnosis, which is how an operation compounds its reliability month after month.
A Repeatable Investigation Routine
Pull the DLR breakdown for the affected campaign, test one message to a number you control in the same country, compare results across SIMs, routes, and message variants, fix the layer the data points to, re-test, and document the cause in a runbook for next time. The SMS gateway solution guide covers the dashboards and settings used in each step.
Documentation turns incidents into learning. Record the date, the campaign, the DLR mix, the layer diagnosed, and the fix applied; after a few incidents, the runbook starts predicting the cause from the symptom, and diagnosis time drops from hours to minutes.
Telarvo Expert Views
The silent-drop case is the hardest to diagnose because nothing looks wrong: messages submit, no reports return, and delivery quietly fails. The discipline that solves it is working the layers in order, testing with a control number, and documenting the result so the next occurrence is recognized in minutes.
— Messaging Operations Engineer, Telarvo Store
Conclusion
Non-delivery has four layers, and the fix order is SIM, content, behavior, then carrier, with a control test and a documented runbook at every step.
Key Takeaways for B2B Buyers
Work the diagnostic tree in order, map DLR statuses to your provider, test with a control number in the affected market, and document each incident so the next one is faster.
Questions to Ask Before Committing
Ask how the gateway surfaces SIM health and DLR status per message, whether pacing and retry rules are configurable, and how route failover works when a carrier stops returning reports.
FAQs
Why do my messages send but never arrive?
This is the classic silent-drop symptom, usually carrier filtering or route quality; check content, sender registration, and DLR statuses first.
Why is delivery fine for some numbers but not others?
Likely carrier-specific or number-type issues such as ported numbers, DND lists, or prepaid numbers behaving differently.
Can I fix delivery by changing hardware?
Only if the problem is hardware, such as signal, SIM health, or capacity; content and compliance issues follow you to any box.
How long should I wait before retrying a failed message?
For transactional traffic, seconds to a few minutes with backoff; never retry permanent failures.