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.

NOTE
As a Managed Cloud Services user, configuration of the bounce mailbox is performed by Adobe.

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. For more on this, refer to Adobe Campaign Classic v7 documentation.

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.

NOTE
The retry settings in the delivery properties are not used by Campaign.

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

For more on the validity period, see the Adobe Campaign Classic v7 documentation.

Email error types email-error-types

For the email channel, possible reasons for a delivery failure are listed below.

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

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.

NOTE
For customers using the Baidu connector, here are the different types of errors:
  • 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.
Adobe Campaign contacts the Baidu server every 10 minutes to retrieve the sent message’s status, and updates the broadlogs. If a message is declared as sent, the status of the message in the broadlogs is set to Received. If Baidu declares an error, the status is set to Failed.

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.

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.

NOTE
The Delivery log qualification table does not apply to the Extended generic SMPP connector.
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.

NOTE
The failure types and reasons for failure are the same as for emails.
Ask your provider for a list of status and error codes in order to set proper failure types and reasons for failure in the Delivery log qualification table.

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.

recommendation-more-help
35662671-8e3d-4f04-a092-029a056c566b