Your bounce classification is a bit rubbish

When a mailbox provider rejects or defers an email it sends back a message explaining why.

Those messages begin with a three digit number (starting with a “5” for rejections and a “4” for deferrals), followed by text that explains why the mail wasn’t accepted. That text often contains a link to follow for more information, or a mailbox provider specific code you can use to look up more details as well as a human readable description. There’s sometimes a set of three numbers separated by dots – these enhanced status codes give more details as to why the mail wasn’t accepted too.

Many large mailbox providers and spam filter developers publish lists of the rejection messages they’ll send, and what they mean. Just a few examples:

Many ESPs don’t make these rejection messages clearly visible to their customers, rather they group them into broad categories like “soft bounce”, “probable spam”, “user unknown”. That makes perfect sense for reporting – if you’re looking at rejection and deferral trends over time you can only usefully report on a small number of variables.

But bounce categorizers are often a bit rubbish.

Look at this list of rejections:

  • 554-5.4.7 [internal] (last transfail: 452-4.2.2 The recipient’s inbox is out of storage space.
  • 550 permanent failure for one or more recipients
  • 554 5.4.7 [internal] (last transfail: 454 4.4.4 [internal] no MX or A for domain)
  • 550 [internal] [oob] The message failed for unspecified reasons.

A nameless ESP classified all those as “TempFail (suspected spam)”.

They’re all permanent 5xx failures, not temporary ones (though some of them are repeated deferrals that have been escalated to a rejection after multiple delivery attempts). And there’s no suggestion from any of them that the delivery was rejected for anything to do with spam. One of them is an abandoned mailbox that’s filled up, two are probably email addresses that don’t exist and one looks like a failure in the ESPs asynchronous bounce parser.

So “TempFail (suspected spam)” is a bit rubbish on several different axes.

If you were to try and diagnose and fix your delivery issues based just on the ESP categorization you’d end up heading off in completely the wrong direction.

If you’re trying to work out what’s going on with your mail delivery one of your first steps should be to look at the actual rejection messages – see what they say, drop them into a search engine, ask your peers about them. Hopefully your ESP makes them available in their user interface somewhere, but if not your support folks should be able to get them for you.

If your ESP is doing bounce management based on their bounce categorizations it may have the same issues. A persistent 5xx permanent delivery failure should lead to an email address being suppressed. If it’s being miscategorized as a “TempFail” or a spam block it may not be. And repeatedly trying to deliver to an email address that doesn’t exist isn’t the best way to look like a legitimate sender.

Related Posts

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

Don't think bounce handling is important?

James from Cloudmark has his own insight on spamtraps.

Read More

Bounce handling simplified

I am a strong believer that bounce handling should be designed to remove addresses that have no human on the other end while not removing addresses that have a real recipient on the other end.
Bounce handling should be designed to appropriately manage your subscriber base. Delivery problems are the consequence if you don’t do that. They shouldn’t be the reason you bounce handle, though.
Context matters.
My experience tells me that senders that think about the impact of their sends can do things that “break the rules” while still being respectful of their subscribers and still see good delivery.

Read More