What a good day to dust off another in my pile of unfinished blog posts and random ideas thanks to the folks @StrongMail for sharing “Marketing chiefs: Are you spamming your customers?”
“And nearly one fifth (17 per cent) of marketers surveyed are not failing to remove email addresses from mailing lists after messages bounce back.”
Reminded me of a story from a year or so ago. It was after dinner with some email friends when like the wine the email war and horror stories started to flow.
Being a consultant I have to maintain a certain level of obliqueness when sharing stories. Sure there’s the whole NDA thing, but more importantly I don’t like to kiss and tell; I don’t care what you think you see on my collar….
So I’m telling this story about a client company with a less-than-commercial email system owned internally by technology. The company used a deliverability service; because they never bothered to weight the deliverability seed list to their distribution list they totally missed the flashing lights and sirens going off for the domain that comprised about 30% of their subscriber base. And spam traps? You don’t even want to go there….
We do all of the basic stuff, like stop mailing to defunct domains and anything with spam, abuse, or postmaster, and clean out just a whole lot of other junk, and then go to take a look at the bounce logs. They don’t really have bounce logs – they were making high seven-digit channel revenues and they didn’t have any sort of bounce logs – hello; is this thing on? – but they had this little bounce counter software thingy that would at least kind of flag to suppress addresses under certain criteria.
Now, since there aren’t any RFC Bounce Code Police enforcing the stringent application of 4xx and 5xx codes, it’s not a bad idea to have a little more log information than “bob@foo.com is a 5″…. I’m just sayin’…. Anyway, it was what it was and it was what I had to work with at the moment, so whatamIgonnado?
Then I learned that they were retrying hard bounces three times before ceasing to mail to that address again. I know! Three times! Seriously!
And as if that weren’t enough, the technology owners of the in-house email tools wanted to argue the wisdom of attempting to deliver an email that has been soundly rejected with a stated cause. Of course we didn’t know what the stated cause was because we really didn’t have any sort of bounce logs to look at, and the bounce counter would purge bounced addresses after it counted and classified them and blah blah blah blah blah….
It’s all kind of a blur now, and I can’t remember if it took them 30 days or 3 months to finally stop retrying hard bounces three times. There are just so many threes in there and I’ve been trying to block some of it out so that I’m not afraid anymore….
So we’re sitting around with milk coming out of our noses– which is weird since we were drinking wine, but whatever – and I tell my buddy, Dennis, sshhh…. The next day we’re on this deliverability panel at an email event and three quarters or more of the way through our session, he asks, “How many people here retry hard bounces three or more times?”
I think that I might have blacked out for a moment, but at least didn’t fall out of my chair; that would have been bad. The shocker came for me when I saw the number of hands that went up in the room. Anecdotally I’d say maybe 20% of the room had their hand up.
A brief explanation of the differences between what a hard bounce means and what a soft bounce means had pens to paper for more than those with their hands up. From the looks of the survey quoted in “Are you spamming your customers?” maybe more people should have attended that panel.
The good people at the Email Experience Council’s Deliverability Roundtable have put all the email bounce codes in one place with the industry’s first bounce code directory making it easy to learn about bounce codes and what they mean in case you’re interested and can’t make it to an industry event. You might miss some fun stories, but I can’t help with that.
And the next time you visit Deliverability.com be sure to ask Dennis why retrying hard bounces three times is a bad idea. He likes questions like that….
Are you suggesting a move to unsub on the first hard bounce? While I would never recommend more than three attempts I’ve seen people I hold in high regard recommend three consecutive hard bounces for unsubscribe simply because the ISPs are not infallible and there have been instances of ISPs defaulting to no such user when, for example, they lose their database connection.
Some of this has to do with sending regularity though; three consecutive bounces is more appropriate for an environment that sends regularly. Less regular senders could likely do fine with two consecutive bounces but the alternative is reversing a block of unsubs every time you find out an ISP accidentally hard bounced everyone.
Now if it took 30 days or 3 months that indicates an irregular sender that could have done with 2 to unsub, but the goal is to set the threshold high enough to get past any ISP issues that create false hard failures, and unsub on the first hard bounce won’t do that.
First let me say that there is a difference between unsubscribing someone and suppressing them. The results are the same, but the way it’s recorded is different. But that’s another story….
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….
Interesting discussion. Bounce processing is one of the key pieces of our mailing platform and gets the same amount of attention/programming as the rest. Consequently, we’re able to define bounce processing rules at the bounce code level for each mailing list permitting us to be more or less aggressive when needed.
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.
Great post, John! We remove hard bounces after the first, we have had a lot better results that way. I think I have only seen it once in our system where we had false hard bounces and it was an issue on the receivers side, in that case we restored their mailing status and kept an eye on things.