Renowned blacklist operator Spamhaus recently announced some changes to its DNSBL (a.k.a. blacklist) products, and while we don’t think it’ll have a big impact on SparkPost customers, we wanted to bring it to your attention all the same.

Spamhaus has long had a policy of allowing free use of its DNSBLs up to a point, a policy that’s clearly spelled out on their website. Basically, if you’re a small site making a relatively limited amount of queries, you can make use of Spamhaus’ public DNS servers to facilitate your use of their DNSBLs. This usage came with the caveat that such queries couldn’t be made indirectly through open public DNS resolvers, such as those offered by Cloudflare (IP address or Google (, but instead would have to come directly from you. Those sites with higher volume query needs are required to become subscribers to the DNSBL products and pay Spamhaus an annual fee for a data feed.

In its latest announcement, Spamhaus is indicating that they’re stepping up enforcement of both of these rules. Like all DNSBLs, the Spamhaus DNSBLs function by answering DNS queries, returning a pseudo-IP address (e.g., if the subject of the query is listed, and returning the DNS code “NXDOMAIN” if it’s not. Most mail server software and other tools that query DNSBLs rely on the answer to this query to determine what action to take, with different IP addresses meaning different things.

What Spamhaus is doing is adding two new IP addresses to the list of possible returns:

  • if the query came through a public resolver
  • if the query came from a source that has issued too many queries

Spamhaus believes that it “will be quite uncommon for most Spamhaus users to encounter these codes”, but we here at SparkPost know from our own data that there are some sites out there that appear to be misconfigured in their use of DNSBLs. Those sites tend to be small ones that not many people send mail to, but the subset of those sites that try to make use of Spamhaus may encounter issues related to this change that causes them to incorrectly refuse mail that they might otherwise accept. Should this happen, we anticipate that they’ll figure it out in short order, especially if their inbound mail stream dries up, but we at SparkPost will do our best to spread the word about this change if we see it having a large impact on our customers.


new rules email deliverability best practices