When a message (email, SMS, push notification) cannot be sent to a profile, the remote server automatically sends an error message, which is picked up by the Adobe Campaign platform and qualified to determine whether or not the email address or phone number should be quarantined. See Bounce mail management.
Email error messages (or “bounces”) are qualified by the Enhanced MTA (synchronous bounces) or by the inMail process (asynchronous bounces).
SMS error messages (or “SR” for “Status Report”) are qualified by the MTA process.
Once a message is sent, the delivery logs allows you to view the delivery status for each profile and the associated failure type and reason.
Messages can also be excluded during the delivery preparation if an address is quarantined or if a profile is on denylist. Excluded messages are listed in the delivery dashboard.
There are three types of error when a message fails. Each error type determines if an address is sent to quarantines. For more on this, refer to Conditions for sending an address to quarantine
The possible reasons for a delivery failure are:
|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: in order 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 have 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.
If a message fails due to a Soft or Ignored error that is temporary, retries will be performed during the delivery duration.
Temporarily undelivered messages can only be related to a Soft or Ignored error, but not a Hard error (see Delivery failure types and reasons).
For hosted or hybrid installations, if you have upgraded to the Enhanced MTA, the retry settings in the delivery are no longer used by Campaign. Soft bounce retries and the length of time between them are determined by the Enhanced MTA based on the type and severity of the bounce responses coming back from the message’s email domain.
For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA, to modify the duration of a delivery, go to the advanced parameters of the delivery or delivery template and specify the desired duration in the corresponding field. See Defining validity period.
The default configuration allows five retries at one-hour intervals, followed by one retry per day for four days. The number of retries can be changed globally (contact your Adobe technical administrator) or for each delivery or delivery template. See Configure retries.
A message can fail immediately (synchronous error), or later on, after it has been sent (asynchronous error).
Synchronous error: the remote mail server contacted by the Adobe Campaign delivery server immediately returned 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 or not the email addresses concerned should be quarantined. See Bounce mail qualification.
Asynchronous error: a bounce mail or a SR was resent later by the receiving server. This mail is loaded into a technical mailbox the application uses to label messages with an error. Asynchronous errors can occur up until one week after a delivery has been sent.
Configuration of the bounce mailbox is detailed in this section.
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. Messages sent to users who have qualified an email as spam are automatically redirected towards an email box specifically created for this purpose. The addresses of these users are on denylist even though they didn’t click the unsubscription link. Addresses are in denylist in the (NmsAddress) quarantine table and not in the (NmsRecipient) recipient table.
Complaint management is detailed in the Deliverability management section.
The Adobe Campaign platform lets you manage email delivery failures via the bounce mail functionality.
When an email cannot be delivered to a recipient, the remote messaging server automatically returns an error message (bounce mail) to a technical inbox designed for this purpose.
For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA, error messages are collected by the Adobe Campaign platform and qualified by the inMail process to enrich the list of email management rules.
For hosted or hybrid installations, if you have upgraded to the Enhanced MTA, most of the email management rules are no longer used. For more on this, see this section.
For hosted or hybrid installations, if you have upgraded to the Enhanced MTA:
The bounce qualifications in the Delivery log qualification table are no longer used for synchronous delivery failure error messages. The Enhanced MTA determines the bounce type and qualification, and sends back that information to Campaign.
Asynchronous bounces are still qualified by the inMail process through the Inbound email rules. For more on this, see Email management rules.
For instances using the Enhanced MTA without Webhooks/EFS, the Inbound email rules will also be used to process the synchronous bounce emails coming from the Enhanced MTA, using the same email address as for asynchronous bounce emails.
For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA, when the delivery of an email fails, the Adobe Campaign delivery server receives an error message from the messaging server or the remote DNS server. The list of errors is made up of strings contained in the message returned by the remote server. Failure types and reasons are assigned to each error message.
This list is available via the Administration > Campaign Management > Non deliverables Management > Delivery log qualification node. It contains all the rules used by Adobe Campaign to qualify delivery failures. It is non-exhaustive, and is regularly updated by Adobe Campaign and can also be managed by the user.
The message returned by the remote server on the first occurrence of this error type is displayed in the First text column of the Delivery log qualification table. If this column is not displayed, click the Configure list button at the right bottom of the list to select it.
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.
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:
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. For more on this, see this page.
For hosted or hybrid installations, if you have upgraded to the Enhanced MTA, most of the email management rules are no longer used. For more details, see the sections below.
Mail rules are accessed via the Administration > Campaign Management > Non deliverables Management > Mail rule sets node. Email management rules are shown in the lower part of the window.
The default parameters of the platform are configured in the deployment wizard. For further information, refer to this section.
The default rules are as follows.
For hosted or hybrid installations, if you have upgraded to the Enhanced MTA, and if your instance has Webhooks/EFS functionality, the Inbound email rules are no longer used for synchronous delivery failure error messages. For more on this, see this section.
For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA, these rules contain the list of character strings which can be returned by remote servers and which let you qualify the error (Hard, Soft or Ignored).
When an email fails, the remote server returns a bounce message to the address specified in the platform parameters. Adobe Campaign compares the content of each bounce mail to the strings in the list of rules, and then assigns it one of the three error types.
The user can create their own rules. When importing a package and when updating data via the Refresh for deliverability workflow, the user-created rules are overwritten.
For more on bounce mail qualification, see this section.
For hosted or hybrid installations, if you have upgraded to the Enhanced MTA, the Domain management rules are no longer used. DKIM (DomainKeys Identified Mail) email authentication signing is done by the Enhanced MTA for all messages with all domains. It does not sign with Sender ID, DomainKeys, or S/MIME unless otherwise specified at the Enhanced MTA level.
For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA, the Adobe Campaign messaging server applies a single Domain management rule to all domains.
If your messages are displayed in Outlook with on behalf of in the sender address, make sure you are not signing your emails with Sender ID, which is the outdated proprietary email authentication standard from Microsoft. If the Sender ID option is enabled, uncheck the corresponding box and contact Adobe Customer Care. Your deliverability will not be impacted.
For hosted or hybrid installations, if you have upgraded to the Enhanced MTA, the MX management delivery throughput rules are no longer used. The Enhanced MTA uses its own MX rules that allow it to customize your throughput by domain based on your own historical email reputation, and on the real-time feedback coming from the domains where you’re sending emails.
For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA:
The MX management rules are used to regulate the flow of outgoing emails for a specific domain. They sample the bounce messages and block sending where appropriate.
The Adobe Campaign messaging server applies rules specific to the domains, and then the rules for the general case represented by an asterisk in the list of rules.
To configure MX management rules, simply set a threshold and select certain SMTP parameters. A threshold is a limit calculated as an error percentage beyond which all messages towards a specific domain are blocked. For example, in the general case, for a minimum of 300 messages, the sending of emails is blocked for three hours if the error rate reaches 90%.
For more on MX management, refer to this section.