By the time you're reading this I should be attending the 23rd Messaging Anti-Abuse Working Group general meeting in Paris, France. Yes, tough job, but someone's got do it.
As you hopefully recall from a few weeks ago, we wanted to break into sections how email works.
Today we are taking on the second part of this series: "What is a "bounce"?
Defining a Bounce
One aspect of good email marketing practice is being able to interpret and respond to the machine responses (referred to as "bounces") when email fails to be delivered to its intended recipient. Bounces occur because the recipient's mailbox is full, the mail server is temporarily unavailable, or the recipient no longer has an email account at that address. A bounce usually appears as a new note in your inbox when you send a personal or work-related email.
Typically, a bounce message will contain several pieces of information to help the original sender in understanding the reason their message was not delivered:
For most ESPs and large bulk senders, the bounces that are sent back include a codified message in the form of a numeric series (550 or 421) and an expanded description sometimes called a delivery status notification (DSN, such as "User Unknown" or "You're blocked"). In order to comply with the established ISP Acceptable Use Policy (AUP) and to further distinguish your emails from spam, many sending systems like Eloqua and MTA providers like StrongMail, Message Systems, and Port25 all have established efficient and updatable capture and reporting mechanisms for reading and accurately interpreting these bounce messages and then report on them in a categorical way that might normalize the data and organize it into logical categories, such as hard (permanent) bounce, soft (transient) bounce, block, and technical failure. As my industry colleague and friend Dave Lewis said in an article, "a good system will then map these delivery failures into subcategories, such as 'unknown user' under hard bounce or 'URL block' under block." By interpreting or categorizing these bounces, actions can be taken in regard to the bounces and will range from unsubscription of invalid addresses on the first hard bounce to limiting mailing to a domain where a block or some other form of service denial has been detected to removing bad or unknown user addresses.
So what do the numbers mean? What do the words means?
Analyzing the Numbers
The numbers basically are a way to tell a mail server to retry or not retry an email if it fails.
Anything that is 4xx like 421 is a temporary failure and can be retried immediately. It could be for a quick server outage, greylisting, etc.
Anything that is 5xx like 550 is a permanent failure and should not be retried immediately. It's usually for a long-term block, unknown user, or bad email account and should be looked at later for reasoning and whether or not the email should be retried again based on the DSN.
The DSN or wording is just a bounce to help humans read the bounce when it comes back to your email client vs. an ESP bounce system. It tells you more as to why it bounced.
So some examples are:
One thing to consider here: capture all data streams. Make sure that your system collects all bounce data streams - both synchronous (sync) and asynchronous (async) bounces. Synchronous bounces happen immediately during the email transmission. For example, if your sending system connects to an ISP and tries to send an email to firstname.lastname@example.org and if the ISP's mail server is configured for synchronous bouncing, it will immediately pause the transmission, and tell you that the address is bad and not allow for anymore data to be sent.
Asynchronous bounces work in the opposite way. Using the example above, domain.com would accept your email and try to deliver it to its internal address records. Once it realizes that the email address is bad, the ISP's mail server will then send your mail server an email letting you know. Are you asking yourself why do it this way? Spammers often use a form of dictionary attack, sometimes known as a directory harvest attack, for email address harvesting. For example, a spammer may try sending messages to email@example.com, firstname.lastname@example.org, email@example.com, etc. Any addresses to which messages are delivered, as opposed to being bounced back during the first half of the send, can be added to the spammer's list of known-valid addresses if it doesn't bounce in the sync process. So many ISPs move that bounce processor till later as an async so they can monitor those who have spammer-looking activities. Statistically, we see more ISPs bouncing email synchronously.
Now another thing that you need to consider here is that the standards for how bounces should be sent and used was created to not address technical failures such as server outages, full mailboxes, bad email addresses, etc. It was never intended to handle policy-based bounces such as spam or phishing blocking. This wasn't something intentional, we just never thought this far ahead, nor could we.
Make sure when creating or buying into an ESP or in-house solution that the bounce management system can:
With a bounce management system that meets these requirements, you'll be in a position to properly evaluate your performance, manage your list, and improve your practices - all of which translate into better bottom-line results. And you'll be well on your way toward mastering email deliverability
More next time on how MTAs handle bounces.
Dennis Dayman has more than 17 years of experience combating spam, security issues, and improving e-mail delivery through industry policy, ISP relations, and technical solutions. As Eloqua's chief privacy and security officer, Dayman leverages his experience and industry connections to help Eloqua's customers maximize their delivery rates and compliance. Previously, Dayman worked for StrongMail Systems as director of deliverability, privacy, and standards, served in the Internet Security and Legal compliance division for Verizon Online, as a senior consultant at Mail Abuse Prevention Systems (MAPS), and started his career as director of policy and legal external affairs for Southwestern Bell Global, now AT&T. As a longstanding member of several boards within the messaging industry, including serving on the Board of Directors and the Sender SIG for the Messaging Anti-Abuse Working Group (MAAWG), Secretary/Treasurer for Coalition Against Unsolicited Commercial Email (CAUCE), Certified Information Privacy Professional (CIPP) Advisory Board, Dayman is actively involved in creating current Internet and telephony regulations, privacy policies, and anti-spam legislation laws for state and federal governments.
May 22, 2013
1:00pm ET / 10:00am PT
June 5, 2013
1:00pm ET / 10:00am PT