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

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

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

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

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

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

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.

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.

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

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#

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

Business.Adobe.com resources