Why an SMS is not delivered and how to fix deliverability

An SMS that never arrives is a customer who cannot log in or an order left unconfirmed. Here are the real causes of non-delivery and the concrete actions that improve deliverability.

First: where a message can fail

An SMS travels through five stages and can be lost at any of them: the system that originates it, the provider platform, the mobile operator, the access network and the handset itself. Diagnosing properly starts with knowing which stage it stopped at, and that is what the message identifier (sid) and the delivery receipt (DLR) returned by the operator are for.

If the API rejected the request, the problem is in your system or in the connection settings. If the API accepted the message but the DLR says failed, the problem is at the operator or the recipient. If the DLR says delivered and the customer insists they never got it, the handset is where to look.

Causes on your own system

The most common and easiest cause to fix is a malformed number: duplicated prefixes, spaces, dashes, the extra 1 after 52 that is no longer used in Mexican national dialling but that some systems still add. The platform normalises to international E.164 format, but an impossible number stays impossible. Validate the format before sending and always store numbers in E.164.

Other causes: sending to landlines, duplicating messages through badly implemented retries, or exceeding one segment with concatenation disabled, which leaves the message truncated.

Causes on the platform

The API can reject a message on business rules: a number on an exclusion list (INPUT_PHONE_BLACKLISTED), insufficient credit on prepaid accounts (INSUFFICIENT_BALANCE), or a mismatch between the configured encryption mode and what was sent (ENCRYPTION_REQUIRED or ENCRYPTION_NOT_ALLOWED). It can also reject requests from unauthorised IPs (403) or with an invalid token (401).

These causes are visible immediately in the API response and in the console. They are worth monitoring: a rise in exclusion-list rejections, for example, means opt-outs are not being applied to your list.

Causes at the operator

Operators apply content and behaviour filters to A2P traffic. Messages with suspicious links, wording associated with fraud, unregistered senders or anomalous volumes from a single origin can be blocked with no notice to the sender, or marked as failed with a generic reason.

Congestion is real too: on high-traffic dates (paydays, Buen Fin, year end) operators prioritise and can delay deliveries. A provider with direct connections and redundant routes reduces the impact; a provider reselling third-party routes amplifies it.

Finally, number portability: a number that moved to a different operator can fail temporarily if the route was not updated. Direct routes check portability in real time.

Causes at the recipient

A handset that is switched off or out of coverage is the most frequent cause of delayed deliveries: the operator retries during the validity period of the message and, failing that, marks it as expired. An inactive or cancelled SIM, or a handset that does not support the message format, produces permanent failures.

On the device, sender blocks, operating-system spam filters and a full message memory (on feature phones) can mean an SMS marked as delivered is never seen by the user. Here the report will say delivered and diagnosis moves to customer support.

How to improve deliverability: concrete actions

Store and validate numbers in E.164 format before sending.
Clean the list using the reports: numbers that fail three times in a row come off it.
Separate transactional from promotional traffic on different connections.
Use registered, consistent sender IDs; avoid switching sender between messages.
Mind the content: no generic URL shorteners, no excessive capitals, no artificial urgency.
Schedule large campaigns in windows and avoid operator peak hours.
Configure webhooks so you know the status in real time and can react.
Review by operator: if one operator concentrates the failures, talk to your provider.

Grupo Tecnophone operates with direct routes to the Mexican operators and per-message, per-operator delivery reports, which shows exactly where each message is lost. If you are assessing your current deliverability, get in touch and we will review your case.

Frequently asked questions

What delivery rate is normal?

For up-to-date lists and transactional traffic over direct routes, above 99% on active numbers. On bulk campaigns over older lists, rates of 85-95% are common because of inactive numbers.

Does delivered always mean read?

No. A delivered status means the handset confirmed reception to the operator. Whether the user actually saw it depends on the device and its filters. SMS offers no read receipt.

Why does a message arrive late?

Usually because the handset was switched off or out of coverage and the operator retried, or because of congestion on the operator network at peak times. Separating critical traffic and using direct routes reduces the delay.

How do I know whether the operator is blocking my messages?

A failure pattern concentrated on one operator, with a generic reason, on active numbers, usually points to filtering. Your provider can review the route and the content with the operator.

Need an enterprise SMS platform?

Grupo Tecnophone provides enterprise SMS messaging with direct routes in Mexico, an API with sandbox and encryption, per-message delivery reports and a console for campaigns. Talk to an expert or read the developer documentation.