In what we believe to be the first collection of bounce codes in one public location, the Get Satisfaction site is now the official home to the eec’s Deliverability Roundtable bounce string project. It is the culmination of many months worth of effort from industry veterans with experience in email deliverability and the technical aspects of sending and receiving email. We decided to place it here since the site allows for dynamic updates as codes change in time and also provides a forum in which users can discuss deliverability issues and receive insight from folks in the industry.
Why is this useful?
The most common form of communication for an ISP to communicate with a sender on a one-to-one ratio is a bounce message. If an email is successfully handed off to an ISP, a success bounce is issued (250 ok). However, if the message is not successfully handed off, an ISP will usually put pertinent information into a bounce message letting you know what the issue is and, in an ideal setting, what you need to do to avoid that bounce in the future. The more failure bounces you collect, the less mail is getting through to your recipients. If you’re concerned about the highest level of delivery penetration, you’ll review the bounce codes to spot trending and actionable items you can do to get your mail through to an ISP. That’s where this site comes into play. We’ve amassed a list of the following ISPs that have standard bounce codes you should be aware of. If you see a bounce from one of them, you should check the Get Satisfaction site to see if more information is available.
Who should use it?
Anyone who has a responsibility around message delivery, most likely your IT or development team, will want to take a look at this. Bounce messages are collected at the email server level so, unless your email application allows easy access to data in a useable format, you’ll need to have someone review the bounce messages at the server level to see the actual ISP message.
How do I use it?
Let’s say you send out a mailing today. After watching the initial delivery numbers, you see that Yahoo has taken a dip in delivery (meaning there’s a delta between the delivery numbers you’re seeing and what you usually expect). Either by using the ESP’s delivery tools or by having someone on your team provide the information, you discover there’s an accumulation of the following bounce strings queuing up on your outbound email server.
“451 Resources temporarily not available – Please try again later [#4.16.5]”
You then go to the new bounce site and search for this string. You should find the following match:
“What does bounce code 451 Resources temporarily not available – Please try again later [#4.16.5] from Yahoo mean?” (check it out).
After you click on the link, you see that this is a bounce message Yahoo! will serve up if their servers are over capacity and are pushing back on mail to allow them to catch up. This is not a sender related bounce but rather a Yahoo! infrastructure one – all you can do is retry the message later and hope Yahoo! has some available cycles at that time (which you should be doing on most soft bounces anyway).
See? It’s that easy. And in most cases there’s a link to the ISP’s postmaster page which will provide further information on what to do or context around why you’re receiving this bounce.
How can you help?
There is no uniform standard amongst ISPs mandating that certain bounces be stated a certain way. As such, you see a huge variety of bounce messages and what information an ISP will provide. Also, as ISPs deem necessary, bounce codes change over time making existing ones outdated and adding new ones. Please help the email community stay on top of the changes by contributing to the GetSatisfaction bounce project site when you see new bounce codes that aren’t listed or know one that’s already listed has changed. By making this an industry effort, we can ensure all of us are up with the latest news. Feel free to ask questions on the site as well. We have a few deliverability folks monitoring it.
Who put this together?
The following folks were involved with this project and we extend our gratitude!
- Joshua Baer – Founder & CEO – OtherInbox/Chief Evangelist - Datran Media
- Dennis Dayman, VP, Privacy, Eloqua
- Michelle Eichner, VP, Pivotal Veracity and Co-Chair, Deliverability Roundtable
- Stephanie Miller – VP, Global Market Development - Return Path
- Jack Sinclair - Co-Founder, COO & CFO - Return Path and Co-Chair, Deliverability Roundtable
- Chris Wheeler - Director of Deliverability – Bronto Software
- and other members of the eec Deliverability Roundtable
– Chris Wheeler, Director, Deliverability, Bronto Software and Member, eec Deliverability Roundtable