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. Carrier 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:

  1. Not all carriers return DLR.
  2. Carriers who do return DLR may not always do so reliably. 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.
  3. There is no such thing as a “false positive” DLR. However, a carrier may generate the DLR at a different point in the message’s journey depending on traffic type. (See table below)
Traffic TypeCode TypesDLR is
P2PLong Code, 8XX*Carrier Acknowledgment
A2PShort Code, 8XX*Carrier Confirmation

*8XX traffic is currently considered strictly P2P in Canada.

Carriers send the DLR for P2P traffic back prior to applying their SPAM filters. This is done to prevent SPAMmers from gaming the system. Even if a message is not intended as SPAM, it may be caught within a carrier’s SPAM filter algorithm. To improve the success of your legitimate P2P traffic, take a look at our P2P Guidelines.

Requesting DLRs

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).


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.

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

A masterlist of carrier-returned DLR error codes can be found here.
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.


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 1557953717096