Once a delivery has been sent, the delivery dashboard displays a status that allows you to monitor if the sending has been successfull. Possible statuses are detailed in the section below.
For more details on the different delivery failures you can encounter, and how to solve them, refer to this page.
|| Definitions and solutions
|| The delivery was correctly sent to the message provider (but the recipient did not necessarily receive it).
|| The delivery was not sent to the recipient because of an error with his address. It was either on denylist, quarantined, not provided or a duplicate.
|| The delivery could not reach the recipient because of an invalid address or a full inbox for example. It can also be linked to an issue with personalization blocks since they can generate errors when the schemas do not match the delivery mapping. See Understanding delivery failures
|| The delivery is ready to be sent and is going to be processed by the delivery server (MTA). See Pending status.
| Not applicable
|| The delivery was taken into account by the server (MTA) but not processed.
| Delivery canceled
|| The delivery was canceled by an operator.
| Taken into account by the service provider
|| The SMS service provider received the delivery.
| Received on mobile
|| The recipient received the SMS on their mobile device.
| Sent to the service provider
|| The delivery was sent to the SMS service provider but not received yet.
|| Intermediary status used only for external connectors such as the mobile channel. It follows the 'Pending' status and is the external connector that will determine the following status.
After confirming your delivery, you can see that the status of your delivery is Pending. This status means that the execution process is waiting on the availability of some resources.
The Pending status can first mean that your delivery has been scheduled and is pending until the given date. For more on this, refer to the Delivery scheduling section.
If your delivery is not being sent and its status remains Pending, it can be the result of:
The MTA (Message Transfert Agent), that runs modules and processes on the delivery server and that manages email sending, may have not been started, or need to be restarted.
To check this and to start the module if necessary, apply the following steps:
This operation can be performed with an on-premise or hybrid hosting model with access the the Campaign server (see hosting models).
Check that your
mta@<instance> modules are launched on your MTA servers.
nlserver pdump HH:MM:SS > Application server for Adobe Campaign Classic (X.Y.Z YY.R build nnnn@SHA1) of DD/MM/YYYY [...] mta@<INSTANCENAME> (9268) - 23.0 Mb [...]
If the MTA is not listed, start it with the following command:
nlserver start mta@<INSTANCENAME>
<INSTANCENAME> with the name of your instance (production, development, etc.). The instance name is identified via the configuration files:
[path of application]nl6/conf/config-<INSTANCENAME>.xml
The delivery may be using an affinity not configured on the sending server.
In this case, check the configuration of the traffic management (IP affinity) and use the Managing affinities with IP addresses field to link deliveries to the MTA that manages the affinity. For more information on affinities, refer to this section.
When too many campaigns running, the delivery status remains in ‘Pending’ status.
The limit of simultaneous campaigns is defined in the NmsOperation_LimitConcurrency option. Default value is 10.
Learn more about options in this page.