Bounce Codes: Can't We All Just Get Along?

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.

Bounce Linguistics

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.

Violators-Beware Standard

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.

Tracking Bounces

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.