Bounce

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.

Your bounce classification is a bit rubbish

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

There’s something about bounces

I’ve shared a version of this image repeatedly. I think it was only my Facebook friends that got the stick figure screaming in frustration, though.

Share your average bounce rates

The question came up on slack this morning about bounce rate benchmarks. What are the normal / average bounces that different ESPs see? Does region matter? What’s acceptable for bounce rates?

Recycled addresses, spamtraps and sensors

A few hours ago I was reading an ESP blog post that recommended removing addresses after they were inactive for a year because the address could turn into a spamtrap. That is not how addresses turn into spamtraps and not why we want to remove active addresses. Moreover, it demonstrates a deep misunderstanding of spamtraps. Unfortunately, there are a lot of myths and misunderstandings of spamtraps in general.

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.

Targets and measures

Spike in Yahoo error codes

A number of people have mentioned over the last couple weeks that they’re seeing a spike in Yahoo rejecting mail with
554 delivery error: dd Requested mail action aborted
Discussions on various mailing lists indicate these messages are related to inactive accounts. Addresses that bounce at Yahoo with these codes should be handled as inactive addresses and removed from future mailings.

Why is bounce handling so hard

It should be easy, right? Except it’s not. So why is it so hard?
With one-on-one or one-to-few email it’s pretty simple. The rejections typically go back to a human who reads the text part of the rejection message and adapt and makes the decision about future messages. The software handles what to do with the undeliverable message based on the SMTP response code.
In the case of a 5xy response the server stops attempting delivery and alerts the original sender the mail failed. One example from helping a client troubleshoot a delivery problem recently.

There’s useful information in the text portion of this email from my mail server. It says there was a permanent failure (550) and that my message won’t be delivered. It also says the email is quarantined in reply to the end of DATA. That’s actually a critical piece of information. It means Barracuda saw the entire message before deciding to reject it. It’s likely a problem with the content of the email and so I need to look at links in the message.
This type of plain text explanation is great for a human to read and act on. But it’s not that simple for list handling software to identify the relevant information in the text message and act on future emails to that recipient. Different MTA vendors and ESPs have done a lot of work to try and correctly parse bounce messages to pull out relevant information.
ISPs have tried to help the situation by giving more descriptive rejection messages. They’re still using the SMTP required 3 digit numbers, but they include short, parseable codes in the text portion of the message. In many cases they also include URLs and links that open up webpages explaining the meaning of the code. They even post a list of the most common codes on their postmaster webpages.
All of these things make it somewhat easier to handle bounces automatically. Kinda.
I’ve been working on some bounce handling recommendations for a client using a few different ESPs. I spent a good few days digging into the bounces returned by their different ESPs. It was an interesting exercise as it demonstrated how very differently ESPs handle bounces. But it also clarified for me that there are a lot of different kinds of bounces.

Relaying Denied

I’ve got multiple clients right now looking for insights about bounce handling. This means I’m doing a lot of thought work about bounces and what they mean and how they match up and how different ISPs manage delivery and how different ESPs manage delivery and how it all fits together. One thing I’ve been trying to do is contextualize bounces based on what the reason is.
Despite what people may thing, spam filtering isn’t the only reason an email fails to deliver. There are lots of other reasons, too. There is a whole category of network problems like routing issues, TCP failures, DNS failures and such. There are address issues where a recipient simply doesn’t exist, or is blocking a particular sender. There are spam and authentication issues. The discussion of all these issues is way longer than a blog post, and I’m working on that.
One of the interesting bounces that is so rare most people, including me, never talk about is “Relaying Denied.” This is, however, one of the easier bounces to explain.
Relaying Denied means the mail server you’re talking to does not handle mail for the domain you’re sending to.
Well, OK, but how does that happen?
There are a couple reasons you might get a “Relaying Denied” message, most of them having to do with a misconfiguration somewhere. For whatever reasons, the receiving server doesn’t handle mail for a domain.
DNS records are incorrect. These can be due to a number of things

Zombies are real but less of a problem

A few years ago I wrote a series of blog posts about zombie email addresses. Zombie addresses are those that someone owned and used and interacted with, but for whatever reason stopped logging into and checking. This series started with the time before the zombies, and moved on to the zombie uprising. Then discussed how they don’t eat brains, but they do love to take a bite out of deliverability. Smart marketers, however, can defeat zombies by the judicious application of the double tap.

Since that series of blog posts a few things have changed. The biggest thing is that the webmail providers are being much more aggressive about disabling email reception at addresses where folks don’t log in. I have a few addresses on different providers I use for testing purposes. I have to remember, though, that I need to log into them before sending test messages. If I don’t, they generally bounce.
This doesn’t completely remove the challenge of zombie addresses but it does make it easier for regular senders to purge their lists of zombies just through their normal bounce handling. No double-taps needed.

Alternate contact when mail bounces

We received an invite from a local company recently. At the top of the invite there was a sticker.
We attempted to send email, but your address bounced. Please contact either me or the tasting room to update. Thanks!

April 2015: The Month in Email

We started the month with some conversations about best practices, both generally looking at the sort of best practices people follow (or don’t) as well as some specific practices we wanted to look at in more depth. Three for this month:

Best practices … what are they?

“We follow all the best practices!” is a common refrain from many senders. But what does best practices really mean?
To me the bulk of best practices are related to permission, technical setup and identity.

Increase in bounces at Y!

I’ve been seeing reports over the last few days about an increase in bounces at Yahoo. Reliable people are telling me they’re seeing some increase in “invalid user” bounces.
You may remember Yahoo announced an overhaul of their mail product back in December. Reliable sources tell me that this is more than just interface revamp. In the back end, Yahoo! is removing older products with few users and security problems. This fits in with the changes CEO Mayer has been making with the company: slim down and stop supporting unprofitable products.
It makes sense that while engineers are looking at the guts of the email program and cleaning up the cruft, they will also disable long unused email addresses. This will result in higher unknown users for some senders.
What’s interesting to me is that the reports are somewhat sporadic. Some senders are seeing a huge percentage of bounces, some are seeing the normal percentage. I expect this difference isn’t anything more than how actively a sender purges based on engagement. Senders that purge unengaged addresses are going to have already removed a lot of the addresses Yahoo! is now purging from their database. Senders that keep sending to their whole list, are going to see a lot of unknown user bounces.
I’ve asked a few folks and people who’ve responded told me that spot checks showed all the addresses turning up as invalid had no engagement for long periods of time.
If you are seeing a lot of bounces at Yahoo! over the last few days, you need to remove those addresses from your lists. I also recommend looking at the engagement statistics of these newly purged recipients. This will tell you, approximately, what an abandoned address profile looks like. You can use that information to make good decisions about purging unengaged users at other ISPs as well. Not only does this lower costs, because you’ll be sending to less non-responsive email addresses, it will also improve delivery at many ISPs.

Thoughts on bounce handling

This week’s Wednesday question comes from D.

What are your thoughts on bounce handling
Read More

Bounces, complaints and metrics

In the email delivery space there are a lot of numbers we talk about including bounce rates, complaint rates, acceptance rates and inbox delivery rates. These are all good numbers to tell us about a particular campaign or mailing list. Usually these metrics all track together. Low bounce rates and low complaint rates correlate with high delivery rates and high inbox placement.

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.

Don't think bounce handling is important?

James from Cloudmark has his own insight on spamtraps.

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.

Blocked for phishing

A couple clients recently have had bounces from different places indicating that their mails were caught by the recipients’ anti-virus filter. These are some of my better clients sending out daily newsletters. They’ve been mailing for years and I know that they are not phishing. They asked me to investigate the bounce messages.
The information I had to work with was minimal. One bounce said:

Soft bounces and rate limiting

What is your policy for handling soft bounces? What do you consider a soft bounce? What is the right thing to do about soft bounces?
The first step in talking about soft bounces is to define them. When I talk about soft bounces, I mean mail that has been rejected with a 4xx response during the SMTP transaction. As described by RFC5321, when a recipient MTA responds with a 4xx it is telling the sending MTA “Wait! I can’t take this mail right now. Come back a little later and try again.” The sending MTA will then continue to attempt to deliver the message until either it is delivered or until it hits the max delivery time, usually 3 – 5 days.
In a well behaved and RFC compliant MTA, messages that have reached the maximum time without delivery due to 4xx rejections will be converted to permanent rejections (5xx). With a correct MTA, this means too many emails in a row timing out shoud result in an email address being removed from future mailings.
For a number of reasons some ISPs, notably Yahoo, are using 4xx responses to slow down mail from some senders. Many senders treat this as a inconvenience and a frustration and try to figure out how to get around the rate limiting. The UK DMA published an article on soft bounces with the following words of wisdom.

Reputation

Reputation is the buzzword in delivery these days. Everyone talks about building a good reputation and how to do it. Makes sense, the ISPs are always hammering on reputation and how critical reputation is. The more I talk with delivery folks on the ESP side of thing, the move I realize that there is a fundamental disconnect between what the ESPs mean when they say reputation and what the ISPs mean when they say reputation.
Many people handling delivery think that the bulk of reputation is wrapped up in complaint rates and bounce rates. I think they know the ISPs measure more than just complaints and bounces (spamtraps!) but really believe that most of developing a good reputation is all about keeping those complaints low.
This perspective may have been true in the past, but is becoming less true as time goes on. There are a lot of very smart people managing incoming mail at the ISPs and they are constantly looking for ways to better meet the desires of their customers. Lest we forget, their customers are not the senders, their customers are the end users. Their customers are not senders.
Part of meeting the needs of end users means actually giving them a way to provide feedback. AOL started the trend with the this-is-spam button, and other ISPs (ones that controlled the user interface at least) followed suit. For a very long time, reputation was dominated by complaint percentages, with modifiers for number of spamtrap addresses and number of non-existent users.
The problem is, these numbers were easy to game. Spammers could modify their metrics such that their email would end up in the inbox. In response, the ISPs started measuring things other than complaints, bounces and spamtraps. These other measurements are strong modifiers to complaints, such that mailers with what used to be acceptable complaint rates are seeing their mail end up bulked or even rejected.
Recently, AOL seems to have made some subtle modifications to their reputation scores. The result is mailers who have previously acceptable complaint rates are seeing delivery problems. When asked, AOL is only saying that it is a reputation issue. Lots of senders are trying to figure out what it is that is more important than complaints.
Tomorrow, I will talk about what I think AOL could be measuring.