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.

Related Posts

What's the best ESP?

I often get clients and potential clients asking me to tell them what the absolute best ESP is.
“You’re an expert in the field, which ESP will give me the best inbox delivery?”
The thing is, there isn’t an answer to that question.
ESPs have expertise in sending large amounts of mail.  All have staff that manage and monitor MTAs. Most have staff that provide advice on delivery issues. Many have staff that handle abuse complaints, FBLs and blocks.
What they don’t have is magic delivery fairies or bat phones into postmaster desks.
Simply moving mail to an ESP won’t give you delivery. For the most part, delivery is the responsibility of the sender, whether they send mail through an in house system or through an ESP.
Delivery is primarily about how recipients react to a particular mail stream. Send mail recipients want, interact with and relate to and you usually see good delivery. The IP addresses or infrastructure contribute but do not dominate the equation. Sending from an ESP won’t fix poor content, irrelevant mail or unengaged recipients.
I can hear everyone now shouting at their screen “What about shared IPs!!!?!?!” Yes, yes, if you use an ESP with shared IP addresses and the ESP gets a bad customer you may see poor delivery for a time because one of their other customers was bad. It’s a fact, it happens. Plus, if you use an ESP with dedicated IPs and the ESP gets a bad customer you may see poor delivery for a time because one of the other customers was bad and their IP is near yours.
So clearly the answer is to bring email in house. That way no other company can affect your delivery, right? Yes. Kinda.
Are you willing to invest money in hiring email and DNS savvy sysadmins? Invest money in a MTA designed to handle bulk mail? Invest in an expert who not only understands bounce handling, but can explain to your developers what a good bounce handling system must do? Invest in someone who can manage authentication like DKIM? Who can handle delivery issues and understands how to talk to ISPs? Invest in development to write a FBL processor?
For some companies, the internal investment is the right answer, and bringing mail in house makes business sense.
For a lot of companies, though, they just want to use email to communicate with customers. They don’t want to have to invest in multiple staff members (as it’s very rare to find a single person with all the various skill sets needed) to just send a weekly newsletter, or daily sales email. They need a tool that works, they don’t need to know how to sign up for a FBL, they don’t need to know how to handle bounces. They can outsource that work and focus on the communication value.
Finding the best ESP starts with finding out how you want to use email.
Question 1: What role does email play in my business?

Read More

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:

Read More

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.

Read More