Show Menu
TOPICS×

Understanding quarantine management

About quarantines

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.
This section applies to online channels: email, SMS, push notification.

Optimizing your delivery through quarantines

The profiles whose email addresses or phone number are in quarantine are automatically excluded during message preparation (see Identifying 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 blacklisting 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 blacklisting

Quarantine applies only to an address, not the profile itself. It means that, if two profiles have the same email address, they will both be affected if the address is quarantined.
Likewise, a profile whose email address is quarantined could update his profile and enter a new address, and could then be targeted by delivery actions again.
Blacklisting , on the other hand, will result in the profile no longer being targeted by any delivery, for example after an unsubscription (opt-out).
When a user replies to an SMS message with a keyword such as "STOP" in order to opt-out from SMS deliveries, his profile is not blacklisted like in the email opt-out process. The profile phone number is sent to quarantine, so that the user continues receiving email messages.

Identifying quarantined addresses

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

Identifying 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 ).

Identifying 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.
This menu lists quarantined elements for email , SMS and Push notification channels.
The following information is available for each address:
The increase in number of quarantines is a normal effect, related to the "wear" of the database. For example, if the lifetime of an email address is considered to be three years and the recipients table increases by 50% each year, the increase in quarantines can be calculated as follows:
End of Year 1: (1*0.33)/(1+0.5)=22%.
End of Year 2: ((1.22*0.33)+0.33)/(1.5+0.75)=32.5%.

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

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

Removing a quarantined address

If you need to remove an address from quarantine, change its status manually to Valid .
If you change the status to Whitelisted , the address will be targeted systematically each time even if an error is encountered.
Blacklisted addresses are not concerned by the quarantine system and are not targeted, even if you change the status of the address.
You can also change the number of errors and the period between errors. To do this, change the settings of the deployment wizard (Email channel/Advanced settings). For more on the deployment wizard, refer to this section .

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. When the error counter reaches the limit threshold, the address goes into quarantine. In the default configuration, the threshold is set at five errors, where two errors are significant if they occur at least 24 hours apart. The address is placed in quarantine at the sixth error. The error counter threshold can be modified. For more on this, refer to Retries after a delivery temporary failure .
    When a delivery is successful after a retry, the error counter of the address which was prior to that quarantined is reinitialized. The address status changes to Valid and it is deleted from the list of quarantines after two days by the Database cleanup workflow.
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.
In the list of quarantined addresses, the Error reason field indicates why the selected address was placed in quarantine. Quarantine in Adobe Campaign is case sensitive. Make sure to import email addresses in lower case, so that they are not retargeted later on.

Push notification quarantines

The quarantine mechanism for push notifications is globally the same as the general process. See About quarantines . 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

For iOS - binary connector
For each notification, Adobe Campaign receives the synchronous and asynchronous errors from the APNS server. For the following synchronous errors, Adobe Campaign generates soft errors:
  • Payload length issues: no retry, the failure reason is Unreachable .
  • Certificate expiration issues: no retry, the failure reason is Unreachable .
  • Connection lost during the delivery: retry performed, the failure reason is Unreachable .
  • Service configuration issue (invalid certificate, invalid certificate password, no certificate): no retry, the failure reason is Unreachable .
The APNS server asynchronously notifies Adobe Campaign that a device token has been unregistered (when the mobile application has been uninstalled by the user). The mobileAppOptOutMgt workflow runs every 6 hours to contact the APNS feedback services to update the AppSubscriptionRcp table. For all the deactivated tokens, the field Disabled is set to True and the subscription linked to that device token will be automatically excluded from future deliveries.
For iOS - HTTP/2 connector
The http/2 protocol allows a direct feedback and status for each push delivery. If the http/2 protocol connector is used, the feedback service is no longer called by the mobileAppOptOutMgt workflow. The unregistered tokens are handled differently between the iOS binary connector and the iOS http/2 connector. 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.
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
Android V2 quarantine mecanism uses the same process as Android V1, the same applies for 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

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.
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. 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.
The failure types and reasons for failure are the same as for emails. See Delivery failure types and reasons .
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. 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.