Blocklist Removal Center
About Spamhaus  |  FAQs  |  News Blog   
Frequently Asked Questions (FAQ)
Datafeed FAQ
Generic Questions
ISP Spam Issues
Legal Questions
Marketing FAQs
Online Scams
Spamhaus BCL
Spamhaus CSS
Spamhaus DBL
Spamhaus PBL
Spamhaus SBL
Spamhaus XBL


Why use a DNSBL?
How do I use a Spamhaus DNSBL?
Which DNSBL should I use?
Must I run my own DNS server to use DNSBLs?
How do I check my DNS server results?
What do the 127.*.*.* Return Codes mean?
DNSBL Queries
Your DNSBL blocks the whole Internet!
Your DNSBL blocks nothing at all!
I am getting a "This is not the DNSBL you're looking for" error, why?
Not just for connection queries...
Running SpamAssassin
Free Use vs Commercial Use
Data Feed: Zone Transfers (rsync) for Corporate networks & ISPs
What about lookups on the Spamhaus website?
Testing the mail server
Testing your Spamhaus DNSBL Setup
Will doing a query to your DNSBL servers slow my system and delay the email?
I'm seeing bounces, but I don't find my IP address in your list... help?
But if there is ever a delay, won't all my incoming email get backlogged?
Querying your DNSBL servers will use a lot of bandwidth, won't it?
How solid is the Spamhaus DNSBL server network?
Missing 'A' record for sbl/xbl/pbl/dbl/
How can I use the Spamhaus zones (ZEN or SBL, XBL, PBL) if I don't run my own mail server?
Are there any other DNSBL uses that could help?
Can I use the Spamhaus DNSBL on my web server or other applications?

Why use a DNSBL?
Doing a DNSBL lookup on a message at SMTP connect time is cheap in hardware cycles and system time. Your DNS server may even have it cached from the last time the spammer tried.

If your MTA already knows the incoming message is spam it can deny a spam message before having to pass it to mail-scanner (medium cost), through the virus scanner (medium to expensive), bayesian filtering (medium), spamassassin network tests: blacklists, DCC, pyzor, razor, etc. (medium - high).

Mail rejected by a DNSBL during delivery is not silently discarded into the "bit bucket". A DNSBL realtime rejection creates a delivery status notification (DSN) to the sender identifying the cause of the rejection, therebye allowing troubleshooting on the sender's end. (i.e., no "lost messages")

Realtime rejection avoids the "backscatter" problem of some spam filters which accept delivery, close the connection, and then try to return the mail after it is determined to be spam. Of course, as we all know, most spam and all viruses have forged sender addresses, and so the "bounce" goes back to an innocent third party (if it is deliverable at all).

Using the SBL, XBL & PBL lists together, or the combined Spamhaus Zen zone (recommended), rejects a very large amount of spam and virus mail with very low "false positive" rejections of legitimate mail. And remember, when used in SMTP realtime, all those rejected legitimate mails are instantly reported to the sender with a DSN.

How do I use a Spamhaus DNSBL?
These answers presume you are running your own mail server AND understand what you are doing. You must fully understand the function and purpose of each DNSBL you use.

All modern mail servers have a 'DNSBL' feature (sometimes called 'RBL Servers' or 'Blacklist'). If you are not sure whether yours does, read its 'Help' file or ask your mail server vendor.

Depending on how much email traffic you have, you can either use Spamhaus public mirrors free by setting your mail server's 'DNSBL' feature to query, or - if you have high traffic - you will need a special Data Feed from us.

There is more information in our "How-to-Use" FAQ, and see the following FAQ 'What zone should my server or spam filter query?'

Remember, use your mail server to query a Spamhaus DNS zone such as Do not automate queries of our website lookup form!

There are other ways to use SBL beyond just checking the connecting IP. Our Effective Spam Filtering page has suggestions for checking URIs in the spam against SBL, which is very effective at stopping spam. Nameserver IPs of connecting hosts are another check which some admins have found effective. If you decide to do such checks on your mailstream, be very careful which Spamhaus zone you select for each step. Checking against SBL is quite conservative and will have few false positives. Checking against XBL is more aggressive and while it will catch more spam it may also intercept more non-spam mail. Don't use URI checks against PBL unless you know exactly what you're doing; that will result in rejecting non-spam mail for most servers. Remember that Zen zone contains SBL, XBL and PBL combined, so you will need to select the correct response based on the 127 return code.

Which DNSBL should I use?
The Spamhaus Block List (SBL), Exploits Block List (XBL) and Policy Block List (PBL) can be used by all modern mail servers by setting your mail server's anti-spam DNSBL feature (sometimes called "Blacklist DNS Servers" or "RBL servers") to query our zones. All three lists should be queried in one single DNS lookup in the zone. Do not query each subzone of Zen (SBL, XBL, PBL) seperately, that is redundant and more work for your server and ours.

Mail servers should also query the Spamhaus DBL Zone. That is a separate query from the Zen query. DBL is for domains, Zen is for IP addresses.

We also publish the zone which includes both SBL and XBL data, but not PBL. It can be appropriate for some mail client filtering, later in this DNSBL Usage FAQ.

You may also wish to use other DNSBLs published by other organizations. Information, reputation and opinions about other DNSBLs are available on the web. Careful selection and implementation of DNSBLs, including the order in which your mail server queries various zones, can provide optimal performance and spam protection for your server's users.

For information on how to configure your mail server to use the Spamhaus zones, please refer to your mail server documentation or manuals, or ask your mail server developer. With so many different mail servers in use we can not offer technical help with setting up the query system. As Zen includes PBL, which has many dynamic ranges, be sure to whitelist any dynamic ranges which are authorized to use your outbound relay. Authenticating users via SMTP AUTH is strongly recommended and avoids the need to whitelist authorized ranges.

An overview of Effective Spam Filtering strategies explains additional uses of block lists such as URI_SBL in SpamAssassin, and the use of DBL, SURBL and URIBL domain-based DNS spam blocking lists.

Must I run my own DNS server to use DNSBLs?

Not necessarily, but it is worth considering. Let us explain:

First off, you can access and use Spamhaus DNSBL data through the global Domain Name System (DNS). DNS traffic itself carries the questions and answers regarding the DNSBL listed/not-listed status of IP addresses and domains: data travel exclusively on the DNS protocol. You normally configure one or more DNS servers (typically two) in your operating system. Those are the IP addresses of the servers that will negotiate all the DNS requests made by your applications, and therefore those DNS servers will be the vehicle for your Spamhaus DNSBL requests, too.

Next, be aware that there are several ways to access Spamhaus DNSBL data:

For many small, low-volume users' mail servers, Spamhaus data is available via our own global network of mirrors, DNS servers which answer billions of queries per day from millions of other small users. Those mail servers issue a DNS query sent via the DNS server specified in settings in the computer's operating system. That DNS server could be operated locally on the same computer or network as the mail server, or operated by a hosting ISP or other outsourced DNS provider for authorized client access only, or it could be an "open" or "public" DNS server which answers for anyone who queries it.

For higher-volume clients which exceed a query volume threshold, Spamhaus expects them to use either our Datafeed Rsync Service to deliver the DNSBL zone data to their own local DNS server, or else our Datafeed Query Service (DQS). DQS queries work just like small-user queries, via whatever DNS server is configured in the operating system. Datafeed Rsync users must run a local DNS server which receives and stores Spamhaus data, and answers their queries.

Now, many ISPs and hosting service providers, and virtually all pay-for-service outsourced DNS specialty providers, are scrupulous about providing highly accurate DNS results based on RFC-specified traversal of the DNS tree, from the global roots up to the authoritative zone servers. As long as those DNS servers are providing your application with accurate and authoritatively true responses, your mail server will get accurate answers from our DNSBL zones and your mail filtering will work correctly.

On the other hand, some consumer oriented ISPs and most "open" or "public" DNS services use NXDOMAIN hijacking to monetize null DNS answers as explained in this FAQ: Your DNSBL blocks the whole Internet! That's OK for applications like end-user browsers, but for mail servers those hijacked NXDOMAIN answers can translate into blocked legitimate mail. Other public DNS servers are blocked from querying Spamhaus data; see this FAQ: Your DNSBL blocks nothing at all!. Some public DNS providers wisely implement non-hijacked responses for known DNSBL zones like Spamhaus, but if you are not sure that those solutions are perfect and will never fail, you could be risking your mail by using those DNS servers to answer DNSBL queries.

So, in summary, if you use our Rsync Datafeed, you must have your own DNS server. If you use our Datafeed Query Service or free public access, you do not need your own DNS server, however you should carefully consider the accuracy of any third-party DNS server and the consequences of any erroneous or untrue answers from such a service, and be aware that operating your own local recursive DNS server can put you in full control of the veracity of the answers to your DNSBL--and other DNS!--queries.

How do I check my DNS server results?

A quick way to check that you are getting correct Spamhaus DNSBL responses from a DNS server, whether local or third-party, is with command-line DNS queries for targets known to be (a) listed in a Spamhaus zone ( and then, (b) known to be not listed ( 'Listed' queries must answer with a proper return code; for Spamhaus that's one or more of our 127.* responses. 'Not listed' queries must always return NXDOMAIN for your mail filtering to work properly. For example:

$ dig +short @[DNS.server]
$ dig +short @[DNS.server]
Host not found: 3(NXDOMAIN)

Remember to check for both 'listed' and 'not listed' results. In either case, [DNS.server] (without the brackets) is the hostname or IP address of the DNS server you wish to query. Omit the server name or IP, and the '@', from the command line and your query will be handled by the DNS server configured in your computer's OS, which is probably the DNS server you wish to check. Checking our DBL zone uses similar DNS queries; see this DBL FAQ for details.

The command "$ host [DNS.server]" provides similar results.

In Windows, try "C:\>nslookup".

You may also wish to check the TXT record of '' with 'dig' or 'host' to confirm that your mail server will provide the correct results for delivery error messages:

$ dig +short TXT @[DNS.server]

To find which DNS server(s) your unix, linux or OSX computer is using, run this command on the machine in question: "$ cat /etc/resolv.conf". In Windows, the DNS servers are configured under "Control Panel/Network and Internet".

What do the 127.*.*.* Return Codes mean?
Spamhaus uses this general convention for return codes:

Return Code Description Spamhaus IP Blocklists Spamhaus Domain Blocklists Spamhaus Whitelists

Return codes for Spamhaus IP zones:

Return Code Zone Description SBL Spamhaus SBL Data SBL Spamhaus SBL CSS Data XBL CBL Data SBL Spamhaus DROP/EDROP Data (in addition to, since 01-Jun-2016) PBL ISP Maintained PBL Spamhaus Maintained

See the DBL FAQ for return codes for DBL.

DNSBL Queries
We recommend you use SBL together with XBL and PBL, as the three zones block different spam sources. To save you having to query three separate DNSBL zones there is a special combined DNSBL zone called Zen which contains the complete SBL, XBL and PBL data. We recommend you use this combined DNSBL zone for checking SMTP connecting IP. To use it, simply set your mail server's DNSBL check to query only. (Don't query SBL, XBL or PBL and Zen!)

DNSBL Zone to Query Returns Contains
SBL,9 Static UBE sources, verified spam services (hosting or support) and ROKSO spammers
XBL Illegal 3rd party exploits, including proxies, worms and trojan exploits
PBL IP ranges which should not be delivering unauthenticated SMTP email.
ZEN Combined zone (recommended)
Includes SBL, XBL and PBL.

Your DNSBL blocks the whole Internet!

There can be several reasons why a DNSBL appears to list all IPv4 addresses (when it really doesn't):

When you implement Spamhaus DNSBL filtering in your mail server, you must check that the zone you have just entered is spelled properly. If you accidentally put in a wrong domain such as '' or '', the DNS queries generated by your mail server will go to some entirely different and unrelated place which can answer your queries with a valid A record containing an IP address (this is often done by "typosquatters" to catch web traffic). Even if this IP is not a conventional DNSBL answer in the 127.0.0.x range, your mail server may still interpret it as a "listed" answer, and block the mail accordingly.

Another problem we have seen is where ISPs "hijack" some DNS replies. This is done to monetize website traffic. Rather than returning an NXDOMAIN ("not found") answer for a DNS request that cannot be found (resolved), a pointer to an advertising page or search page is given. Many public or "open" resolvers, as well as some secure resolvers on cloud-based or wide area networks, use NXDOMAIN hijacking. As Spamhaus' "not listed in our zone" replies are the same as a "webpage not found" reply, users behind this sort of DNS monetization schemes will always see an IP address returned rather than the correct NXDOMAIN DNS answer. If this is the issue, there are three possible ways to resolve it: (1) instruct your mail server to ignore all response codes that are not in as they come from a "man in the middle" hijacking, not from us; (2) contact your ISP or DNS provider to see if you can opt out, otherwise change DNS resolvers; or (3) set up your own DNS resolver (technically the best).

A second form of DNS hijacking has been seen, where an ISP cuts off DNS traffic to DNS servers it feels are being queried too often. That may also return an IP value, which will cause all email to be flagged as spam. They may even null the value of the DNSBL's name. That can cause unpredictable results and you will need to contact your ISP.

Finally, erroneously using DBL as an IP list rather than as a domain list may also have the effect of blocking all mail: see the DBL FAQs.

Your DNSBL blocks nothing at all!

First, check our FAQ answer for "Your DNSBL blocks the whole Internet!" and make sure you've not made a spelling mistake in your mailserver configuration.

Check what DNS resolvers you are using: If you are using a free "open DNS resolver" service such as the Google Public DNS ( and others (eg. Alternate DNS, Comodo Secure, DNS.Watch, DynDNS, FreeDNS, Hurricane, NeuStar DNS Advantage, Norton ConnectSafe, OpenNIC, Puncat, Quad9, SafeDNS, Uncensored, Verisign, Yandex.DNS), or large cloud/outsourced public DNS servers, such as Level3's, Verizon's or AT&T's to resolve your DNSBL requests, in most cases you will receive a "not listed" (NXDOMAIN) reply from Spamhaus' public DNSBL servers. We recommend using your own DNS servers when doing DNSBL queries to Spamhaus. If this is not possible, contact us for other options.

I am getting a "This is not the DNSBL you're looking for" error, why?
You have probably misspelled "" as "" in your mail server configuration. This is the error message defined by the people administering that domain (not us). This case belongs to the category discussed under the Your DNSBL blocks the whole Internet! question.

Not just for connection queries...
In addition to checking the IP addresses of the connecting servers against the SBL/XBL/PBL (or Zen), you can significantly boost your spam catch rate by also scanning the email body of any mails, that get past this first check, looking for host names of URLs (web sites) advertised in spams, and checking the IP addresses of those hosts, and their name servers, against the SBL. This is because the SBL lists the IP addresses of spammers' websites in addition to their mail servers. This feature ("URIBL_SBL") is available in SpamAssassin 3.0 on, and code to do this is also available as a sendmail milter from here.

Running SpamAssassin
Your SpamAssassin version should be at least 3.4.1, released in April 2015. If you are running an earlier release, please upgrade. SpamAssassin 3.4.1 will query the Spamhaus lists out of the box, with no configuration changes required.

Warning: SpamAssassin 3.4.1 has an important bug (described in detail here) that needs to be patched if the release of the Net::DNS Perl package installed on your system is 1.01 or larger. If you installed SpamAssassin as an O/S package, the bug may have been fixed already. If you installed it from sources, the bug is present. In all cases, locate the directory where the file is located and run the following commands:

if ! grep -q '$packet->header->rd(1)'
then	# apply patch
  cp -p
  patch << 'EOF'
---    2015-04-28 19:56:49.000000000 +0000
+++    2015-07-20 18:24:48.000000000 +0000
@@ -592,6 +592,9 @@
   if ($packet) {
+    # RD flag needs to be set explicitly since Net::DNS 1.01, Bug 7223
+    $packet->header->rd(1);
   # my $udp_payload_size = $self->{res}->udppacketsize;
     my $udp_payload_size = $self->{conf}->{dns_options}->{edns};
     if ($udp_payload_size && $udp_payload_size > 512) {
  echo " has already been patched."
It will not be necessary to do this on the forthcoming SpamAssassin 3.4.2.

For further information we recommend to consult the SpamAssassin documentation.

Queries done by SpamAssassin will sum to the other queries directly made by the MTA. The total must remain below the free usage threshold defined in the DNSBL Usage Terms.

Free Use vs Commercial Use
Use of the Spamhaus DNSBLs via DNS queries to our public DNSBL mirrors is free of charge for low-volume non-commercial use. To check if you qualify for free use, please see the Spamhaus DNSBL Usage Terms.

Use of the Spamhaus DNSBLs by ISPs, corporations and networks with high email traffic, or commercial spam filter companies requires a subscription to the dedicated Data Feed Service run by Spamhaus Technology.

Data Feed: Zone Transfers (rsync) for Corporate networks & ISPs
For corporate networks, Internet Service Providers and spam filter companies, Spamhaus provides a dedicated Data Feed service which transfers the Spamhaus DNSBL zones to a local DNS server on your network and keeps the zones synchronised every few minutes. Please follow this link for further informations.

What about lookups on the Spamhaus website?
The Blocklist Removal Center lookup tool is provided for people to check their own IP or domain conveniently, and to direct any listed parties to the correct information for fixing the problem and removing the listing. It is intended for manual lookups only. No automated lookups, please! Any perceived use of automated tools to access the web lookup system will result in firewalling or other countermeasures. Access to blocked IPs will result in "403 ERROR" HTTP responses.

Testing the mail server

Once you are convinced that your mail server setup is complete, you can try the testing service kindly maintained by Crynwr Software. This service consists of a robot that will send you email from a listed IP to verify that your server blocks the message. The testing service is available independently for SBL, PBL and XBL (SBL tests are initiated by, PBL tests by and XBL tests by

To activate the robot, you have to send an email (content or subject do not matter) to the special addresses (for SBL testing), (for PBL testing), or (for XBL testing). This email must be sent from the IP address used by your mail server to receive mail, because the robot can test exclusively the IP address that originated the testing request. If you have difficulties in doing that -- for instance because your outbound mail goes out from a different IP, or because you are using multiple IP aliases -- you will have to send mail using telnet "by hand", making sure that the source IP address of your connection coincides with the IP address where your mail server is listening for connections. Also make sure that you are using a functional email address under your control as sender, as the results of the tests will be mailed to this address.

If the test is successful, you will get back from the robot an email containing the SMTP dialogue between the robot and your server. If the test is unsuccessful, you will get two mails: the mail containing the SMTP dialogue, and the test mail that the robot managed to send you in spite of being listed on the BL you are testing.

If all works, congratulations: your setup work has now finished. Enjoy the missing spam!

Testing your Spamhaus DNSBL Setup
Once you have set up your mail server to use a Spamhaus DNSBL you can test to see whether your configuration is working by sending a test email as explained on this page: You must send the email from the mail server which you wish to test. The Crynwr system robot will reply to tell you if your server is correctly blocking Spamhaus DNSBL-listed IPs or not.

Will doing a query to your DNSBL servers slow my system and delay the email?
Our servers are very fast and run software optimized specifically for speedy DNSBL replies. They are geographically distributed around the globe and connected via high-bandwidth pipes. Query response time is typically in the low milliseconds so any delays will be indiscernible, and once a query is done, it is cached at your own local DNS resolver for a period of time. That makes further queries "local" to you and extremely fast.

I'm seeing bounces, but I don't find my IP address in your list... help?

The Spamhaus Blocklists are only some of many public DNSBL systems. In addition to publicly-queriable lists, many networks maintain their own private blocking lists. And DNSBLs are only one of many reasons that could cause a Delivery Status Notication (DSN).

Read the bounce ('DSN') messages carefully; they should provide clues as to why your mail was rejected. Unfortunately, some of them are not accurate or helpful; sometimes they even point to Spamhaus SBL for no reason at all. But, since each system which rejects your mail may give a different DSN, do read several of the messages and you will find some that make sense and help you track down the problem.

Locate the IP address which was rejected, generally the IP address of your outbound mail server and usually noted in the DSN message. Test it in the "IP Removal" form at If it does not show up with that form, the address is not listed in any Spamhaus DNSBL (that form queries all the most current Spamhaus zones).

A few sites which might help you track down DNSBL issues with other lists are:

Remember that none of those sites is a DNSBL itself so it cannot possibly block your mail, and that they are offered on a voluntary basis, without support. Use their web services, but please don't pester them!

Some DNSBLs are simply too aggressive, unreliable or otherwise unsuited to use by more than a few hobbyist domains, places where most legitimate senders are unlikely to ever send any mail. If your IP address is in such a list, just ignore it! It's not stopping you from mailing anyone and no one who knows anything about mail cares about such lists.

But if there is ever a delay, won't all my incoming email get backlogged?
Modern mail-servers process separate incoming messages in parallel, so a slight pause in processing of one message will have no effect on another.

Querying your DNSBL servers will use a lot of bandwidth, won't it?
DNS is inherently very efficient, using minimal amounts of bandwidth. Using a Spamhaus DNSBL will use far less bandwidth than having to accept every spam and virus email sent to your system. By rejecting them at the SMTP connection, no further data is sent thereby substantially reducing overall bandwidth. DNS caching by your local resolver means that not every query counts towards outside bandwidth use. (And, on the hardware side, your server(s) won't have to do expensive post-delivery filtering and storage of spam messages.)

How solid is the Spamhaus DNSBL server network?
The Spamhaus DNSBL network currently consists of over 120 servers distributed throughout the world and located mainly in major collocation facilities with dedicated multi-megabit connections and with extensive network peering at each facility. The Spamhaus DNSBL network has been designed with complete redundancy and has never been "off the air" or unavailable since its inception in 2001.

Missing 'A' record for sbl/xbl/pbl/dbl/
"I can't trace, I get 'host not found'..."
"All your DNSBLs are down! I can't resolve any of them to an IP!"

Occasionally users inform us that our DNSBLs must be down or that our DNS may be broken because: "I can't resolve to an IP address" or "I can't ping".

Spamhaus DNSBL zones (,,,, & are not hosts or servers, they are DNS zones. DNS zones map specially-formatted queries (such as '') to DNSBL servers which in turn provide authoritative answers to the DNSBL queries. DNS zones do not normally have 'A' records, therefore you can not resolve a DNS zone to an IP address or to a specific machine.

Trying to resolve or ping a DNS zone is like trying to resolve or ping '.com' (which is also a DNS zone) and of course '.com' doesn't have an 'A' record (so you can not resolve '.com' to an IP address either).

Each of Spamhaus's DNSBL zones is load-balanced into sub-zones, served by over 120 DNSBL servers ('mirrors') located around the world. Our DNSBL server IP addresses change frequently as servers are added or removed from the pool, but the DNS zone always knows where to find them.

Never set your anti-spam filter to query the IP addresses of Spamhaus zone DNS servers, as these can change at any time. For IP address checks, always query only the advertized zones themselves: SBL, XBL, PBL, or preferably the combined Zen zone. For domains, use the DBL zone.

How can I use the Spamhaus zones (ZEN or SBL, XBL, PBL) if I don't run my own mail server?
DNS Blocking Lists are designed to work most effectively during SMTP "realtime" transmission, enabling spam to be rejected early in the transaction before it burdens servers, disks and mail queues. Because the SMTP transmission is terminated before the spam can be transmitted, this also results in a "Delivery Status Notification" (error message) which notifies the sender's server of the rejection and provides a fail-safe in case of errors. Ideally you should ask your ISP or IT admin to use Spamhaus Zen on their mail server.

But, even if your mail isn't filtered at the server, you can still use DNSBLs, including SBL and XBL, with your Windows POP3 mail client (like Outlook, OE, Eudora, T-bird, etc.). Options include:

For Windows
- SpamPal Now: (freeware)
- MailWasher (free and Pro versions; be sure to disable bounces!)
- jwSpamSpy (German)
- K9 (freeware - Bayesian filtering based, but has a neat "Advanced feature" to use SBL/XBL as part of the Bayesian statistics)
- SmarterTools SmarterMail (free and pay versions; includes SpamAssassin ability)
- Spamihilator (with DNSBL Add-on)

For Mac
- Junkmatcher integrates with OS X
- has links to more spam filtering tools for Mac mail clients, and some for linux.

Setting up any one of those to work in conjunction with your mail client is fairly easy; they have can do it! But do not configure any such software to "bounce" spam - such backscatter invariably ends up sending your spam to an innocent third party, as most "From" addresses are forged. A word of caution: the zone may work better for client-level filters than, as explained in the PBL FAQ.

Advanced users with access to procmail on a shell server may wish to investigate the highly effective SpamBouncer, which supports Spamhaus lists, and optionally other DNSBLs.

Are there any other DNSBL uses that could help?
Using the data in the SBL and XBL portions of our zones can be used to prevent blog and guestbook spam and abuse. Also, some Apache webserver plugins like mod_spamhaus and this Squid DNSBL redirector can be used to ban blocklisted visitors to ones website.

Note that reading the FAQ on the XBL is a must before trying these techniques.

Can I use the Spamhaus DNSBL on my web server or other applications?

You can query the SBL and XBL to prevent things such as blog-comment and guestbook spamming, click-fraud, and automated email address harvesting. You do this by programming your application(s) to query our DNS servers to determine whether a specific IP address is on one of our blocklists. You can use such queries to stop posts from users who use IP addresses on the SBL or XBL to connect to your web site, or to block comment and guestbook posts that contain URIs hosted on IP addresses listed in the SBL or XBL.

You can also search comment and guestbook posts for URIs that contain domains found in our domain blocklist, the DBL. Consult the Spamhaus FAQ on the DBL for more information on what the DBL is and how it works.

There are open-sourced code bases available in Perl and PHP for performing DNS queries. You can find these by searching the Web. Three useful web sites that have code to perform DNS lookups are on, The Code Cave and MetaCPAN.

Some PHP code to check if ones server is listed can be found here, the website is in Japanese and called "Spamhaus チェッカー".

If you prefer to brew your own code, below is the information you will need:

  • ZONE =
  • QUERY SYNTAX = <REVIP>, where "<REVIP>" is the IP you are querying, reversed.
  • For example, if you want to check, you would query


Whenever possible, we encourage applications to query and then parse the return code(s) to determine whether to block an IP. This prevents unnecessary queries and speeds processing on your application. If your application cannot parse return codes, you can query to determine whether an IP address is on the SBL, and to determine whether an IP address is on the XBL. Either of these zones returns if the IP address is on that blocklist.

WARNING! Do not block users using IP addresses listed on the PBL from accessing Web-based applications. The PBL is not a list of "spamming IP addresses"; treating IP address on it as if they all belong to spammers will result in blocking large numbers of legitimate users. Consult the Spamhaus FAQ on the PBL for more information on what the PBL is and how it works.

© 1998-2018 The Spamhaus Project Ltd. All rights reserved.
Legal  |  Privacy