by Kirill Popov

Sometimes you send an email but there is nobody there to receive it, and you get a bounce. Sounds pretty straightforward, right? Well, there are a couple of caveats about bounces that help shed more light on what goes on after you hit the send button. In this month’s Delivery Trends, let’s look at bounces, what they are, and how they are handled.

First, there are two types of bounces: synchronous, and asynchronous. These bounces happen at different times, which is why bounce information trickles in over time after your email campaign is sent, rather than showing up all at once.

Synchronous bounces happen immediately during the email dialogue. For example, your sending server mail.acme.com connects to mailbox.inbox.com and tries to send an email to invalidemail@inbox.com. If mailbox.inbox.com is configured for synchronous bouncing, it will immediately break off connection, and tell you that the address is bad.

Asynchronous bounces work in the opposite way. Using the example above, inbox.com would accept your email and try to deliver it to its internal address records. Once it realizes that the email address is bad, mailbox.inbox.com will then send your mail server an email, letting you know.

Second come bounce categories. Bounce meanings are officially marked via a series of numeric codes, to help facilitate cross-language operability. These codes are standardized in two Request For Comment (RFC) documents, the accepted standards of the Internet. There is the older RFC821 which has basic codes, and the updated RFC1893 which includes an enhanced set of reasons.

Permanent or otherwise known as “Hard” bounces are identified by a leading “5” digit in the returned code. For example, a code such as “550” in the older system or an enhanced “5.1.1” codes both mean that the destination address is invalid, which denotes a permanent failure. Typically, these hard bounces are retried once or twice after a number of days, to account for any errors on the receiving system.  Example code: “5.1.1 Bad destination mailbox address”

Transient or “soft” bounces typically have a leading “4” digit as part of the code. These bounces mean that there is a temporary failure that prevented your email from being sent and that you should not be discouraged and retry your message later. A simple example is a user’s mailbox being full. The user is still there, they simply can’t receive your email right then.  An example would be:  “421 Mailbox full”

But there is more! As with any standard on the Internet, this code system is not “enforced” by any sort of Internet police, so there are situations where systems are incorrectly or purposefully configured to return wrong or misleading codes. This is where bounce reasons come in. A bounce reason is a message from the receiving system, such as “mailbox full”, that augments the bounce code. Sometimes you will see a bounce message such as “550 Mailbox is full”. The numeric code denotes that the mailbox was not found, yet the bounce message says that the mailbox is simply full. To play it safe, even “hard” bounces need to be retried at least once.

Because of these inconsistencies, there is always a possibility that a good email address may be rejected, or an invalid email address will remain active in your list. With good bounce handling strategy, however, you should be able to minimize the chances of these errors occurring.