Email deliverability: How to optimize bounce management?

Among the most frightening deliverability topics, bounce management could be part of the TOP10 (believe me, I already scared a few people in training or by phone :p).

In addition to being a technical issue, bounce management is often overlooked by advertisers, even though it is of the utmost importance, as it can lead to strong deliverability issues if it's not managed, or even badly managed.

What is a bounce?

A bounce is a legitimate message (normally) sent by a remote server following the non-delivery of an email to its mail server.

To make it simple, a notification will be sent to a sender if he cannot deliver his email to the recipient's email.

Bounces fall into two categories: hard and soft.

The hardbounce

Definition

Logically, in the technical jargon, the hardbounce must be considered as a definitive error, i.e. the error will last in time.

Some examples of hardbounces:

• An e-mail address that does not exist or no longer exists on a domain.
• A field that does not exist or no longer exists.
• A mail server that does not exist or no longer exists.

Management of a hard at a router

On the e-mail router side, only the e-mail address that does not exist or no longer exists is considered a hardbounce, any other definitive error will be tagged as softbounce instead, simply because you are not safe from the fact that a mail server has temporarily gone down and therefore sends back hard bounces.

How to identify a hard?

The RFC 3463 indicates that a code starting with 5.xxx.xxx should indicate a permanent error.

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.

So, in principle, if the network administrator has set up his server correctly, any SMTP code that starts with 5.xxx.xxx should be tagged as hard. Unfortunately, it happens that some softbounces start with 5.

How to manage hardbounces?

Quite simply, the first impact is to permanently remove it from the database and place it in a blacklist specific to this type of bounces. Professional e-mail routers do this automatically.

Risks and impacts

It's important to get your hardbounces out of the way at first impact to :

• Maintain proper database hygiene
• Maintain a good reputation
• Avoid being considered as a spammer (this is a spam technique!)

If you don't manage them (or not correctly), the impact on your reputation will be very strong, which can lead to a temporary blocking or a total blacklisting of all your mailings, all for an indefinite period.

Last but not least, don't forget that a spammer will generate a lot of hardbounces, if you are in this case, your brand could be considered as such!

The softbounce

Definition

A softbounce should be considered a temporary error, i.e. the error should disappear over time.

Some examples of softbounces:

• The full boxes
• A temporary blockage
• A mail server down

Management of a software on a router

On the e-mail router side, the softbounces are categorized in different ways (this changes from one router to another but globally, only the names and the number of categories change, the classification principle remains the same):

• Mailbox Full : for users who have reached their quota of available disk space
• DNS Error : concerns domains that do not respond to the connection request
• Account disabled / Adresses désactivées : concerns addresses disabled by the ISP (last step before the address becomes a hardbounce or a spamtrap).
• Blocks / Anti-Spam Filtering: concerns temporary or permanent blocks (it is possible that a router considers anti-spam filtering outside of a softbounce - and a hardbounce - and considers it as a separate bounce).
• General errors : in principle, this is the catch-all category, when a softbounce is not classified in one of the above categories, it will be placed here until it is qualified by the technical team.

 How to identify a soft ?

The RFC 3463 indicates that a code starting with 4.xxx.xxx should indicate a permanent error.

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.

So, in principle, if the network administrator has set up his server correctly, any SMTP code that starts with 4.xxx.xxx should be tagged as soft.

How to manage softbounces?

Routers, in principle, do not really handle softbounces, which in itself could not be a problem since they are only temporary errors. But, some softbounces can generate blockages if they become too recurrent and/or too frequent.

Ideally, depending on the category of the softbounce, it would be appropriate to apply management rules, i.e. to discard them after X failures (it's up to you how you want to manage them) and to place them in a specific blacklist (outside your hardbounces/complaints).

Risks and impacts

As I mentioned in the previous point, it is important to apply business rules for some of your softbounces, for several reasons:

• Maintain database hygiene
• Maintain a good reputation
• Avoid being considered as a spammer (because you will generate a lot of errors on the remote server)

If you don't manage them (or not correctly), the impact on your reputation can be strong, which can lead to a temporary (or even permanent) blocking or spamming.

What mechanisms to put in place

First of all, you should not forget that your bounces degrade your deliverability rate and your reputation. Therefore, it is important for you to manage them well by setting up different mechanisms:

Mechanics at the collection level

Collect in double-optinThis will allow you to properly qualify an address before injecting it into your mass e-mails. As a bonus, you will collect the person's consent and you will also make sure that it is really him who has registered to your program (and not a robot or a malicious person).

Mechanics at the level of your database

Workflow of softbounces managementThe principle is to set up automations within your database in order to remove softbounces after a certain number of errors in order to improve hygiene. In the end, your reputation will only be better.

Workflow for managing hardbounces (if you are not using a professional router): rule out hard errors at first impact.

Conclusion:

Managing bounces is not an insurmountable task, but it requires time (cf. monitoring), a good understanding of the error codes that come up and the implementation of a (well-oiled) mechanism to manage them.

If you have any doubts, or if you'd like to set up such a system, don't hesitate to contact us 😉