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:
- The date and time the message was bounced
- The identity of the mail server that bounced it
- The reason that it was bounced (e.g., user unknown or mailbox full)
- The headers of the bounced message
- Some or all of the content of the bounced message
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:
- 550 User unknown = Don’t retry now and don’t send again
- 421 Greylisting = Retry now and send again
- 550 You’re blocked = Don’t retry now and send later after addressing why block occurred
- 451 No reverse DNS = Retry now and send again later after you fix your DNS
- 552 Message too big = Don’t retry now, but send again later after reducing size
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:
- Capture all data streams such as sync and async.
- Correctly interrupt the data that can be confusing in itself in the above bullet examples.
- Organize and normalize the data to handle the thousands of bounces you might get.
- Make the data and reporting actionable to the user. Remove the email address or retry the email.
- Be updateable since bounces can change over time and ISPs are always changing.
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.
The web doesn’t have a traffic problem, but it has a conversion problem.
Do you ever get the feeling that you’re being ignored? That despite your best efforts to ensure every email you write is a) highly relevant; b) succinct; and c) blurb-free, your message still gets overlooked?
As consumers, we live in a real-time world. We have the technology to access the information we need, when and where we want it, and the "when" is usually "now."
A new starter in Team SaleCycle recently asked me the following question… “Wouldn't they just come back anyway?”