How Email Works…Part Quatre

I hope that you had a great holiday season as my family did; however, it wasn’t a long enough vacation though…

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 “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 ISP’s suspects 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 mostly 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 hind 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 your 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 use a system that did not effectively manage bounces with relation to a subscriber’s status. Regardless, the data from the ISPs 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 are 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 your trying to send to a system that your 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 sender’s 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). Often times a subscriber status should not be affected based on these codes and verbiage; however, you should:

  1. Suspend future mailings to that ISP/network/domain.
  2. Carefully examine your data to determine the root cause of the issue.
  3. Attempt to resolve the issue with the ISP/network/domain via their proper/preferred channel's.

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!

Again, I want to thank one of my good friends and colleagues in this industry Greg Kraios for helping me originally with this idea. He helped with the first post and had hoped to participate more during the series, but do to some pressing issues could not help as much as we wanted; however today he was able to add his two smart cents to this final posting in the series and in record time I might add. Great work my friend…

-Dennis
Eloqua

Don't Just Send, Deliver!

Dennis Dayman

More posts by

Oracle | Eloqua

Don’t Just Send, Deliver!

Follow Dennis Dayman

Tags:

Comments are closed.

UA-9835597-1