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.

Related Posts

Rescuing reputation

One of the more challenging things I do is work with companies who have poor reputations that they’re trying to repair. These companies have been getting by with poor practices for a while, but finally the daily delivery falls below their pain threshold and they decide they need to fix things.
That’s when they call me in, usually asking me if I can go to the ISPs and tell the ISPs that they’re not spammers, they’re doing everything right and will the ISP please stop unfairly blocking them. Usually I will agree to talk to the ISPs, if fixing the underlying problems doesn’t improve their delivery on its own. But before we can talk to the ISPs, we have to try to fix things and at least have some visible changes in behavior to take to them. Once they have externally visible changes, then we can ask the ISPs for a little slack.
With these clients there isn’t just one thing they’ve done to create their bad reputation. Often nothing they’re doing is really evil, it’s just a combination of sorta-bad practices that makes their overall reputation really bad. The struggle is fixing the reputation requires more than one change and no single change is going to necessarily make an immediate improvement on their reputation.
This is a struggle for the customer, because they have to start thinking about email differently. Things have to be done differently from how they’ve always been done. This is a struggle for me because I can’t guarantee if they do this one thing that it will have improved delivery. I can’t guarantee that any one thing will fix their delivery, because ISPs measure and weight dozens of things as part of their delivery making decisions. But what I can guarantee is that if they make the small improvements I recommend then their overall reputation and delivery will improve.
What small improvement have you made today?

Read More

Delivery Metrics

Last week ReturnPath published a study that shows 20% of permission based email fails to be delivered to the inbox. For this study, ReturnPath looked at the mail sent by their mailbox monitor customers and counted the number of deliveries to the inbox, the number of deliveries to the bulk folder and the number of emails that were not delivered.
At US ISPs 21% of the permission based emails sent to the ReturnPath probe network did not make it to the inbox. 3% of the emails sent went to the bulk folder and 17% did not make it to the mailbox at all.  MSN/Hotmail and Gmail were the worst ISPs to get mail to. They each failed to deliver more than 20% of the mail that was sent to them. At Canadian ISPs, even less of the mail made it to the inbox, primarily because primus.ca is such a large portion of the Canadian market and they use Postini as a filter. Postini is a quite aggressive filter and takes no feedback from senders.
ReturnPath’s take home message on the survey is that one set of metrics is not enough to effectively evaluate a marketing program. Senders need to know more about their mailings than they can discover from just the bounce rate or the revenue rate or response rate or open rate.
There are a lot of reasons an email doesn’t get to the recipient’s inbox or bulk folder. Mail can be hard blocked at the MTA, and rejected by the ISP outright. Mail can be soft blocked at the MTA and the ISP can slow down sending. Sometimes this is enough to cause the sending MTA to stop attempting to deliver the mail, thus causing mail to not show up. Both of these types of blocks are usually visible when looking at the bounce rate.
Some ISPs accept mail but then fail to deliver it to the recipient. Everything on the sender end says the ISP accepted it for delivery but the ISP just drops it on the floor. This is the type of block that a mailbox monitoring program is best able to identify.
Despite all the discussions of numbers, many marketers are still not measuring the variables in their email campaigns. Ken Magill wrote today about a study released by eROI that indicates more than a third of marketers are not doing any testing on their mailings.
Now, both of these studies are done in an attempt to sell products, however, the numbers discussed should be making smart senders think about what they are measuring in regards to their email campaign, how they are measuring those factors and what the measurements mean.

Read More

Technology does not trump policy when it comes to delivery

Recently Ken Magill wrote an article looking at how an ESP was attempting to sell him services based on the ESPs ‘high deliverability rates.’ I commented that Ken was right, and I still think he is.
Ken has a followup article today. In the first part he thanks Matt Blumberg from Return Path for posting a thoughtful blog post on the piece. Matt did have a very thoughtful article, pointing out that the vast majority of things affecting delivery are under the control of the list owner, not under the control of the ESP. As they are both right, I clearly agree with them. I’ve also posted about reputation and delivery regularly.

Read More