Search Results

Delivery Confirmation

Outbound Message Delivery Stages

A message’s lifecycle is representative of its travel from one SMS entity (SME) to another. An SME can be a mobile device or a messaging application and is responsible for initiating or receiving an SMS message.

After a message is sent, there are three basic phases at which its progress is confirmed:

  1. Gateway Acknowledgment: A Transaction GUID (Globally Unique Identifier) has been generated and the outbound message is live in the Aerialink network.
  2. Carrier Acknowledgment: The outbound message has reached the carrier SMSC successfully and it is being processed for delivery to the end-user.*
  3. Handset Confirmation: The carrier has sent the outbound message to the end-user handset.

* Our Platform Portal Activity Report will reflect “success” in the delivery field if we have received a Carrier Acknowledgment. A “failed” status indicates that the message did not reach the SMSC.

Activity Report Status

The Activity Report in the Aerialink Platform portal displays the status of the message within the Aerialink network. Below are the statuses displayed in the report.

Outbound (MT) Statuses

MTSUCCESSTransaction generated; message successfully passed to carrier.
MTFAILMessage did not reach carrier successfully
MTBLOCKEDMessage was blocked from reaching carrier.
MTQUEUEDMessage queued to be sent to carrier.
MTPROCESSINGMessage being processed before sending.

Inbound (MO) Statuses

MOSUCCESSMessage successfully forwarded to endpoint.
MOPENDINGMessage in process of forwarding to endpoint.
MOFAILMessage did not forward to endpoint successfully

Delivery Receipt

Delivery receipts or “DLR” provide details about the success or failure of an outbound message, such as:

  • The ID of the MT message. This is a positive 64 bit integer used to uniquely identify an SMS message as it passes through the Gateway.
  • A date, giving the time at which the delivery event occurred.
  • A delivery report type code giving an overview of the delivery status of the message.
  • A detailed reason code, giving further information on the reason for the delivery report.

These details are provided to Aerialink by the carrier and passed to Aerialink customers unaltered.

However, there are additional factors to consider when reviewing a DLR:

  • Not all carriers return DLR. Most carriers in the U.S. and Canada return DLR.
  • Carriers who do return DLR may not always do so reliably. Returning DLR is a lower priority than message delivery, so DLR are not guaranteed. International carriers have been known to change this offering on occasion. Therefore, the lack of a DLR from a carrier may not indicate an issue. DLR are great for spot checking but should not be relied on for 1:1 delivery confirmation.

DLR for Concatenated Messages

Note that in the case of concatenated messages sent via the HTTP REST API, a multi-segment message will return only return a DLR for one of the message’s segments. Which segment is awarded the DLR is not consistent. This is common for wireless providers such as Verizon, who typically return only one DLR for a concatenated message.


Aerialink does support DLR for MMS messages, but keep in mind that MMS DLR - like all DLR - are at the discretion of the carrier. Not all carriers may support DLR for MMS, even if they support DLR for SMS.

10DLC Carrier DLR

A DLR for a 10DLC message indicates the message has reached the message hub successfully and is being processed for delivery to the handset. It is not a handset DLR, and is returned prior to the application of carrier anti-spam filters. Therefore, a positive DLR may be returned for messages blocked as spam.

Requesting DLRs

Most DLRs must be requested at the time that your outbound (MT) message is submitted via API or the Send a Message function of the Aerialink Platform portal. The DLR will then be delivered in the form of an inbound (MO) message to the URL that you specify in your account configuration (and are also visible via the Activity Report in the Aerialink Platform).

If the request type is “solicited,” a request must be submitted to receive DLR. If “unsolicited,” DLR is returned automatically.

SenderMessage TypeRequest Type
Short CodeSMSSolicited
Short CodeMMS*Solicited

* Short Code MMS DLR not supported by Canadian carriers

DLR Fields Returned

idtransactionGUID (unique message identifier)
subindicates whether the message was submitted
dlvrdindicates whether the message was delivered
submit datethe date/time the message was submitted
done datethe date/time the message reached the carrier
statmessage status - “DELIVRD” indicates that the carrier has confirmed delivery as successful at the latest point in the process for that traffic type
errerror code (if applicable)
textthe first twenty characters of the message

Please note that the codes are separated by code type on the “sheet” (or tab) level within the spreadsheet. Ensure that you direct your attention to the appropriate tab when searching for the code.


Most major carriers will return the value of DLRs in the Message Text field as an inbound message. However, some carriers - most notably U.S. Cellular - return the DLR information in another way. U.S. Cellular returns their DLR data in the TLV tag, directly after the tag number 0x0427. Below are the possible TLV DLR values provided by U.S. Cellular.


Delivery Receipt Response Codes

For a breakdown of carrier-returned DLR error codes please see our DLR Response Codes Masterlist.

Carrier Delivery Trace

Should there be a delivery-related concern, Aerialink can perform a manual trace to a carrier network requesting confirmation of the message’s end destination. Depending on carrier, this step can take anywhere from two to ten days.

Numbers API Lookup

The Aerialink Numbers API lookup is a query service which provides telephone number information useful for troubleshooting delivery issues. Some of the information provided includes:

  • landline or mobile status
  • number validity
  • mobile carrier
  • country

Aerialink customers concerned that messages are not reaching their destinations or are not doing so in a timely manner should initiate a support request. Aerialink can run special traces to a carrier via our connections to verify the message’s end location.

Device Information Detection

There are some creative ways to detect the phone type and model. Please inquire with an Aerialink Engineer who can explain how a small amount of coding on your side can provide you with some of this value added data.

Retry Period

If an SMS message cannot be delivered to its destination immediately for any reason, the carrier SMSC will invoke a retry procedure with which they may continue to attempt delivery over a period of time before the message is considered to have failed. If the recipient device is powered off, for example, the message will be kept in an operator’s retry scheme for the duration of their retry period (24, 48 or occasionally 72 hours depending on SMSC), after which point the message will expire.

Store and Forward

SMS is a store-and-forward technology, which means that when a message is sent, it is first stored in an SMSC before being forwarded to its end destination. This means that if the destination handset is unable to receive the message immediately, the message can be forwarded to its recipient at a later point in time.

Because of the nature of store-and-forward technology, the likelihood that a message can be completely lost is very minimal. In the instance that a message is dropped, there are usually internal notifications which are triggered so that action can be taken.

This page was last updated 1651872754103