Why ISP Whitelist and ISP Email Delivery Requirements are Not All the Same

ISP email delivery requirements and ISP whitelist requirements differ from ISP to ISP. In fact one of the most frustrating things for commercial and volume email senders is that different ISPs have different standards for what they require in order to ensure that your email gets delivered.

On top of that, many ISPs don’t seem to adhere to the industry standards in terms of how their receiving mail servers interact with the sending mail servers. For example five different ISPs may use five or more different SMTP error messages when they bounce an email because the email address doesn’t exist, even though people believe there to be one generally accepted code for that situation (along the lines of “550 user unknown”).

The good news is that it’s actually pretty easy to comply with the different ISP email requirements even without knowing what they are.

ISP Whitelist Requirements

First we’re going to dispense with the matter of ISP whitelist requirements: there are none. What we mean is that these days none of the big ISPs maintain any sort of whitelist that you can get on. In fact this is one of the primary reasons that our email sender certification service includes a certified email reputation list, not a whitelist. A whitelist says only “you should accept this email because we say so”. The days when major ISPs were more likely to use someone’s whitelist, let alone maintain their own internal whitelist, were based on a relatively static email sending landscape, and that changed years ago. Now they rely on their own spam filtering algorithms, some other metrics, and either our or Validity’s email reputation list (or both) which not only tells them that they should accept and deliver the email from our certified senders, but why they should accept and deliver it. This is one of the reasons that email reputation can be more important than being whitelisted.

So that leaves us with the matter of ISP email acceptance and delivery requirements, and they are not all the same. So why is this? Why don’t ISPs all play by the same rules, as it were?

There are a few reasons, and as a sender it helps to understand why one ISP has different rules, systems, and processes from another.

Why ISP Email Acceptance and Delivery Requirements are Not Standardized

First, ISPs are like any other company – and the larger the company, the more susceptible their processes are to red tape, to “one hand doesn’t know what the other is doing’ syndrome, to corporate hierarchical differences, and, perhaps above all in the Internet industry, to a disconnect between the awareness, understanding, and goals of the executives making the decisions and the technicians who actually have to deal with the day-to-day running of the technical underpinnings of the ISP.

Now add in that the larger the ISP, the more likely it is that they have acquired and not-quite absorbed as many as dozens of smaller regional ISPs. So now you have a situation where a large ISP can actually be operating on several different platforms, with several different email processing infrastructures and architectures – many of which are legacy systems which they inherited as already up and running systems – and you can begin to get an idea of the nightmare that is the average ISP Internet technologist’s daily reality.

Another piece of this puzzle, as alluded to above, is that some of the standards on which ISPs and email senders are operating were developed when the Internet looked very different. The universe of potential statuses of an email address twenty years ago (either it’s a legitimate email address or it isn’t) was much more limited than it is today. So, for example, the 550 SMTP error code which means that the requested action (delivering your email) was not taken because the mailbox was unavailable probably had only a couple of possible meanings twenty years ago (such as “user unknown”), but today there could be any number of reasons that the requested action was not taken and that the mailbox was not available for your mail, ranging from that there is no such email address hosted on that server (user unknown) all the way to that the email address is not available specifically to you because for some reason you have been blacklisted. So while the reasons that email can be rejected have evolved and multiplied, the primary codes remain much the same, and it’s not hard to see how an ISP may reject or otherwise fail to deliver email without returning an error code that makes sense or is helpful to you.

A third aspect of this is that just as email senders are unable to agree on one universal standard for what they need to do in terms of best practices for sending legitimate email, so ISPs do not necessarily all agree on what makes for “legitimate email” which they will accept and deliver, and what is spam, which they won’t. And actually, many email senders would not want the ISPs to agree, as they would almost certainly agree that the standards would include using confirmed (double) opt-in.

Finally, add into the mix that the average ISP is receiving billions and billions of pieces of email every day – nearly all of which is spam, with a little bit of legitimate, non-spam email mixed in.

And then, of course, there is the ever-changing landscape of authentication mechanisms (SPF, DKIM, DMARC, etc.) and what each ISP wants to see for each – or maybe they don’t care at all! For example, ReturnPath explains that in order to have maximum deliverability at Comcast, you should “[u]se Sender Policy Framework (SPF), Domainkeys Identified Mail (DKIM), and Domain-based Authentication, Reporting, and Conformance (DMARC) for all email.”

Put this all together, and you get the current situation: different ISPs having different standards for what they require in order to ensure that your email gets delivered, and sending different messages when it isn’t.

Yes, it’s frustrating for senders, particularly those who view themselves as upstanding senders trying to send legitimate email. But it’s important to remember that it’s hard for the ISPs too, and most of them are trying to do the right thing under onerous circumstances at best.

And, if you want the ISPs to adopt a unified standard for the acceptance and delivery of email, then senders need to adopt a unified standard for acceptable best practices for the sending of email. And they need to be prepared to have any email which does not meet that standard rejected.

Fortunately, there is a set of best practices that will ensure maximum delivery at all ISPs. Here they are.

Best Practices to Ensure That Your Email Gets Delivered at All ISPs

1. Use confirmed opt-in (also known as “double opt-in”)
2. Make it very easy for someone to unsubscribe by including a clearly visible link
3. Honor opt-outs immediately, removing the opted-out email address as soon as you can
4. Have your SPF, DKIM, and DMARC in order
5. Use confirmed opt-in (yes, we said it twice, we really mean it)

Questions? Hit us up in chat, or email us here.