In shown results, Dialog Insight divides delivery errors in 2 big categories:

  • Delivery errors (bounces)
  • After-delivery errors

In both cases, it concerns messages that have NOT reached the recipient. The actual number of errors is therefore the total of those 2 categories of errors. The difference between the two types is based on how and when the error was detected.

To better understand, here is a brief description of the delivery process.


Initial delivery of the message

When sending a message, Dialog Insight communicates with the server associated with the domain name of the recipient's address and tries to deliver the message to that server, who normal replies immediately:

  • If the email address is valid and available, the message is accepted and Dialog Insight considers the message as delivered.
  • If the message is not accepted (for various reasons explained below), Dialog Insight considers the message to be in error.

So, when a message is processed, 100% of sent messages are either delivered or have bounced.


Messages sent back to the sender

Sometimes, servers that have accepted a message, and therefore have taken the responsibility of its delivery to the recipient, end up not being able to deliver the message. This can happen, for example, when a message needs to be delivered to another server before reaching the recipient and this delivery did not succeed. In such cases, the server that had initially accepted the message will send an error message to Dialog Insight saying that the message could not be delivered.

It is important to take into consideration that the time elapsed between the initial delivery of the message and the return of this message is unpredictable and probably quite long (up to a few days in general) since the intermediate server will probably have tried to deliver the message over a few days before finally return it to Dialog Insight' s servers.


Accuracy of the results

When a message goes through an additional server and ends up not being delivered, we want to inform you of that error. However, since this message was already considered delivered (to the first server), the success of the delivery is already registered in the system and part of statistics and contact histories. To keep results from fluctuating over time (the number of delivered messages lowering with time) and to make sure that the total of messages that were delivered and who bounced do not exceed 100%, we calculate errors from messages returned to the sender separately.

To sum it up:

  • Delivered messages+ bounces = Total number of sent messages
  • After-delivery errors = Part of the delivered messages that were sent back after delivery to the first server.

The difference between soft and hard bounces

The difference between soft and hard bounces has no significant impact on error management. The major distinction is for internal purposes and relies in the SMTP protocol (which rules errors) that indicates the destination server is the error is temporary (soft) or permanent (hard).

If the error is temporary (soft), this means that the server trying to deliver the message will perform further attempts (usually a few minutes or hours later) and will probably succeed.

If the error is permanent (hard), this means that the server does not accept the message and that the sender should not try again.

It is important to understand that a permanent error (hard bounce) does not necessarily mean that the email address is not valid. It is simply an error message that indicates that this particular message is not accepted. The reasons for this reject could be, for example:

  • The message has exceeded the maximum size accepted by the server.
  • The mailbox of the recipient is full.
  • The message contains content not authorized by the server's anti-spam filter.

Dialog Insight manages these two types of errors as follows:

  • Permanent errors are immediately logged as delivery errors (bounces).
  • Temporary errors cause the message to be placed in queue so that delivery will be attempted again later.
  • If the message cannot be delivered within reasonable time (usually about within 4 days), it will be in error.

From the sender's point of view, whether the error is soft or had does not really matter; what matters the most is whether the email address is valid, because an invalid address causes the contact to be placed in quarantine.


Quarantine

Quarantine is a temporary status given to a contact that prevents messages to be sent to him/her, without however deactivating or unsubscribing the contact permanently. The contact's preferences and subscriptions remain valid, and correcting the email address, either by import, change request or directly in the contact's profile, will lift the quarantine to make the contact eligible again to receive messages.


Invalid email related quarantine

A contact is placed in quarantine when it can be establish with certainty that the email address is not valid, based on the delivery result received from the server related to the domain name of the address. This certainty is achieved by analyzing thoroughly thousands of replies from various email providers and based on specific rules regulating all major providers in the world.

This system automatically eliminates future messages to be sent to invalid addresses in 99% of the cases.

It is almost impossible to provide an exact list of the many causes of quarantine as there are literally HUNDREDS of different rules in place, which are in turn based on as many conditions and replies, and all this for each provider! Furthermore, these rules and conditions vary over time as provides can decide any time to add or edit any of these rules.


Delivery error related quarantine

This type of quarantine, which is enabled and configured in the Contact application, prevents messages to be sent to contacts who register too many delivery errors over a given period of time.

For more information, see what is the quarantine process and how to configure quarantine option on delivery errors.