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

20% of email doesn't make it to the inbox

Return Path released their global delivery report for the second half of 2009. To put together the report, they look at mail delivery to the Mailbox Monitor accounts at 131 different ISPs for 600,000+ sends. In the US, 20% of the email sent by Mailbox Monitor customers to Return Path seed accounts doesn’t make it to the inbox. In fact, 16% of the email just disappears.
I’ve blogged in the past about previous Return Path deliverability studies. The recommendations and comments in those previous posts still apply. Senders must pay attention to engagement, permission, complaints and other policy issues. But none of those things really explain why email is missing.
Why is so much mail disappearing? It doesn’t match with the philosophy of the ISPs. Most ISPs do their best to deliver email that they accept and I don’t really expect that ISPs are starting to hard block so many Return Path customers in the middle of a send. The real clue came looking at the Yahoo numbers. Yahoo is one of those ISPs that does not delete mail they have accepted, but does slow down senders. Other ISPs are following Yahoo’s lead and using temporary failures as a way to regulate and limit email sent by senders with poor to inadequate reputations. They aren’t blocking the senders outright, but they are issuing lots of 4xx “come back later” messages.
What is supposed to happen when an ISP issues a 4xx message during the SMTP transaction is that email should be queued and retried. Modern bulk MTAs (MessageSystems, Port25, Strongmail) allow senders to fine tune bounce handling, and designate how many times an email is retried, even allowing no retries on a temporary failure.
What if the missing mail is a result of senders aggressively handling 4xx messages? Some of the companies I’ve consulted for delete email addresses from mailing lists after 2 or 3 4xx responses. Other companies only retry for 12 – 24 hours and then the email is treated as hard bounced.
Return Path is reporting this as a delivery failure, and the tone of discussion I’m seeing seems to be blaming ISPs for overly aggressive spamfiltering. I don’t really think it’s entirely an ISP problem, though. I think it is indicative of poor practices on the part of senders. Not just the obvious permission and engagement issues that many senders deal with, but also poor policy on handling bounces. Perhaps the policy is fine, but the implementation doesn’t reflect the stated policy. Maybe they’re relying on defaults from their MTA vendor.
In any case, this is yet another example of how senders are in control of their delivery problems. Better bounce handling for temporary failures would lower the amount of email that never makes it to the ISP. This isn’t sufficient for 100% inbox placement, but if the email is never handed off to the ISP it is impossible for that email to make it to the inbox.

Read More

Bounce handling is hard

Sometimes I find it hard to find a new topic to write about. I decide I’m going to write about X and then realize I did, often more than once. Other times I think I can blog about some issue only to realize that it’s too complex to handle in a quick post. There are concepts or issues that need background or I have to work a little harder to explain them.
One thing I haven’t blogged about before is bounce handling. That particular topic falls into the other category of posts that take a lot of time to write and need a significant amount of work to make sense. I was even joking with my fellow panel members at EEC a few months ago about how that’s a post that so needs to be written but I’m avoiding it because it’s so hard. There’s so much to be conceptualized and explained and I realize it’s not a blog post but multiple blog posts, or a white paper or even a book.
Bounce Rate words on a thermometer or gauge measuring the rate of abandonment as visitors or audience leaves your website or online page or resource
So let’s start with some simple definitions.  Those of you who work at ISPs are probably thinking of bounces in terms of accept than reject, that’s not exactly what I’m talking about here. I’m writing these for senders, who usually call rejects during the SMTP transaction bounces.

Read More