Understand delivery failures delivery-failures
Bounces are the result of a delivery attempt and failure where the ISP provides back failure notices. Bounce handling processing is a critical part of list hygiene. After a given email has bounced several times in a row, this process flags it for suppression.
This process prevents systems from continuing to send invalid email addresses. Bounces are one of the key pieces of data that ISPs use to determine IP reputation. Keeping an eye on this metric is important. “Delivered” versus “bounced” is probably the most common way of measuring the delivery of marketing messages: the higher the delivered percentage is, the better.
If a message cannot be sent to a profile, the remote server automatically sends an error message to Adobe Campaign. This error is qualified to determine whether the email address, phone number or device should be quarantined. See Bounce mail management.
Once a message is sent, you can view the delivery status for each profile and the associated failure type and reason in the delivery logs.
When an email address is quarantined, or if a profile is on denylist, the recipient is excluded at the delivery preparation step. Excluded messages are listed in the delivery dashboard.
Why has the message delivery failed delivery-failure-reasons
There are two types of error when a message fails. Each delivery failure type determines if an address is sent to quarantine or not.
-
Hard bounces
Hard bounces are permanent failures generated after an ISP determines a mailing attempt to a subscriber address as not deliverable. Within Adobe Campaign, hard bounces that are categorized as undeliverable are added to the quarantine list, which means they wouldn’t be reattempted. There are some cases where a hard bounce would be ignored if the cause of the failure is unknown.Here are some common examples of hard bounces: Address doesn’t exist, Account disabled, Bad syntax, Bad domain
-
Soft bounces
Soft bounces are temporary failures that ISPs generate when they have difficulty delivering mail. Soft failures will retry multiple times (with variance depending on use of custom or out-of-box delivery settings) in order to attempt a successful delivery. Addresses that continually soft bounce will not be added to quarantine until the maximum number of retries has been attempted (which again vary depending on settings).Some common causes of soft bounces include the following: Mailbox full, Receiving email server down, Sender reputation issues
The Ignored type of error is known to be temporary, such as “Out of office”, or a technical error, for example if the sender type is “postmaster”.
The feedback loop operates like bounce emails: when a user qualifies an email as spam, you can configure email rules in Adobe Campaign to block all deliveries to this user. The addresses of these users are denylisted even though they did not click the unsubscription link. Addresses are added to the (NmsAddress) quarantine table and not to the (NmsRecipient) recipient table with the Denylisted status. Learn more about feedback loop mechanism in the Adobe Deliverability Best Practices Guide.
Synchronous and asynchronous errors synchronous-and-asynchronous-errors
A message delivery can fail immediately, in that case we qualify this as a synchronous error. If message sending fails or later on, after it has been sent, the error is asynchronous.
These types of errors are managed as follows:
-
Synchronous error: the remote server contacted by the Adobe Campaign delivery server immediately returns an error message. The delivery is not allowed to be sent to the profile’s server. The Mail Transfer Agent (MTA) determines the bounce type and qualifies the error, and sends back that information to Campaign in order to determine whether the email addresses concerned should be quarantined. See Bounce mail qualification.
-
Asynchronous error: a bounce mail or a SR is resent later by the receiving server. This error is qualified with a label related to the error. Asynchronous errors can occur up until one week after a delivery has been sent.
Bounce mail qualification bounce-mail-qualification
The way bounce mail qualification is handled in Adobe Campaign depends on the error type:
-
Synchronous errors: The MTA determines the bounce type and qualification, and sends back that information to Campaign. The bounce qualifications in the Delivery log qualification table are not used for synchronous delivery failure error messages.
-
Asynchronous errors: Rules used by Campaign to qualify asynchronous delivery failures are listed in the Administration > Campaign Management > Non deliverables Management > Delivery log qualification node. Asynchronous bounces are qualified by the inMail process through the Inbound email rules.
Retry management retries
If message delivery fails following a temporary error (Soft or Ignored), Campaign retries sending. These retries can be performed until the end ot the delivery duration.
Soft bounce retries and the length of time between them are determined by the MTA based on the type and severity of the bounce responses coming back from the message’s email domain.
Validity period valid-period
The validity period setting in your Campaign deliveries is limited to 3.5 days or less. For a delivery, if you define a value higher than 3.5 days in Campaign, it will not be taken into account.
For example, if the validity period is set to the default value of 5 days in Campaign, soft-bouncing messages will go into the MTA retry queue and be retried for only up to 3.5 days from when that message reached the MTA. In that case, the value set in Campaign will not be used.
Once a message has been in the MTA queue for 3.5 days and has failed to deliver, it will time out and its status will be updated from Sent to Failed in the delivery logs.
Email error types email-error-types
For the email channel, possible reasons for a delivery failure are listed below.
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 7-row-4 8-row-4 9-row-4 10-row-4 11-row-4 12-row-4 13-row-4 14-row-4 15-row-4 16-row-4 17-row-4 18-row-4 19-row-4 20-row-4 html-authored no-header | |||
|---|---|---|---|
| Error label | Error type | Technical Value | Description |
| Account disabled | Soft / Hard | 4 | The account linked to the address is not active anymore. When the Internet Access Provider (IAP) detects a lengthy period of inactivity, it can close the user's account. Deliveries to the user's address will then be impossible. If the account is temporarily disabled due to six months of inactivity and can still be activated, the status With errors will be assigned and the account will be tried again until the error counter reaches 5. If the error signals that the account is permanently deactivated, it will directly be set to Quarantine. |
| Address in quarantine | Hard | 9 | The address was placed in quarantine. |
| Address not specified | Hard | 7 | No address is given for the recipient. |
| Bad-quality address | Ignored | 14 | The quality rating for this address is too low. |
| Denylisted address | Hard | 8 | The address was added to the denylist at the time of sending. This status is used for importing data from external lists and external systems into the Adobe Campaign Quarantine list. |
| Control address | Ignored | 127 | The recipient's address is part of the control group. |
| Double | Ignored | 10 | The address of the recipient was already in this delivery. |
| Error ignored | Ignored | 25 | The address is on the allowlist. The error is therefore ignored and an email will be sent. |
| Excluded after arbitration | Ignored | 12 | The recipient was excluded by a 'arbitration' type campaign typology rule. |
| Excluded by a SQL rule | Ignored | 11 | The recipient was excluded by a 'SQL' type campaign typology rule. |
| Invalid domain | Soft | 2 | The domain of the email address is incorrect or no longer exists. This profile will be targeted again until the error count reaches 5. After this, the record will be set to Quarantine status and no retry will follow. |
| Mailbox full | Soft | 5 | The mailbox of this user is full and cannot accept more messages. This profile will be targeted again until the error count reaches 5. After this, the record will be set to Quarantine status and no retry will follow. This type of error is managed by a clean-up process, the address is set to a valid status after 30 days. Warning: for the address to be automatically removed from the list of quarantined addresses, the Database cleanup technical workflow must be started. |
| Not connected | Ignored | 6 | The recipient's mobile phone is switched off or not connected to the network when the message is sent. |
| Not defined | Not defined | 0 | The address is in qualification because error has not been incremented yet. This type of error occurs when a new error message is sent by the server: it can be an isolated error, but if it occurs again, the error counter increases, which will alert the technical teams. They can then carry out message analysis and qualify this error, via the Administration / Campaign Management / Non deliverables Management node in the tree structure. |
| Not eligible for the offers | Ignored | 16 | The recipient was not eligible for the offers in the delivery. |
| Refused | Soft / Hard | 20 | The address has been placed in quarantine due to a security feedback as a spam report. According to the error, the address will be tried again until the error counter reaches 5, or it will be directly sent to quarantines. |
| Target limited in size | Ignored | 17 | The maximum delivery size was reached for the recipient. |
| Unqualified address | Ignored | 15 | The postal address has not been qualified. |
| Unreachable | Soft / Hard | 3 | An error has occurred in the message delivery chain. It could be an incident on the SMTP relay, a domain that is temporarily unreachable, etc. According to the error, the address will be tried again until the error counter reaches 5, or it will be directly sent to quarantine. |
| User unknown | Hard | 1 | The address does not exist. No further deliveries will be attempted for this profile. |
Push notifications error types push-error-types
For the mobile app channel, possible reasons for a delivery failure are listed below.
iOS quarantine ios-quarantine
The HTTP/V2 protocol allows a direct feedback and status for each push delivery. If the HTTP/V2 protocol connector is used, the feedback service is no longer called by the mobileAppOptOutMgt workflow. A token is considered unregistered when a mobile application is uninstalled or reinstalled.
Synchronously, if the APNs returns an “unregistered” status for a message, the target token will be immediately be put in quarantine.
| table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 html-authored no-header | |||||
|---|---|---|---|---|---|
| Scenario | Status | Error message | Failure type | Failure reason | Retry |
| Targeted device powered on | OK | ||||
| Targeted device powered off | OK | ||||
| User disables notifications for the application | OK | ||||
| Message creation/analysis phase - payload too big | Failure | Payload too long | Soft | Refused | No |
| Message creation/analysis phase - unexpected content format issue | Failure | Various error messages according to the error | Soft | Undefined | No |
| Certificate issue (password, corruption, etc.) and test connection to APNs issue | Failure | Various error messages according to the error | Soft | Refused | No |
| Network connection lost during sending | Failure | Connection error | Undefined | Unreachable | Yes |
| APNs message rejection: Unregistration the user has removed the application or the token has expired |
Failure | Unregistered | Hard | User unknown | No |
| APNs message rejection: all other errors | Failure | The error rejection cause will be present in the error message | Soft | Refused | No |
Android quarantine android-quarantine
For Android V1
For each notification, Adobe Campaign receives the synchronous errors directly from the FCM server. Adobe Campaign handles them on the fly and generates hard or soft errors according to the severity of the error and retries can be performed:
- Payload length exceeded, connection issue, service availability issue: retry performed, soft error, failure reason is Refused.
- Device quota exceeded: no retry, soft error, failure reason is Refused.
- Invalid or unregistered token, unexpected error, sender account issue: no retry, hard error, failure reason is Refused.
The mobileAppOptOutMgt workflow runs every 6 hours to update the AppSubscriptionRcp table. For the tokens declared unregistered or no longer valid, the field Disabled is set to True and the subscription linked to that device token will be automatically excluded from future deliveries.
During the delivery analysis, all the devices that are excluded from the target are automatically added to the excludeLogAppSubRcp table.
- Connection issue at the beginning of the delivery: failure type Undefined, failure reason Unreachable, retry is performed.
- Connection lost during a delivery: soft error, failure reason Refused, retry is performed.
- Synchronous error returned by Baidu during the sending: hard error, failure reason Refused, no retry is performed.
For Android V2
The Android V2 quarantine mechanism uses the same process as Android V1, the same applies to the subscriptions and exclusions update. For more on this refer to the Android V1 section.
| table 0-row-6 1-row-6 2-row-6 3-row-6 4-row-6 5-row-6 6-row-6 7-row-6 8-row-6 9-row-6 10-row-6 11-row-6 12-row-6 13-row-6 14-row-6 15-row-6 16-row-6 17-row-6 18-row-6 19-row-6 20-row-6 21-row-6 22-row-6 23-row-6 24-row-6 html-authored no-header | |||||
|---|---|---|---|---|---|
| Scenario | Status | Error message | Failure type | Failure reason | Retry |
| Message creation/analysis phase: illegal keywords used in the custom fields | Failure | The following keywords cannot be used: {1} | Soft | No | |
| Message creation/analysis phase: payload too big | Failure | The notification is too heavy: {1} bits, while only {2} are authorized | Soft | Refused | No |
| Network connection lost during sending | Failure | No response from the Firebase Cloud Messaging service on the address: {1} | Soft | Unreachable | Yes |
| FCM message rejection: The FCM server is temporarily unavailable (for example with timeouts). | Failure | The Firebase Cloud Messaging service is temporarily unavailable | Soft | Unreachable | Yes |
| FCM message rejection: Error authenticating the sender account | Failure | Failed to identify the developer account, please check your ID and password | Soft | Refused | No |
| FCM message rejection: Device quota exceeded | Failure | Soft | Refused | Yes | |
| FCM message rejection: Invalid registration / not registered | Failure | Hard | User unknown | No | |
| FCM message rejection: All other error | Failure | The Firebase Cloud Messaging server has returned an unexpected error code: {1} | Refused | No | |
| FCM message rejection: Invalid argument | Failure | INVALID_ARGUMENT | Ignored | Undefined | No |
| FCM message rejection: Third party authentication error | Failure | THIRD_PARTY_AUTH_ERROR | Ignored | Refused | Yes |
| FCM message rejection: Sender ID mismatch | Failure | SENDER_ID_MISMATCH | Soft | User unknown | No |
| FCM message rejection: Unregistered | Failure | UNREGISTERED | Hard | User unknown | No |
| FCM message rejection: Internal | Failure | INTERNAL | Ignored | Refused | Yes |
| FCM message rejection: Unavailable | Failure | UNAVAILABLE | Ignored | Refused | Yes |
| FCM message rejection: unexpected error code | Failure | unexpected error code | Ignored | Refused | No |
| Authentication: Connection issue | Failure | Impossible to connect to authentication server | Ignored | Refused | Yes |
| Authentication: Unauthorized client or scope in request. | Failure | unauthorized_client | Ignored | Refused | No |
| Authentication: Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested. | Failure | unauthorized_client | Ignored | Refused | No |
| Authentication: Access denied | Failure | access_denied | Ignored | Refused | No |
| Authentication: Non-valid email | Failure | invalid_grant | Ignored | Refused | No |
| Authentication: Invalid JWT | Failure | invalid_grant | Ignored | Refused | No |
| Authentication: Invalid JWT Signature | Failure | invalid_grant | Ignored | Refused | No |
| Authentication: Invalid OAuth scope or ID token audience provided | Failure | unauthorized_client | Ignored | Refused | No |
| Authentication: OAuth client disabled | Failure | disabled_client | Ignored | Refused | No |
SMS quarantines sms-quarantines
For standard connectors
The specificities for SMS channel are listed below.
| table 0-row-5 1-row-5 2-row-5 3-row-5 4-row-5 5-row-5 html-authored no-header | ||||
|---|---|---|---|---|
| Scenario | Status | Error message | Failure type | Failure reason |
| Sent to the provider | Sent | |||
| Received on the mobile | Received | |||
| Error returned by the provider | Failure | Error while receiving data (SR or MO) | Soft | Unreachable |
| Invalid MT acknowledge | Failure | Error '{1}' while processing acknowledgment frame for send query | Soft | Unreachable |
| Error while sending the MT | Failure | Error while sending messages | Soft | Unreachable |
For the Extended generic SMPP connector
When using the SMPP protocol to send SMS messages, the error management is handled differently.
The SMPP connector retrieves data from the SR (Status Report) message that is returned using regular expressions (regexes) to filter its content. This data is then matched against the information found in the Delivery log qualification table (available via the Administration > Campaign Management > Non deliverables Management menu).
Before a new type of error is qualified, the failure reason is always set to Refused by default.
Example of a generated message:
SR Generic DELIVRD 000|#MESSAGE#
-
All error messages begin with SR to distinguish SMS error codes from email error codes.
-
The second part (Generic in this example) of the error message refers to the name of the SMSC implementation such as defined in the SMSC implementation name field of the SMS external account.
Because the same error code may have a different meaning for each provider, this field allows you to know which provider generated the error code. You can then find the error in the relevant provider’s documentation.
-
The third part (DELIVRD in this example) of the error message corresponds to the status code retrieved from the SR using the status extraction regex defined in the SMS external account.
This regex is specified in the SMSC specificities tab of the external account.
By default, the regex extracts the stat: field as defined by the Appendix B section of the SMPP 3.4 specification. -
The fourth part (000 in this example) of the error message corresponds to the error code extracted from the SR using the error code extraction regex defined in the SMS external account.
This regex is specified in the SMSC specificities tab of the external account.
By default, the regex extracts the err: field as defined by the Appendix B section of the SMPP 3.4 specification.
-
Everything that comes after the pipe symbol (|) is only displayed in the First text column of the Delivery log qualification table. This content is always replaced by #MESSAGE# after the message is normalized. This process avoids having multiple entries for similar errors and is the same as for emails.
The Extended generic SMPP connector applies a heuristic to find sensible default values: if the status begins with DELIV, it is considered a success because it matches the common statuses DELIVRD or DELIVERED used by most providers. Any other status leads to a hard failure.
Troubleshooting delivery failures troubleshooting
This section provides guidance on diagnosing and resolving common delivery failure issues.
Failed status with personalization errors personalization-errors
If an email delivery’s status is Failed, it can be linked to an issue with personalization blocks. Personalization blocks in a delivery can generate errors when the schemas do not match the delivery mapping.
Delivery logs are key to learn why a delivery failed. Here is a common error you may encounter:
Recipient messages are failing with an “Unreachable” error stating:
Error while compiling script 'content htmlContent' line X: `[table]` is not defined. JavaScript: error while evaluating script 'content htmlContent
Cause: The personalization within the HTML is attempting to call upon a table or field that has not been defined or mapped in the upstream targeting or in the delivery’s target mapping.
Resolution: Review the workflow and delivery content to determine specifically what personalization is attempting to call the table in question. Then either remove the call to this table in the HTML or fix the mapping to the delivery.
Learn more about personalization in this section.
Multiple personalization values error multiple-values-error
When a delivery fails, the following error can appear in the delivery logs:
DLV-XXXX The count of message prepared (123) is greater than the number of messages to send (111). Please contact support.
Cause: There is a personalization field or block within the email that has more than one value for the recipient. A personalization block is being used and it is fetching more than one record for a particular recipient.
Resolution: Check the personalization data used, and then check the target for recipients that have more than one entry for any of those fields. You can also use a Deduplication activity in the targeting workflow prior to the delivery activity to ensure there is only one personalization field at a time. For more information on deduplication, refer to the Workflow documentation.
Auto-reply handling auto-reply-handling
Some deliveries can fail with an “Unreachable” error stating:
Inbound email bounce (rule 'Auto_replies' has matched this bounce).
Explanation: This means that the delivery succeeded but Adobe Campaign received an auto-reply from the recipient (e.g. an “Out of office” reply) that matched the ‘Auto_replies’ inbound email rules.
The auto-reply email is ignored by Adobe Campaign, and the recipient’s address will not be sent to quarantines. This is expected behavior and does not indicate a delivery failure.
Related topics
Delivery statuses explains the different statuses a delivery can have during its lifecycle.
Monitor deliveries in Campaign UI provides guidance on using the delivery dashboard to track delivery performance and diagnose issues.
Quarantine management explains how Campaign manages quarantined addresses to protect your sending reputation.
Monitor your deliverability provides guidance on maintaining good deliverability and sender reputation.
Delivery best practices covers best practices for creating and sending deliveries in Campaign.