Your e-mail bounces. The ISP sends a bounce code to define the problem. Why don't all ISP codes match?
As emailers, we know about blacklists, blocklists, and whitelists and their impact on email delivery. What about the areas in between? A critical dialogue between emailers and ISPs takes place not before or after, but during the messaging process -- through bounce codes.
Different browser platforms have different coding standards. Nonconformity can lead to unviewable pages. Browser manufacturers rationalize this as a competitive advantage that can provide a better, or unique, online experience.
The same can be said for ISPs and their competitive advantage in the war against spam. Every ISP now promotes its spam-fighting prowess. What they don't advertise is each of their processes for replying to email offers a unique set of codes to determine message deliverability. This process for bouncing email is a critical part of the spam-fighting repertoire.
When a server rejects an email, the server returns a set of bounce codes, that identify and often explain why the message was rejected. Standards for these codes were written in 1982 by the late Jon Postel as part of the overall SMTP standards. A protocol equates a code to the type of email failure that resulted in the email's rejection. The standards are guidelines for online servers. In 1996, the codes were updated specifically for enhanced mail systems to further clarify the bounce process.
Over time, the traditional processes for code identification and explanation became more dynamic. Problem is, ISPs use them inconsistently, or they're incorrectly applied. This frequently results in the return of a hard bounce code when an email address is still valid.
The enhanced coding system adequately describes the numbers' order and meaning. Since 1996, we've seen new code interpretations, such as user feedback complaints. E-mailers have a template to explain multiple types and layers of bounces, but no code is used consistently to define persistent violation of an ISP's terms and use policy, which would lead to blocklist status.
I recently attended a meeting with many of the largest ISPs. We discussed creating a standard surrounding a 5.7.1 bounce code to provide a "violation notice code." The 5 represents persistent messaging; 7 represents a policy issue; and 1 relates to the recipient address.
ISPs don't want to bounce messages. It drains resources. They'd rather stop email at the gate. They can choose to terminate a senders' ability to reach recipients by blocking IP addresses or delete messages altogether. The hope is prior to those scenarios, an intermediary bounce notification, such as the 5.7.1 code, can warn of blocking or filtering actions that might occur.
Hats off to AOL, which announced a new whitelist program last week. It publicly stated it will track and monitor bounce patterns from large senders and offer automatic image serving only for senders that meet threshold requirements.
For reputable emailers, it's a welcome sign. In contrast to Microsoft's decision to eliminate graphics as the default, AOL's approach gives emailers a fighting chance for delivery success.
How hard is it for ISPs to track bounces from large senders? E-mailers shouldn't have to guess what bounce codes really mean or worry their mail will be deleted. E-mailers should be liable for ineffective bounce handling and pay a penalty if they abuse the system. An ISP bounce-handling fee might be one solution to the problem.
If emailers are liable and ISPs offer a common intermediary warning code, the email delivery process would be that much more effective.
Should there be a bounce-warning code? Should emailers be liable for bounce handling? Share your thoughts.
Want more email marketing information? ClickZ E-Mail Strategies is an archive of all our email columns, organized by topic.
Join the Industry's Leading eCommerce & Direct Marketing Experts in Chicago
ClickZ Live Chicago (Nov 3-6) will deliver over 50 sessions across 4 days and 10 individual tracks, including Data-Driven Marketing, Social, Mobile, Display, Search and Email. Check out the full agenda and register by Friday, Oct 3 to take advantage of Early Bird Rates!
Ben Isaacson is the privacy and compliance leader for Experian, overseeing Internet and advanced technology privacy and compliance affairs across Experian Marketing Services products including CheetahMail, Digital Advertising Services, and Hitwise. Mr. Isaacson's previous roles include serving as the executive director of the Association for Interactive Marketing (AIM), a former DMA subsidiary. He regularly blogs at EmailResponsibly.com.
IBM Social Analytics: The Science Behind Social Media Marketing
80% of internet users say they prefer to connect with brands via Facebook. 65% of social media users say they use it to learn more about brands, products and services. Learn about how to find more about customers' attitudes, preferences and buying habits from what they say on social media channels.
An Introduction to Marketing Attribution: Selecting the Right Model for Search, Display & Social Advertising
If you're considering implementing a marketing attribution model to measure and optimize your programs, this paper is a great introduction. It also includes real-life tips from marketers who have successfully implemented attribution in their organizations.
September 23, 2014
September 30, 2014
1:00pm ET/10:00am PT
October 23, 2014
1:00pm ET/10:00am PT