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

  • you cannot ignore them

If you want to reach the rest of your list, it’s best to stop sending to the “bad” part of it.
Sometimes this is called “list hygiene”.

  • you should understand their meaning

There are three types of Delivery Status Notification (DSN): Success - The email has been delivered (notification is sent only if requested by the sender)
Hard Bounce - A permanent error has occurred
Soft Bounce - A temporary error has occurred

hard bounce (status-code 5.XXX.XXX): the email address generated a permanent error
such as “550 5.1.1 … User unknown” or “5.1.2 … Host unknown”
A permanent error indicates that you should never send to that recipient again.
A single bounced message should trigger email address blocking.

soft bounce (status-code 4.XXX.XXX): the email address generated a temporary error
such as “452 4.2.2 … Mailbox full”
A transient error indicates that you can retry delivery in the future.
At least three bounced messages, within a few days of each other, should trigger email address blocking.

  • you should know how bounce handling works (and how to tweak it)
  • all returned messages are downloaded by an application
    they’re made available for human review, either through the app interface or through a JSON file hard bounce
  • the Classification follows some rules, which can be edited hard bounce categories
  • the Options define when soft bounces will be “upgraded” to to hard bounces level bounces options

» 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