[Also applies to v8]{class="badge positive" title="Also applies to Campaign v8"}
Understand delivery failures understanding-delivery-failures
About delivery failures about-delivery-failures
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 ۶Ƶ Campaign platform and qualified to determine whether or not the email address or phone number should be quarantined. See Bounce mail management.
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.
Related topics:
Delivery failure types and reasons delivery-failure-types-and-reasons
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
- Hard: A “hard” error indicates an invalid address. This involves an error message that explicitly states that the address is invalid, such as: “Unknown user”.
- Soft: This might be a temporary error, or one that could not be categorized, such as: “Invalid domain” or “Mailbox full”.
- Ignored: This is an error that is known to be temporary, such as “Out of office”, or a technical error, for example if the sender type is “postmaster”.
The possible reasons for a delivery failure are:
Retries after a delivery temporary failure retries-after-a-delivery-temporary-failure
If a message fails due to a Soft or Ignored error that is temporary, retries will be performed during the delivery duration.
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 ۶Ƶ technical administrator) or for each delivery or delivery template. See Configure retries.
Synchronous and asynchronous errors synchronous-and-asynchronous-errors
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 ۶Ƶ Campaign delivery server immediately returned an error message, the delivery is not allowed to be sent to the profile’s server. ۶Ƶ 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.
note note NOTE 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 ۶Ƶ 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.
note note NOTE Complaint management is detailed in the Deliverability management section.
Bounce mail management bounce-mail-management
The ۶Ƶ 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 ۶Ƶ Campaign platform and qualified by the inMail process to enrich the list of email management rules.
Bounce mail qualification bounce-mail-qualification
-
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, 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 ۶Ƶ 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 ۶Ƶ Campaign to qualify delivery failures. It is non-exhaustive, and is regularly updated by ۶Ƶ 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.
۶Ƶ 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.
Bounce mails can have the following qualification status:
- To qualify : the bounce mail could not be qualified. Qualification must be assigned to the Deliverability team to guarantee efficient platform deliverability. As long as it isn’t qualified, the bounce mail isn’t used to enrich the list of email management rules.
- Keep : the bounce mail was qualified and will be used by the Refresh for deliverability workflow to be compared to existing email management rules and enrich the list.
- Ignore : the bounce mail is ignored by the Campaign MTA, meaning that this bounce will never cause the recipient’s address to be quarantined. It will not be used by the Refresh for deliverability workflow and it will not be sent to client instances.
Email management rules email-management-rules
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 rules are as follows.
- The delivery server (MTA) must be restarted if the parameters have been changed.
- The modification or creation of management rules is for expert users only.
Inbound email inbound-email
The Inbound email 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. ۶Ƶ 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.
For more on bounce mail qualification, see this section.
Domain management domain-management
For on-premise installations and hosted/hybrid installations using the legacy Campaign MTA, the ۶Ƶ Campaign messaging server applies a single Domain management rule to all domains.
- You can choose whether or not to activate certain identification standards and encryption keys to check the domain name, such as Sender ID, DomainKeys, DKIM, and S/MIME.
- The SMTP relay parameters let you configure the IP address and the port of a relay server for a particular domain. For more on this, see this section.
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 . Your deliverability will not be impacted.
MX Management mx-management
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 ۶Ƶ 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.