v7 v8

Understand quarantine management

Adobe Campaign manages a list of quarantined addresses. Recipients whose address is quarantined are excluded by default during delivery analysis, and will not be targeted. An email address can be quarantined, for example, when the mailbox is full or if the address does not exist. In any case, the quarantine procedure complies with specific rules described below.

Optimize your delivery through quarantine management

The profiles whose email addresses or phone number are in quarantine are automatically excluded during message preparation (see Identify quarantined addresses for a delivery). This will speed up deliveries, as the error rate has a significant effect on delivery speed.

Some internet access providers automatically consider emails to be spam if the rate of invalid addresses is too high. Quarantine therefore allows you to avoid being added to denylist by these providers.

Moreover, quarantines help reducing SMS sending costs by excluding erroneous phone numbers from deliveries.

For more on best practices to secure and optimize your deliveries, refer to this page.

Quarantine vs denylist

Quarantine and denylist do not apply to the same object:

• Quarantine applies only to an address (or phone number, etc.), not to the profile itself. For example, a profile whose email address is quarantined can update their profile and enter a new address, and could then be targeted by delivery actions again. Likewise, if two profiles happen to have the same phone number, they will both be affected if the number is quarantined.

  The quarantined addresses or phone numbers are displayed in the exclusion logs (for a delivery) or in the quarantine list (for the entire platform).

• Being on the denylist, on the other hand, will result in the profile no longer being targeted by the delivery, such as after an unsubscription (opt-out), for a given channel. For example, if a profile on the denylist for the email channel has two email addresses, both addresses will be excluded from delivery.

  You can check if a profile is on the denylist for one or more channels in the No longer contact section of the profile’s General tab. See this section.

Identify quarantined addresses

Quarantined addresses can be listed for a specific delivery or for the entire platform.

Identify quarantined addresses for a delivery

Quarantined addresses for a specific delivery are listed during the delivery preparation phase, in the delivery logs of the delivery dashboard (see Delivery logs and history).

Identify quarantined addresses for the entire platform

Administrators can list the addresses in quarantine for the entire platform from the Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses node.

The following information is available for each address:

Identify quarantined addresses in delivery reports

The following reports provide information about the addresses in quarantine:

• For each delivery, the Delivery summary report shows the number of addresses in quarantine in the delivery target. It displays:

  • The number of addresses placed in quarantine during the delivery analysis,

  • The number of addresses placed in quarantine following the delivery action.

• The Non-deliverables and bounces report displays information about the addresses in quarantine, the types of error encountered, etc., and a failure breakdown by domain.

You can look up this information for all deliveries of the platform (Home page > Reports) or for a specific delivery. You can also create customized reports and select the information to be displayed.

Identify quarantined addresses for a recipient

You can look up the status of the email address of any recipient. To do this, select the recipient profile and click the Deliveries tab. For all deliveries to that recipient, you can find out whether the address failed, was quarantined during analysis, etc. For each folder, you can display only the recipients whose email address is in quarantine. To do this, use the Quarantined email address application filter.

Conditions for sending an address to quarantine

Adobe Campaign manages quarantine according to the delivery failure type and the reason assigned during error messages qualification (see Bounce mail qualification and Delivery failure types and reasons).

• Ignored error: ignored errors do not send an address to quarantine.
• Hard error: the corresponding email address is immediately sent to quarantine.
• Soft error: soft errors do not send immediately an address to quarantine, but they increment an error counter. For more on this, see Soft error management.

If a user qualifies an email as a spam (feedback loop), the message is automatically redirected towards a technical mailbox managed by Adobe. The user’s email address is then automatically sent to quarantine with the Denylisted status. This status refers to the address only, the profile is not on the denylist, so that the user continues receiving SMS messages and push notifications.

In the list of quarantined addresses (see see Identifying quarantined addresses for the entire platform), the Error reason field indicates why the selected address was placed in quarantine.

Soft error management

As opposed to hard errors, soft errors do not send immediately an address to quarantine, but instead they increment an error counter.

Retries will be performed during the delivery duration. When the error counter reaches the limit threshold, the address goes into quarantine. For more on this, refer to Retries after a delivery temporary failure.

The error counter is reinitialized if the last significant error occurred more than 10 days ago. The address status then changes to Valid and it is deleted from the list of quarantines by the Database cleanup workflow.

For hosted or hybrid installations, if you have upgraded to the Enhanced MTA, the maximum number of retries to be performed in case of Erroneous status and the minimum delay between retries are now based on how well an IP is performing both historically and currently at a given domain.

For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA, you can modify the number of errors and the period between two errors. To do this, change the corresponding settings in the deployment wizard (Email channel > Advanced parameters) or at the delivery level.

Remove an address from quarantine

Automatic updates

Addresses that match specific conditions are automatically deleted from the quarantine list by the Database cleanup workflow.

The addresses are automatically removed from the quarantine list in the following cases:

• Addresses in a With errors status will be removed from the quarantine list after a successful delivery.
• Addresses in a With errors status will be removed from the quarantine list if the last soft bounce occurred more than 10 days ago. For more on soft error management, see this section.
• Addresses in a With errors status that bounced with the Mailbox full error will be removed from the quarantine list after 30 days.

Their status then changes to Valid.

Manual updates

You can also un-quarantine an address manually. To manually remove an address from the quarantine list, change its status to Valid from the Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses node.

Bulk updates

You might need to perform bulk updates on the quarantine list, for example in case of an ISP outage. In such case, emails are wrongly marked as bounces because they cannot be successfully delivered to their recipient. These addresses must be removed from the quarantine list.

To perform this, create a workflow and add a Query activity on your quarantine table to filter out all impacted recipients. Once identified, they can be removed from the quarantine list, and included in future Campaign email deliveries.

Below are the recommended guidelines for this query:

• For Campaign Classic v7 environments with Inbound Email rule information in the Error text field of the quarantine list:

  • Error text (quarantine text) contains “Momen_Code10_InvalidRecipient”
  • Email domain (@domain) equal to domain1.com OR Email domain (@domain) equal to domain2.com OR Email domain (@domain) equal to domain3.com
  • Update status (@lastModified) on or after MM/DD/YYYY HH:MM:SS AM
  • Update status (@lastModified) on or before MM/DD/YYYY HH:MM:SS PM

• For Campaign Classic v7 instances with SMTP bounce response information in the Error text field of the quarantine list:

  • Error text (quarantine text) contains “550-5.1.1” AND Error text (quarantine text) contains “support.ISP.com”

  where “support.ISP.com” can be: “support.apple.com” or “support.google.com” for example

  • Update status (@lastModified) on or after MM/DD/YYYY HH:MM:SS AM
  • Update status (@lastModified) on or before MM/DD/YYYY HH:MM:SS PM

Once you have the list of affected recipients, add an Update data activity to set their email address status to Valid so they will be removed from the quarantine list by the Database cleanup workflow. You can also just delete them from the quarantine table.

Push notification quarantines

The quarantine mechanism for push notifications is globally the same as the general process. However certain errors are managed differently for push notifications. For example, for certain soft errors, no retries are performed within the same delivery. The specificities for push notification are listed below. The retry mechanism (number of retries, frequency) is the same as for emails.

The items put in quarantine are device tokens.

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 quarantine mechanism for SMS messages is globally the same as the general process. See About quarantines. The specificities for SMS are listed below.

For the Extended generic SMPP connector

When using the SMPP protocol to send SMS messages, the error management is handled differently. For more information on the Extended generic SMPP connector, refer to this page.

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. See this page.

  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. See this page.

  

  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. See this page.

  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. For more on this, see Bounce mail qualification.

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.