I hope that you had a great holiday season as my family did; however, it wasn’t a long enough vacation…
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 how MTAs handle bounces. Today, I wanted to close this series by discussing how bounces can affect a subscriber’s status within your database.
As you should know by now, bounces are a way for a recipient mail server to tell you how you should treat that message (often including information specific to an email address). Some tell you the address is no longer valid and that you should never try it again, some say that the email inbox for that recipient is full and to try again later, some tell you that the recipient mail server is broken and to come back later, and some tell you that the ISPs suspect that your email might be spam.
In most cases, there is an action to be taken in how you can email that person in the future, if at all.
Let’s take a look at this from an ISP perspective instead today and use the example of a bounce telling you an email address is no longer valid (550 User Unknown).
If you look at AOL’s standards, which are identical to other ISP’s standards, a high number of invalid recipients (bad email addresses) will harm your reputation. Also, it is important to note that many ISP networks and anti-spam systems usually have auto-blocking mechanisms in place to prevent against mailing too many invalid recipients as it looks like a “Directory Harvest Attack.” The ISP has no clue that you are not intentionally malicious, as the data patterns have extremely similar characteristics. They are only trying to protect their network and subscribers from abuse.
You will always have some invalids due to people changing email addresses, but the lower the number, the better your reputation. A majority of spammers (if not all) don’t care about bounces and tend to use the “spray and pray” method. Spray and pray is when a spammer fires out tons of email (usually in long bursts) without aiming, hoping that someone will buy from them when they hit a valid account out of the millions they harvest off the Internet. They never stick around to collect bounces to clean their lists and usually move on to the next rock they can hide under to spray and pray again. So every time they send, they are sending to the same valid and invalid addresses. This is why removing dead addresses is vitally important the first time an ISP tells you the address you’re trying to deliver to is no longer valid.
Another key reputation metric some ISPs use is to count the number of times a particular sending IP address attempts to mail the same inactive/non-existent/dead accounts. This data point can be used as a way to determine if that sender should be blocked. You may have had all the permission in the world for mailing these addresses, but used a system that did not effectively manage bounces with relation to a subscriber’s status. Regardless, the data from the ISP’s point of view is extremely similar to that of a spammer and usually triggers a block (rightfully so).
Now let’s take a look at temporary (often referred to as “soft”) bounces such as mailbox full (again from an ISP’s perspective).
While I am currently unaware of any ISPs that will block based solely on mailing to accounts that are over quota (mailbox full), over time it’s likely those addresses will be abandoned and will eventually turn into a non-existent email account. In the B2C world of delivery, many ISPs have provided plenty of storage space to their subscribers; however, this is often not the case with corporate domains. Therefore, some subscriber management systems are advanced enough to “suppress” mailbox full bounces from various ISPs on the first notification; however, they may not do the same for the same bounces from a non-ISP domain.
Finally, let’s look at one more example such as blocking (you guessed it, from an ISP’s perspective). Again, I don’t know of any ISPs that will block you “more” if you’re trying to send to a system that you’re blocked from, but again it makes no sense to continue to try if you can’t get through.
In terms of seeing a block in your bounce reporting, you should suspend delivery of email to that particular domain until you can resolve the root cause of the issue. ISPs would greatly appreciate the gesture of senders not hammering away at their networks while knowing their mail will not be accepted (do you see any similarities between this behavior and the “spray and pray” behavior we discussed earlier?); however, this will not be enough for you to get the block removed.
Most bounces indicating a block are typically classified in the 5xx (“hard”) category; however, some ISPs will actually issue a 4xx (“soft”) bounce based on reputation (or other parameters). Oftentimes a subscriber status should not be affected based on these codes and verbiage; however, you should:
- Suspend future mailings to that ISP/network/domain.
- Carefully examine your data to determine the root cause of the issue.
- Attempt to resolve the issue with the ISP/network/domain via their proper/preferred channels.
One of the basic principles to ensure good delivery has always been quality over quantity. Address “churn” is always increasing and mailers should expect to see list degradation; however, ensuring that your mailing platform is built to effectively manage a subscriber’s status can be instrumental to your success!
I hope you enjoyed this series and learned something new. Please let me know if there is anything else of interest I can touch on.
Do you ever get the feeling that you’re being ignored? That despite your best efforts to ensure every email you write is a) highly relevant; b) succinct; and c) blurb-free, your message still gets overlooked?
As consumers, we live in a real-time world. We have the technology to access the information we need, when and where we want it, and the "when" is usually "now."
A new starter in Team SaleCycle recently asked me the following question… “Wouldn't they just come back anyway?”