What you’re about to read is quite possibly the least sexy topic on the Net. Why risk the vast fame and fortune afforded to ClickZ columnists by writing about such a mundane topic as bounced email? Because it’s that important.
If you send email for a living, you need to know what happens when a campaign or newsletter leaves your server and heads out onto the Net. You need to know because every customer you fail to reach is a sale you fail to make. You need to know because your competitors do. You need to know because it will keep you out of trouble: out of the courtroom and off the blacklists.
A Long and Winding Road
Let’s start with the basic structure of the email process. When you send your campaign to a list, your email delivery software takes your message and generates individual emails for each of the intended recipients (OK, OK — not every system works this way. I’m generalizing). It then queues up each message for delivery. Straightforward enough, right? Now the hard part begins.
For each delivery, your system must accomplish several things. First, for each recipient (e.g., email@example.com), your system needs to look up the domain (e.g., jupitermedia.com) and mail server (e.g., mymailserver.jupitermedia.com). Chances are, it will find them. Every once in a while, a hiccup occurs (perhaps on your end, perhaps on theirs — doesn’t matter), and the domain look-up fails. Bounce.
If the domain look-up succeeds, your mail delivery program attempts to connect to the recipient mail server. If the mail server is too busy, or doesn’t like the way your system is talking to it, or has a list saying it shouldn’t listen to your system at all, it will reject your connection. In all three cases: Bounce.
Even if your message makes it through the gauntlet above and connects to the mail server, it’s not home free yet. Next, your system needs to see if the intended recipient (e.g., egrossman of firstname.lastname@example.org) exists on that mail server and if he has the right and the disk space to accept email. If all those conditions are met (whew!), the content of the email is transmitted (assuming there’s no network failure) and boom, we’re done. Who knew an email had such a hard time getting from sender to recipient? With multiple points of failure, it’s likely even a few good email addresses will bounce from time to time.
Hard Versus Soft Bounces
Every email must successfully jump through many hoops to reach its intended destination. If the process fails at any point before the message is transmitted, your mail system will know it hasn’t completed its task — and can immediately count that delivery attempt as a failure. We call this a hard bounce, because we know it immediately and incontrovertibly. Transmission failed. That’s all there is to it.
As with everything else on the Internet, delivery is not that simple. Sometimes, all the steps above can be completed successfully, including transmitting the message to the server — and the mail can still bounce. How? Some mail servers are set up to receive email without checking whether the intended recipient exists or is authorized to receive mail. The mail server takes in the message and stores it for further analysis.
From your delivery system’s perspective, this appears to be successful delivery. After all, you transmitted the message, got your “success” handshake from the server, and disconnected. But when the recipient mail server does its further analysis — that is to say, checks to see if that user really exists or has enough disk space allowed, it may find your message unworthy. It may reject your message and send it back to your mail delivery system. This type of bounce is a soft bounce. When your system receives these rejected messages, it should mark that delivery attempt as a failure and remember the user bounced.
Why E-Mail Bounces
Perhaps the single biggest reason for bounced mail is what I like to call “list decay.” E-mail addresses go bad. People change jobs, change ISPs, and so on. When they go, their email addresses rarely follow them. Don’t kid yourself that they went around and updated subscriptions on their own. Nine times out of 10, when an address goes bad, it’s a new bounce on your otherwise pristine list.
The other primary reason addresses go bad is users run out of space. A proliferation of Web-based email accounts means everybody and his 90-year-old grandmother has a Yahoo or Hotmail account or two… or three. With only a few megabytes of storage space, inboxes fill up quickly. If you try to deliver mail to a full account, you’ll get a warning message, saying something like “User over quota.” In other words, no room at the inn. Bounce.
Deal With It
Whatever the reason for the bounce — user doesn’t exist, user over quota, network failure — you need to deal with it. I don’t mean you need to get over it. I mean your system needs to be able to respond to bounces and act appropriately. E-mail servers (and the geeks who run them) are smart. If they see you bouncing too much mail to too many people, they’ll block you off their network segment entirely. Then, you won’t be able reach anyone on their server — even the good addresses.
Most advanced email delivery systems can record when an attempted delivery for a specific individual bounces and can keep track of it. In some systems, this is called a bounce count. When your bounce count gets high enough, that name is taken off the list. In other words, if I try you 10 times and you bounce every time, your status changes to inactive. This way, email delivery systems don’t pound the heck of mail servers but instead play nice and stop trying to deliver to people who don’t exist or don’t have permission to accept mail.
Any system worth its salt allows you to configure the bounce settings in detail. You should be able to fine-tune how many attempts are made before a user is moved to inactive. You should also be able to configure how a given user has her bounce count reset to zero. Over the course of a year, you might fail to reach a perfectly good address multiple times. If your bounce count is indiscriminate and only looks at cumulative failures, you’ll eventually collect enough failures to move that good address to inactive status. Those failures are likely to be interspersed with successes. A good email delivery system allows you to count bounces but also to wipe the slate clean after one or more successful deliveries.
A Clean List Is a Happy List
A system that can clean your list by moving bad names off it will make you a happy camper. Ignore bounces at your own peril. It’s a matter of time before some sysadmin decides you’ve been bouncing too many users for too long and decides you’re not getting through to anybody on their network. Cross the wrong guy, and have fun explaining to your client or boss why your reach is now one-half of what you said it would be.
If that isn’t enough (it should be), let me state the obvious: A dirty list will have a very low response rate. If 30 percent of the people you’re attempting to deliver to don’t exist, you bet they won’t be among your respondents. In other words, they’ll sink your response rate. Bad addresses don’t read articles, they don’t buy products, and they don’t respond to campaigns.
Lesson learned? Clean your list, raise your response rate! You’ll be glad you did — and so will your boss, your clients, and your sysadmins. 😉
Got a question? Think I’m full of it? Let me know — send me email!
Edward is on vacation this week. Today’s column originally ran early last year.
Don’t forget to vote for your favorite marketing technology solutions!
Properly implemented DMARC should not affect your deliverability. You can guess what I’m going to say next. Last month I wrote about ... read more
Graze, the snack company which provides nutritious nibbles in slim cardboard subscription boxes, has become a regular fixture in offices, homes and ... read more
Inboxes are so crowded, how can a marketer stand out? Here are eight brands that cut through the noise with great emails. Also, we are all about alliteration.
In theory, having no DMARC record should have no impact on deliverability, but not everyone got that memo.