Diagnosing Hard Bounces

A very short post about diagnosing hard bounces, because I’ve had to give the same advice to a dozen folks over the past few months.

When you’re diagnosing and mitigating hard bounce rates the first thing you’ll see is your ESPs dashboard or reporting. It’ll tell you how many emails you sent bounced, and how that number has changed over time. A useful start.

But a hard bounce can be caused by any of a dozen or more reasons, and they’ll imply different causes for the issue, and very different approaches to mitigation.

A Venn diagram based on bounce handling classification rules from 3 individual ESPs. The diagram shows overlapping sets of "hard bounce" "soft bounce" and "spam bounce" along with a frustrated stick figure trying to make sense of the confusion.
It’s worse than this now.

The first thing you want to do is to find out details of what’s causing your bounces, by getting hold of the actual rejection messages the recipient ISP returned. They might be available somewhere in your ESP reporting, or you might need to reach out to your support contacts to get them. But an ESP will have access to them (if they don’t … think about looking for a better ESP).

They’re easy to recognise – they’ll start with a three digit number, typically starting with a 5 (or maybe a 4). After that will be some human readable text, and maybe a link to a web page.

The human readable text will describe why the email was rejected. If there’s a link that page will give you more information about the recipient ISPs expectations, and what needs to be improved.

That might be enough for you to understand what’s going on, and if it’s not then those rejection messages are what any expert you ask for help is going to want to see.

Related Posts

Let’s Talk: Bounce handling

Next Let’s Talk session is June 17 with the topic of bounce handling. As always: 5pm Dublin, noon Eastern, 9am Pacific. Send an email to laura-ddiscuss@ the obvious.

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

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.

Read More