No topic I address in my deliverability webinars or consultations makes customers’ eyes light up quite like that of “whitelisting”. It’s easy to understand why; it sounds like a panacea for all of their deliverability problems, present and future.

“Whitelisitng” is a loose term that describes any kind of arrangement in which a recipient domain agrees to exempt mail from some or all of their usual filtering processes. In theory, it sounds like a fantastic arrangement for senders; but in practice, such arrangements are relatively rare. Here’s why:

First, not all domains actually bother to maintain a whitelist. Depending on the number of recipient inboxes behind a given domain, managing a whitelist can be an enormous operational burden. Time spent maintaining a whitelist is time taken away from managing other, more pressing issues, like identifying and blocking new sources of malware and spam.

Second, there’s no margin in whitelist maintainance for the recipient domains. ISPs and mail administrators are in the business of ensuring that only the mail their customers want is delivered. Their customers let them know which mail is wanted by opening it, or by clicking on the links it contains (excepting, of course, the unsubscribe link). They don’t need to take senders at our word whether our mail is wanted. If their customers want to ensure delivery of mail that might otherwise be rejected or filtered, many enterprise mail systems and free inbox providers will allow individual users to whitelist mail “on the desktop” by adding the sender or the sending domain to a Contacts folder or Safe Sender list. In an increasing number of implementations, this will override server-level filtering rules for that particular recipient.

Third, those domains who do operate whitelists don’t often exempt listed entities from the full range of their filtering capabilities. For example, the recipient domain might continue to accept mail from a whitelisted IP address in spite of fluctuations in the IP reputation score, but may still subject the mail to their usual content filtering after accepting the mail for delivery.

Fourth, recipient domains already have a significant investment in developing and tuning their in-house filtering systems, or in licensing them from third parties, or in some combination of these two. If your mail isn’t blocked by these systems, then the mail is de facto whitelisted – no need to add you to any list.

Last, whitelisting arrangements are rarely permanent. Even if a recipient domain agrees to whitelist mail, they always reserve the right to terminate the arrangement if they see mail from the whitelisted IP that varies significantly from what they had agreed to let pass. Termination often occurs without warning or notice.

Above all, whitelisting represents a serious possibility of exposing their systems to abusive mail. What if the whitelisted sender’s server or ESP account is later compromised, and is used to send a trojan or other abusive content? The potential risk of whitelisting often far outweighs any possible benefit to recipients.

Most large ISPs that offer some type of whitelisting program have a fairly stringent set of requirements that often include some degree of vetting of infrastructure, policies and content to qualify. What senders typically don’t realize is that, if they can satisfy those whitelisting requirements, they won’t actually need to be whitelisted to ensure that their e-mail is delivered.