Why was my SMS not delivered? Delivery statuses, errors and common causes

When a system accepts an SMS request, that does not necessarily mean the message has reached the recipient’s phone. It passes through several stages: from the application or portal, through the messaging service and mobile network, and finally to the device. A problem can arise at any stage, so the status must be read in context.

This guide explains the most important distinctions and a safe troubleshooting method. Exact fields and status values can change, so the current API documentation remains the technical authority.

Created does not mean delivered

A successful API response first confirms that the message has been registered for further processing. It does not confirm delivery to the handset. Keep the message ID returned when the message is created. Where the workflow needs delivery information, use that ID with the documented status endpoint.

It helps to group status into three stages:

• Registered or accepted: the service has received the task and can begin processing it.
• Forwarded or processing: the message is moving through provider and mobile networks, but the result is not final.
• Final outcome: the network has reported delivery or a failure that is no longer being processed.

Labels can differ between interfaces and routes. Base application logic on the documented contract rather than assuming what a word such as “sent” must mean.

What a delivery report proves

A delivery report, often shortened to DLR, is a technical acknowledgement from the messaging chain. A delivered status is a strong signal that the message reached its destination as reported by the mobile network. It is not a read receipt and does not prove that the intended person saw, understood or acted on the content.

A missing final status does not automatically mean that the message has been lost. A handset may be switched off, out of coverage or temporarily unavailable. The network may continue trying before returning a final outcome. Timing and behaviour vary by route, country and operator.

Common reasons an SMS is not delivered

An invalid or badly formatted number

An incorrect country code, missing digits, obsolete numbers and stray spreadsheet characters are common causes. Normalise numbers before sending and retain the country explicitly in your data. The phone-number tool can help before an import or API call.

The handset is temporarily unavailable

The device may be switched off, out of coverage, full or detached from the network. This may produce a temporary status that later changes. Avoid manually sending the same message again until you know whether the first attempt is still being processed.

The sender does not suit the destination

Countries and operators can apply different rules to alphanumeric sender names, numbers, registration and content. A setup that works in Norway may not behave identically abroad. Check the country and sender type in the international delivery guide and clarify special requirements before a larger send.

Content or traffic is restricted

Networks and providers may act on prohibited content, misleading sender identity, suspicious links, unusual traffic or failure to meet country rules. A single status code will not always explain filtering. Collect technical references and ask support to investigate the specific message or group.

The account, credits or request is not valid

Authentication, missing required fields, account state or insufficient credits can stop a message before it reaches the mobile network. Applications should handle these responses directly and distinguish them from a later delivery failure.

A practical troubleshooting sequence

1. Find the message ID and time. Do not begin with the entire list or another bulk send.
2. Check the creation response. Was the request accepted, or did it fail before registration?
3. Retrieve the latest documented status. Distinguish an active state from a final outcome.
4. Check the recipient. Review the country code, length and whether the number remains active.
5. Check sender and country. Confirm that the combination suits the intended workflow.
6. Compare a small sample. Determine whether the issue affects one number, operator, country or every message.
7. Collect minimal references. Give support the ID, time, status and relevant account details without spreading message content or personal data unnecessarily.

Handling status in an API integration

A production system should store the technical message ID against its own reference and distinguish “request received” from “final delivery outcome”. Use the status endpoint as described in the current documentation. Do not depend on a webhook or another mechanism unless it is confirmed for your account and API version.

Handle 400, 401 and 5xx responses explicitly. Retain X-Request-ID for troubleshooting. Check the account’s documented capabilities before using optional idempotency, and send a stable Idempotency-Key for the same logical create request. Define how long your system waits for a final status before flagging the case for review.

The developer guide explains the distinction between created and delivered, while the SMS API page provides an overview of integration and documentation. For help with a specific ID or message flow, contact Intellipush with the technical references.