Thanks for visiting! Remember that nowadays, (most) blocklists don't really govern deliverability and inbox placement. Want to learn more about email marketing best practices, email technology, and deliverability troubleshooting? Then you'll want to check out my other site, Spam Resource.

Shutting Down Blocklists

As I often do, today I'm receiving reports about a DNSBL (which I've previously warned was dead) is returning false positive entries for those still using it today.

What does this mean?

IF YOU ARE AN EMAIL ADMINISTRATOR WHO USES BLOCKLISTS, you need to start paying attention. DNSBLs are not "set it and forget it." Instead, you should periodically check the lists you're using. Ensure they are still active. Test to see that legitimate mail sent to your server is being delivered. When looking to see if a blocking list is still alive and running, look for a test entry (usually 127.0.0.2) in DNS. Make sure the DNSBL's website is still alive and doesn't mention the list having been shut down. Look on sites like this one (DNSBL.com) and SpamLinks to ensure that your favorite blocking list isn't listed there as deceased.

STOP USING blocking lists that are dead, or might be dead, or are observed as having problems. This is an ounce of prevention that'll prevent many pounds of pain later. Some DNSBLs, when they die, they eventually "list the world" -- making your mail server block every single piece of mail, spam or not. You lose a lot of mail, very quickly, when that happens.

IF YOU ARE A BLOCKLIST OPERATOR, or you're considering becoming one, then you need to read this proposed BCP document: Guidelines for Management of DNSBLs for Email. It's fairly new, so I can understand that not everybody who runs a BL has read it, or understands everything in it, or listens to it. But it's very important that people start reading it, start understanding it, and start incorporating its guidance into their practices.

Why? Because it tells you the right way to run a DNSBL. It explains the best way to provide notice to potential users as to how the DNSBL is implemented, what your policies are, best practices for test entries, and most importantly: Best practice for shutting down a DNSBL in a way that doesn't screw things up for the system admins who are using your DNSBL currently.

This wasn't written in a vacuum; it was written collaboratively with input from a wide range of folks involved in DNSBLs and spam filtering efforts both current and past. And it is by no means set in stone -- but somebody has to start somewhere, and this is what a bunch of smart folks came up with. This should be a must read for any current or future blocking list operator.