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.

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:

Bounce mail qualification bounce-mail-qualification

The way bounce mail qualification is handled in Adobe Campaign depends on the error type:

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.

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.

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.

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:

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.

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.

SMS quarantines sms-quarantines

For standard connectors

The specificities for SMS channel are listed below.

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#

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.