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.
On the heels of a fantastic event in New York City, ClickZ Live is taking the fun and learning to Toronto, June 23-25. With over 15 years' experience delivering industry-leading events, ClickZ Live offers an action-packed, educationally-focused agenda covering all aspects of digital marketing. Register today!
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.
Hong Kong, May 5-6, 2015
Gartner Magic Quadrant for Digital Commerce
This Magic Quadrant examines leading digital commerce platforms that enable organizations to build digital commerce sites. These commerce platforms facilitate purchasing transactions over the Web, and support the creation and continuing development of an online relationship with a consumer.
Paid Search in the Mobile Era
Google reports that paid search ads are currently driving 40+ million calls per month. Cost per click is increasing, paid search budgets are growing, and mobile continues to dominate. It's time to revamp old search strategies, reimagine stale best practices, and add new layers data to your analytics.
May 6, 2015
12:00pm ET/9:00am PT