It's Time to Think About Bounces Differently


Today's guest post comes from Sebastian Kluth of the Certified Senders Alliance. This is cross-posted from Linkedin, with his permission. Thanks, Sebastian, for helping encourage us to start thinking about the possibilities for the future evolution of bounces! (And click here to learn more about the Certified Senders Alliance.)

Bounces are a primary KPI and measurement unit in email marketing and email deliverability. A bounce provides delivery status notifications (DSNs – see RFC 3463).

Basically, when we talk about bounces, we are thinking of the following standard definitions:

  1. Hard Bounce: a permanent delivery failure due to an invalid email address or non-existing domain name.
  2. Soft Bounce: a temporary delivery failure due to a full inbox, server downtime, or the message size exceeding limits.

Very straightforward, very top level and very technical. The idea behind sending bounces was to inform the sending MTA about the delivery status to the recipient MTA via SMTP. SMTP status codes were introduced to standardise and differentiate this bounce-back communication.

The SMTP status codes are numerical codes used by email servers to indicate the result of email delivery transmission. The codes are organised into classes representing a specific type of delivery status. For example, a 2xx class code indicates successful delivery, while a 4xx class code indicates a temporary delivery failure, and a 5xx class code reports a permanent delivery failure.

With all this information on bounces, they can commonly be categorised as follows:

  • Hard Bounce: Indicates a permanent delivery failure due to an invalid email address or a closed email account.
  • Soft Bounce: Indicates a temporary delivery failure due to a full inbox, a problem with the recipient's email server, or a blocked email message.
  • Blocked Bounce: Indicates that the recipient's email server has blocked the message due to a filter or policy, such as for spam or content that is deemed inappropriate.
  • Transient Bounce: Indicates a temporary delivery failure that is likely to be resolved if the message is re-sent.
  • Deferred Bounce: Indicates that the recipient's email server is temporarily unavailable or over capacity and that the message will be delivered later.

So far, so technical, so theoretical – still!!

With this understanding, we can clearly see the limits in relation to the current challenges of email communication and deliverability. I personally believe this fully automated server-based communication approach is an opportunity to resolve current and future email challenges.

The last three bounce categories (the newbies 😉) are the ones that are challenging the old approach and idea of sending bounces. They are sometimes seen as being covered in the RFC mentioned above, but they leave a lot of space for interpretation and different uses.

We often see different bounce codes being used by different mailbox providers to mean the same thing – different ways of understanding and interpreting the codes are common and this often leads to frustration.

Let me outline a random fictional example to demonstrate the issue a bit more practically:

“An email message stream from a brand has been marked as spam by a user. The user is only one of many and due to a high number of spam complaints, the mailbox provider is no longer delivering into inboxes but into spam folders and starts bouncing back to get rid of that perceived spam traffic.”

The bounce can look different as every mailbox provider categorises from another perspective:

  • 2xx – successful delivery – the email address exists; the email has been delivered and reached the mailbox providers ecosystem at MTA level, but due to the user-based reputation issue, the email has been delivered into the spam folder. Are we fine with that? Maybe?!
  • 4xx – persistent transient failure – so many users have been complaining about the email stream that the receiver is bouncing due to a policy violation issue and rejects the mail from the inbox into the spam folder. Hmm, questions…
  • 5xx – permanent failure – even if the email address exists, the emails are no longer wanted by the users. The mailbox provider doesn't want to receive this kind of email anymore from the brand and blocks the IP or domain sending 5xx. A permanent status despite an existing and valid email address. Is this possible?!

All we need at this point is a cold beer and popcorn, and this discussion will entertain us for quite a while. And this is just one made-up example, there are many other real-life ones out there.

Here are my thoughts on bounces and the management thereof.

  1. Sending emails is no longer only about technical needs. The growth of commercial emails and the rise of perceived and real spam over the past two decades has kept senders and receivers busy managing the greater expectations and complex requirements. Senders want to reach their commercial target group, while receivers need to find ways to protect their users by managing billions of emails daily. The decision to deliver an email to the inbox is much more complex than it was. Mailbox providers face challenges in bouncing back useful spam information to serious senders, but how do they fit into the technical fundamentals as described above, and how can we avoid misuse of this information by spammers?
  2. Email performance tracking has become much more challenging. Apart from legal considerations, we now encounter a different understanding of email KPIs and their accuracy. Open rates are often understood by email marketers as “the email has been read” – but we all know that isn't the case. And even if the email has been read, what happens next? Isn't the direct feedback from a mailbox provider much better than externally tracked information? What if the “bounce layer” evolves and provides performance feedback about an IP or domain?
  3. This leads to my third point – did the user set up an individual email filter to exclude the emails from a certain domain from their inbox? Apart from mailbox providers filtering, users have also become very picky and sophisticated in their email usage. Do the SMTP status codes or the enhanced status codes still allow for this?

Letting the sender know that a user doesn't want the emails anymore and has filtered them out of their inbox may be helpful in reducing irrelevant traffic. Mailbox providers could demand the removal of that user from the list. Then, senders have clear feedback, which will help with optimising email streams and campaigns.

Suggesting this in a group of email senders and receivers will end up in a controversial discussion. Some will say yes, it would be helpful, others not. The reason isn't that the RFCs do not cover these topics; it is that they leave too much space for the different parties to find their own way of using and understanding them.

This is because we are still trying to fit a long list of new requirements and circumstances into an old bouncing standard which has existed for more than 20 years. It needs updates and additions to meet the current and future requirements to improve and evolve the way of email bounces.

My conclusions:

  1. I think we need to overcome the old-fashioned thinking about bounces being a status reporting between servers only. When we start understanding the bounces (on both the sender and receiver sides) as an automated communication channel, it provides many opportunities to exchange helpful information to mitigate email and spam issues at all levels. Some examples: Criminals get blocked, perceived spammers get clear feedback and warnings about their exposure, legitimate email senders can receive feedback on how their recipients engage with their emails, or the user-based email filter will forward emails into the spam folder in the future.
  2. We need a global working group of email experts covering all different use cases and interests to update the bounce standards and develop a central knowledge and data source that provides consistent and regularly updated bounce messages to standardise sending, receiving, and processing bounces. I'm not just suggesting a written document with a detailed description. I'm thinking of an API-based technical service to which receivers can bounce back a specific notification to the sender. In contrast, the sender can send a query for more information and can then correctly process the bounce code received.
  3. Thinking outside the box here, I personally believe we can use bounce communication to exchange performance-based information about reputation and engagement ratings for a domain. Feeding back reading trends of an email stream or spam complaint rates from a certain domain will provide added value to make email campaigns better and more relevant to the user.

Post a Comment

Comments