You hit the ’send’ button, and your campaign comes back marked ’return to sender.’ Why email bounces -- and what to do about it.
What you’re about to read is quite possibly the least sexy topic on the net. But I figured, "Hey, what better way to launch my new column?" 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., firstname.lastname@example.org), your system needs to look up the domain (e.g., internet.com) and mail server (e.g., mymailserver.internet.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 email@example.com) 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 that 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 Email Bounces
Perhaps the single biggest reason for bounced mail is what I like to call "list decay." Email 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. Email 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!
2015 Holiday Email Guide
The holidays are just around the corner. Download this whitepaper to find out how to create successful holiday email campaigns that drive engagement and revenue.
Three Ways to Make Your Big Data More Valuable
Big data holds a lot of promise for marketers, but are marketers ready to make the most of it to drive better business decisions and improve ROI? This study looks at the hidden challenges modern marketers face when trying to put big data to use.
December 2, 2015
1pm ET/ 10am PT
Wednesday, December 9, 2015
5pm HKT / 5am ET