how to handle bounced emails

Bounced emails or simply “bounces” are the emails sent automatically
by an MTA (Mail Transfer Agent) to the sender,
to inform that the message was NOT received correctly by the recipient

The subject is usually “Returned mail: see transcript for details”.
The explanatory bounce information, a code with a description, can be found in the content.

The “status-code” should clearly identify the type of error that caused the return
but often the codes and descriptions used by each email service provider
must be analyzed and interpreted to classify the bounce correctly.


What are the risks with bounced emails?

Mailing to wrong/inactive recipients is considered a “spammer behaviour”.

» back to top


Check the number of bounces

Sometimes a configuration error on both the sender’s side and the recipient’s side
can cause a soft bounce or even a hard bounce.

A good habit is to check the number of bounced messages in the last week
to see if the values are the same as before or if there are any anomalies.
If there is something wrong, you will notice immediately. Reading the details of the bounces will help you find the cause.

Some systems allow you to define the number of days (eg 180)
after which a subscriber’s bounce information is discarded.
In this way the smtp server will try to contact that recipient again.

Blocks activated by mistake will be cleared automatically
but the reputation of the smtp server can suffer.

» back to top


In one sentence: prevention is better than cure.

email sending process

To avoid damage to the reputation of their SMTP servers,
more and more ESPs (Email Service Providers) use an “email suppression list
that acts before the messages reach the recipient’s mailbox.

When any customer sends an email that results in a hard bounce,
the email address that produced the bounce is added to the suppression list.

The suppression list applies to all the customers. In other words,
if a different customer attempts to send an email to an address that’s on the suppression list,
the SMTP server won’t send it out, because the email address is suppressed.

Using smtp servers with dedicated IP can avoid some issues related to reputation sharing.
For example, the “email suppression list” can only be limited to your IP address,
so that if another customer causes a blacklisting of the smtp server and the related bounces,
your mailings will not be affected.

» back to top


Bounced messages status codes

Status codes used to identify hard bounces and soft bounces have the following syntax:
status-code = class “.” subject “.” detail

Status codes consist of three numeric fields separated by “.”
- the first sub-code (class) indicates whether the distribution attempt was successful
- the second sub-code (subject) indicates the probable source of any delivery anomaly
- the third sub-code (detail) indicates a specific error condition

The sub-code (class) provides a general classification of the status.
The values ​​listed for each class are defined as follows in the RFC 3463 and the RFC 6522:

2.XXX.XXX Success (NOT sent unless requested by the sender)
Success specifies that the DSN is reporting a positive delivery action. 
Detail sub-codes may provide notification of transformations required for delivery.

4.XXX.XXX Persistent Transient Failure
A persistent transient failure is one in which the message as sent is valid, 
but persistence of some temporary condition has caused abandonment or delay of attempts to send the message. 
If this code accompanies a delivery failure report, sending in the future may be successful.

5.XXX.XXX Permanent Failure
A permanent failure is one which is not likely to be resolved by resending the message in the current form. 
Some change to the message or the destination must be made for successful delivery.

Some code and description examples:

2.0.0: Sent (Message accepted for delivery)

4.2.2: Over quota
4.4.5: Insufficient disk space

5.0.0: Invalid domain name
5.1.1: User unknown
5.7.1: Message content rejected

» back to top