As you might recall, the plan to tackle the broad topic of "How Email Works" was to break it down into the following sections:
We left off in the series discussing "What Is a Bounce?" This month, 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, there are five specific locations that will be crucial to the exchange:
Similarly, when you send an email in the simplest form, there are five specific locations that will be crucial to the exchange:
If we stick with our snail mail analogy, a bounce could easily be 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:
When you send an email, the same concept is applied.
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.
OK, 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 receives a bounce from this email, it should look something like this.
—– The following addresses had permanent fatal errors —–
—– Transcript of session follows —– … while talking to smtp.example.net.: >>>> DATA < < < 550 5.1.1… 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.
: 220.127.116.11. does not like recipient. Remote host said: 550 MAILBOX NOT FOUND Giving up on IP 18.104.22.168
The part of the messages that read "MAILBOX NOT FOUND" or "User unknown" is 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:
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:
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 on 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 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 affects 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 like Eloqua today offer a "best in class" bounce handling system that goes beyond simple three-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 this month. Looking forward to "How Email Works, The Final Chapter."
Last Week to Save on SES London Tickets!
SES London takes place February 10-13, 2014. Learn to engage customers and increase ROI by distributing your online marketing efforts across paid, owned & earned media. Join the leaders of today's digital marketing & advertising industry. Find out more ››
*Saver Rates expire this Friday, Dec 13.
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.