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:

• Gmail
• Yahoo
• Mimecast

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.