If you have been just sitting around waiting for the next part of this series, apologies are in order – the industry has been hopping during the month of October. On the other hand, if you had overlooked the delay, perfect! Glad to catch up with you!
Hoping that you have had the opportunity to take part in some industry-related event in this past month. Personally, I have been privileged to speak at numerous events in several states. I was also proud to take part in Eloqua’s first annual customer event in Las Vegas. It was hugely successful, and a good time, too!
As you might recall, the plan to tackle the broad topic of “How Email Works” was to break it down into the following sections:
- How MTAs (Mail/Message Transfer Agents) Communicate
- What is a “Bounce?”
- How MTAs Handle Bounces
- How Bounces Can Affect a Subscriber’s Status
We left off in the series discussing “What is a Bounce?” Today, I wanted to talk briefly (yeah, right!) about how bounces are handled in the underbelly of the Internet.
Let’s break it down this way.
When you send a postal letter through the United States Postal Service (USPS) there are five (5) specific locations that will be crucial to the exchange.
- Your mailbox
- Your local post office
- The road with the postal trucks on it
- Your recipient’s local post office
- Your recipient’s mailbox
Similarly, when you send an email in the simplest form, there are five (5) specific locations that will be crucial to the exchange.
- Your inbox/outbox
- Your mail server or ISP
- The Internet
- Your recipient’s mail server or ISP
- Your recipient’s inbox/outbox
If we stick with our snail mail analogy, a bounce could easily compared to a letter marked “return to sender.” When you send a letter to an intended recipient at a home or business, but your friendly local postman finds that person is no longer at the requested address, the post office sends the letter back to you explaining that the letter, for one reason or another, is undeliverable. The letter will probably now bear a red stamp on it that describes why they couldn’t deliver it. It usually says something like “Return to Sender – no person at this address.”
Thankfully, when you sent the letter, you also included a return name and address block in the top left hand corner of your letter so that:
- Your recipient knows who sent the letter before opening it.
- If something were to go wrong and the postal service couldn’t deliver it, they know how to return it to you.
When you send an email, the same concept is applied.
- You include a FROM or Return-Path address block so the recipient knows who sent the email.
- If something goes wrong and the Internet Service Provider (ISP) is not able to deliver the email because the person is no longer on that service, they know how to return and notify you.
- The “bounce,” or your “return to sender” notification includes a bit of information describing why the email could not be delivered. The most common bounces are 4xx (i.e., 421 Mailbox Full) and 5xx (i.e., 550 Recipient Not Found) errors. These can widely vary depending on both the ISP that is sending the email back and the sender’s systems.
Without getting into all the nuts and bolts of the specs, according to the RFC (Internet Standards) specification, all 4xx class errors are considered to be temporary failures and should be retried later. Again, by RFC specs, all 5xx class errors are permanent failures and should not be retried.
Okay, let's take a look at a couple of bounce messages. Buried in the myriad of letters and numbers, are a few important things:
Let’s say you attempted to send an email to a friend at example.com. If your MTA (Mail Transfer Agent or your mail server) receives a bounce from this email, it should look something like this.
—– The following addresses had permanent fatal errors —– <email@example.com>
—– Transcript of session follows —– … while talking to smtp.example.net.: >>>> DATA <<< 550 5.1.1 <firstname.lastname@example.org>… User unknown <<< 503 RCPT first (#5.5.1)
Here's a bounce from another mail server, which attempts to be friendlier:
Hi. This is the qmail-send program at example.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out.
<email@example.com>: 10.10.10.10. does not like recipient. Remote host said: 550 MAILBOX NOT FOUND Giving up on 10.10.10.10.
The part of the messages that read "MAILBOX NOT FOUND" or "User unknown" are key. Depending on the reason for the failure, these might actually be one of several different messages.
Again, just like your local postal office, when the letter is returned to them by the recipient’s post office (because they couldn’t deliver the letter), they:
- Look at the return name and address block to see who originally sent the letter.
- Look at the red stamp that was put on the letter by your recipient’s local postal office.
Your local postal office can then make a determination on what to do with your letter. In this case, the protocol is to return the original letter to your postal box at home, so you can take an action on it. Maybe it’s time to update your address book, or double-check your penmanship. Once you have cleared up the mistake, you can then resend the letter. (Or you could convince your friend that email would be much better than postal mail anyway.)
In the email world, when the email is returned to your mail server (or ISP) by your intended recipient’s mail server (or ISP), they:
- Look at the Return-Path or bounce address it was sent from when it bounced to see who to send a notice to.
- Look at the codes stamped in the bounce by the recipient’s mail server (or ISP) to determine the reason for the bounce or failure to deliver the message.
Your mail server (or ISP) will then send you the original email with a set of stamps (550 User Unknown) as shown above telling you what happened so you can take an action it. Maybe that action is to remove that person from your address book or double check the email address you had typed. (Thankfully, this time your poor penmanship is not to blame.)
One of the most common solutions for a bounced email, (aside from checking to be sure that you are sending to the right address, of course), is to "wait a while and try again". The email system, while somewhat random, is also somewhat self-healing. If there's an email server with a problem, chances are it will get fixed or eventually bypassed, especially if it belongs to a larger ISP. For temporary problems, email servers will typically keep trying for up to four (4) days before giving up and will let you know if they have indeed given up with a bounce.
Now let’s talk about how this effects you on a day-to-day basis. How does my ESP or in-house solution handle my bounces for my campaigns on such a large level? Most companies today offer a “best in class” bounce handling system that goes beyond simple 3 digit (550 or 421) error processing. They want to ensure the best possible deliverability to each of your recipients. Most should be attempting to read not only the error codes, but also the description of the error, like “User Unknown” or “Mailbox Full.” So, their system should go the extra mile and continue to retry temporary failures automatically for you, or should stop trying to deliver email to bad email accounts. They should also be very THOROUGH in their reporting of email failures to you so you can understand the problems or trends in your email marketing programs (hard, soft, blocks, technical, etc failures). This also means they should retry failures intelligently, making sure they do not overload the receiving system in the process.
So, that’s it for today. That is how email servers handle bounces in a nutshell. If you have any questions, please do not hesitate to email us to get further clarification on this subject, submit a topic idea, or plain just post a comment to us. Looking forward to How Email Works, The Final Chapter. (Coming soon to a blog post near you.)
Don’t Just Send, Deliver!
A big thanks to my wonderful wife for editing this document for me. She rocks. and I have the t-shirt to prove it. (she wrote that part, but it’s true)