What’s a bounce?

Bounces and bounce handling is one of those topics I’ve avoided writing about for a long time. Part of my avoidance is because there are decades of confusing terminology that hasn’t ever been really defined. Untangling that terminology is the first step to being able to talk sensibly about what to do. Instead of writing a giant long post, I can break it into smaller, more focused posts.

What is a bounce?

A bounce is when an email is undelivered. In the deliverability field, we use the term bounce to describe mail that was not delivered during the SMTP transaction and mail that was later returned as undeliverable.

Why does mail bounce?

There are a large number of reasons mail is undeliverable. One of the common reasons mail is undeliverable is because the recipient address doesn’t exist. Mail can bounce for other reasons, too. Some of those reasons are technical: the mail is malformed, or the receiving server is having a problem. Other reasons are filter related, like the sending IP has a poor reputation or there is a block against content in the mail.

What should we do when mail bounces?

That depends on the specifics of the bounce. In the SMTP protocol there are 3 answers a receiving mail server can given when presented with an email:

  • I accept this message,
  • I will never accept this message
  • I don’t accept this message, but ask me again later.

MTAs handle the individual emails just fine. If they get a “never accept” (5xy) response, they immediately stop trying to deliver the message. If they get a “tray again later” (4xy) response, they will attempt to redeliver for a certain period of time.

Where’s the confusion?

The confusion is that we have a situation where we need to make decisions about trying the next email based on extremely limited data. There’s also a very diverse usage of SMTP response codes among MTAs. The same 3 digit codes can mean different things and the same messages are assigned different 3 digit codes. All in all, a situation that is not easily handled mechanically.

You haven’t mentioned soft or hard bounces?

I have, sort of. 5xy (no, never) responses are sometimes called hard bounces while 4xy (try again later) responses are sometimes called soft bounces. This isn’t what bulk senders mean when they use the terminology. Generally, hard bounces are used to mean emails that will never deliver and that usually means the address does not exist but can be something technical (DMARC fail, technical problems, etc) that needs to be fixed on the senders end before attempting to mail again. Soft bounces mean emails that might deliver in the future, so mostly every other bounce type. In these cases soft and hard terminology does not map onto the SMTP 4xy and 5xy response codes.

What is a soft bounce?

A soft bounce typically describes a case where a message was not accepted by the receiving server, but there’s no evidence the next message won’t deliver.

What is a hard bounce?

A hard bounce typically describes an email address not existing. No future message will deliver because the address does not exist.

What’s the problem? Just suppress hard and send to soft.

It’s not that simple. There are cases where something breaks and ISPs response “user unknown” to every email, even those that are valid addresses. In these cases it’s worth attempting to send a few times before suppressing the address from future mails.

There are also cases where a soft bounce is actually permanent. Take the “mailbox full” case. In the environment of multi gigabyte mailboxes and spam folders that don’t count towards a mail quota, it’s very rare for mailboxes to actually fill up. It can happen, but in most cases of mailbox full the mailbox has been totally abandoned. Maybe the recipient lost the password, maybe they passed away, whatever it is, the mail is never going to deliver.

Bounce handling recommendations

For user unknown the sooner you stop sending the better. In the early 2000s there was a handshake agreement between a group of ESP representatives and ISP representatives that address that bounce will be removed after 3 consecutive bounces in a period of more than 15 days. In the years since then, this has been a standard recommendation. Many ESPs have their own bounce handling rules, and they’re all within the spirit of the agreement.

The short version of all of this is that bounces are a fact of life, and that if mail repeatedly fails to deliver to an address then it’s time to suppress the address from future mailings.

 

Related Posts

Spike in Yahoo error codes

A number of people have mentioned over the last couple weeks that they’re seeing a spike in Yahoo rejecting mail with
554    delivery error: dd Requested mail action aborted
Discussions on various mailing lists indicate these messages are related to inactive accounts. Addresses that bounce at Yahoo with these codes should be handled as inactive addresses and removed from future mailings.

Read More

Why is bounce handling so hard

It should be easy, right? Except it’s not. So why is it so hard?
With one-on-one or one-to-few email it’s pretty simple. The rejections typically go back to a human who reads the text part of the rejection message and adapt and makes the decision about future messages. The software handles what to do with the undeliverable message based on the SMTP response code.
In the case of a 5xy response the server stops attempting delivery and alerts the original sender the mail failed. One example from helping a client troubleshoot a delivery problem recently.

There’s useful information in the text portion of this email from my mail server. It says there was a permanent failure (550) and that my message won’t be delivered. It also says the email is quarantined in reply to the end of DATA. That’s actually a critical piece of information. It means Barracuda saw the entire message before deciding to reject it. It’s likely a problem with the content of the email and so I need to look at links in the message.
This type of plain text explanation is great for a human to read and act on. But it’s not that simple for list handling software to identify the relevant information in the text message and act on future emails to that recipient. Different MTA vendors and ESPs have done a lot of work to try and correctly parse bounce messages to pull out relevant information.
ISPs have tried to help the situation by giving more descriptive rejection messages. They’re still using the SMTP required 3 digit numbers, but they include short, parseable codes in the text portion of the message. In many cases they also include URLs and links that open up webpages explaining the meaning of the code. They even post a list of the most common codes on their postmaster webpages.
All of these things make it somewhat easier to handle bounces automatically. Kinda.
I’ve been working on some bounce handling recommendations for a client using a few different ESPs. I spent a good few days digging into the bounces returned by their different ESPs. It was an interesting exercise as it demonstrated how very differently ESPs handle bounces. But it also clarified for me that there are a lot of different kinds of bounces.

Read More

Relaying Denied

I’ve got multiple clients right now looking for insights about bounce handling. This means I’m doing a lot of thought work about bounces and what they mean and how they match up and how different ISPs manage delivery and how different ESPs manage delivery and how it all fits together. One thing I’ve been trying to do is contextualize bounces based on what the reason is.
Despite what people may thing, spam filtering isn’t the only reason an email fails to deliver. There are lots of other reasons, too. There is a whole category of network problems like routing issues, TCP failures, DNS failures and such. There are address issues where a recipient simply doesn’t exist, or is blocking a particular sender. There are spam and authentication issues. The discussion of all these issues is way longer than a blog post, and I’m working on that.
One of the interesting bounces that is so rare most people, including me, never talk about is “Relaying Denied.” This is, however, one of the easier bounces to explain.
Relaying Denied means the mail server you’re talking to does not handle mail for the domain you’re sending to. 
Well, OK, but how does that happen?
There are a couple reasons you might get a “Relaying Denied” message, most of them having to do with a misconfiguration somewhere. For whatever reasons, the receiving server doesn’t handle mail for a domain.
DNS records are incorrect. These can be due to a number of things

Read More