Understand 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

There are two types of error when a message fails. Each error type determines if an address is sent to quarantines 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, 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”.

Bounce mail qualification

Rules used by Campaign to qualify delivery failures are listed in the Administration > Campaign Management > Non deliverables Management > Delivery log qualification node. It is non-exhaustive, and is regularly updated by Adobe Campaign and can also be managed by the user.

The bounce qualifications in the Delivery log qualification table are not used for synchronous delivery failure error messages. Momentum determines the bounce type and qualification, and sends back that information to Campaign.

Asynchronous bounces are qualified by the inMail process through the Inbound email rules.

The message returned by the remote server on the first occurrence of this error type is displayed in the First text column of the Audit tab.

Adobe Campaign filters this message to delete the variable content (such as IDs, dates, email addresses, phone numbers, etc.) and displays the filtered result in the Text column. The variables are replaced with #xxx#, except addresses that are replaced with *.

This process allows to bring together all failures of the same type and avoid multiple entries for similar errors in the Delivery log qualification table.

NOTE

The Number of occurrences field displays the number of occurrences of the message in the list. It is limited to 100 000 occurrences. You can edit the field, if you want, for example, to reset it.

Bounce mails can have the following qualification status:

  • To qualify : the bounce mail could not be qualified. Qualification must be assigned to the Deliverability team to guarantee efficient platform deliverability. As long as it is not qualified, the bounce mail is not used to enrich the list of email management rules.
  • Keep : the bounce mail was qualified and will be used by the Refresh for deliverability workflow to be compared to existing email management rules and enrich the list.
  • Ignore : the bounce mail is ignored, meaning that this bounce will never cause the recipient’s address to be quarantined. It will not be used by the Refresh for deliverability workflow and it will not be sent to client instances.

NOTE

In case of an outage of an ISP, emails sent through Campaign will be wrongly marked as bounces. To correct this, you need to update bounce qualification.

Retry management

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. The number and frequency of retries are set up by Momentum, based on the type and severity of the bounce responses coming back from the message’s ISP.

The default configuration defines five retries at one-hour intervals, followed by one retry per day for four days. The number of retries can be changed globally or for each delivery or delivery template. If you need to adapt delivery duration and retries, contact Adobe Support.

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. Adobe Campaign qualifies each error 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 Services user, configuration of the bounce mailbox is performed by Adobe.

    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 on denylist even though they did not click the unsubscription link. Addresses are in denylist in the (NmsAddress) quarantine table and not in the (NmsRecipient) recipient table. Learn more about feedback loop mechanism in Adobe Deliverability Best Practices Guide.

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

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

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

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

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.

On this page