Retrying a bounced address three times is excessive in my opinion. If an ISP didn’t like a message on the first or second attempt, there’s little to suggest that a third or tenth attempt will bring any more success. Generally, removing on the first bounce is too aggressive for the reasons John mentions above, specifically to cover ourselves when an ISP misreports a bounce.

I’m not very familiar with how other ESPs process bounced emails but we also add an element of time in our bounce processing rules. For example, we might require 7 days between the first and last bounce before we automatically suppress the address. Similarly, we may require 14 or 21 days before we suppress a soft bounced addresses. This gives the ISP some time to resolve any internal issues before we start hacking addresses out of a list.

The biggest benefit we get from our configurable bounce processing system occurs when we’re working with a new client with a valid opt-in list that hasn’t been mailed to in a while or who is coming from an environment where bounce processing was week or non-existent. For these lists, we get very aggressive and for the first mailing we remove on the first bounce. If a client doesn’t agree with our policy, we suggest they try another ESP.

Without getting too into the weeds here, RFC 3463 defines 4.x.x (4xx) as a Persistent Transient Failure (known as a soft bounce) and 5.x.x (5xx) as a Permanent Failure (hard bounce). The little x’s all have meaning, too, and that’s often where ISPs fall down in reporting back some of the more detailed information.

ISPs will, however, more often than not return some additional information with little keywords such as “denied”, “unknown”, “refused”, “bad”, “spam”, “invalid”, “suspended”, or maybe even “deactivated”. It’s that little extra can can help determine why the message was rejected rather than something like 5.0.0 or 500, and why it’s important that these things are recorded in Bounce Logs that users have access to.

A lot of ESPs realize that most operators aren’t sophisticated enough to understand all of these little things, so instead of teaching their users, they hide the information and make these decisions for them. In some respects I think that this retards the operators ability to learn what’s going on with their bounced messages.

On the other hand, it does help to protect users from themselves who might think that retrying a permantly rejected message a couple more times might be a good idea and something that an ISP would not only not ding them for, but maybe even appreciate their tenacity.

Those using in-house systems or appliances without this kind of knowledge put themselves at risk; often create deliverabilty problems for themselves, call someone like me, and then want to debate about the wisdom of retrying permanently failed records multiple times before giving up….

There are times that ISPs make mistakes and accidently hard bounce everyone. That’s the exception, not the rule.

When that happens, if you’re paying attention, you can go back and release those records from suppression. It’s a good idea to only release those records impacted by that error and not all email addresses that previously hard bounced for that domain.

When I said that it took at least 30 days for technology that had ownership and control over the email system to stop retrying hard bounced records, that’s how long it took them to pull their collective heads out of their posterior and realize that I might have a bit of a clue as to what I was talking about.

But some “expert” somewhere that was more opinionated than informed on the subject told them that retrying permanent failures was a good idea, and since that’s what they wanted to believe….