The acronym DNSBL stands for Domain Name System Block List. Understanding DNSBL Filtering explains the concept in words and diagrams.

DNSBLs list IP addresses or, in some cases, domain names. The listed IP addresses or domains have been observed sending spam, hosting the web sites of spammers, or providing other services to spammers (collectively called spam support services), or have otherwise met the publisher's policy for inclusion in that list. The Spamhaus Policy Blocklist (PBL) lists IPs that the ISP does not or should not allow to send email directly to other SMTP servers, but which should send email only via the ISP's designated outgoing SMTP servers. Some DNSBLs have other listing criteria, such as geographic lists of IP addresses by country, or even data beyond IP or domain. Those DNSBLs may be used for a variety of purposes.

DNSBLs are used by companies, ISPs, and even individual email applications to help determine whether an email is likely to be spam, and if it is to prevent that email from being delivered to the recipient. Usually a company or ISP's SMTP server checks the DNSBL when an email is received, and refused that email if it is coming from a listed IP address or if it contains a URL that is hosted on a listed IP address.

DNSBLs are sometimes called RBLs (Realtime Blackhole Lists) after MAPS, the granddaddy of all DNSBLs. They also are called blocklists, blacklists, zones or simply BLs.

IMPORTANT: A DNSBL cannot stop anyone from sending mail. It only prevents delivery at the receiving end when the receiver specifically configures his mail server or mail software to consult it. DNSBLs are strictly defensive tools; they cannot be used to launch denial-of-service (DOS) attacks or to do any offensive damage.

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 zen.spamhaus.org, 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 zen.spamhaus.org. 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.

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.

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 (127.0.0.2) and then, (b) known to be not listed (127.0.0.1). '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] 2.0.0.127.zen.spamhaus.org
127.0.0.10
127.0.0.4
127.0.0.2
$
$ dig +short @[DNS.server] 1.0.0.127.zen.spamhaus.org
Host 1.0.0.127.zen.spamhaus.org 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 2.0.0.127.zen.spamhaus.org [DNS.server]" provides similar results.

In Windows, try "C:\>nslookup 2.0.0.127.zen.spamhaus.org".

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

$ dig +short TXT 2.0.0.127.zen.spamhaus.org @[DNS.server]
"http://www.spamhaus.org/sbl/query/SBL233"
"http://www.spamhaus.org/query/bl?ip=127.0.0.2"

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".

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 'spamhous.org' or 'spamhouse.com', 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 advertizing 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. For example, USA ISP, Cox Communication has been doing this in some areas and points people to a webpage like this one. As Spamhaus' "not listed in our zone" replies are the same as a webpage not found reply, users behind this sort of DNS monetization will always see an IP address returned rather than the correct NXDOMAIN DNS answer. If this is the issue, contact your ISP to see if you can opt out. Cox Communication has an informational page with opt-out instructions. Or, for best results, set up your own DNS resolver.

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.

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 or large cloud/outsourced public DNS servers, such as Level3's or Verizon's, to resolve your DNSBL requests, in most cases you will receive a "not listed" (NXDOMAIN) reply from Spamhaus' public DNSBL servers. Please use your own DNS servers when doing DNSBL queries to Spamhaus.

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 www.spamhaus.org/lookup. 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:
         http://www.dnsbl.com/ (general DNSBL info)
         http://shopping.declude.com/Articles.asp?ID=97
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.

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.

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. Two useful web sites that have code to perform DNS lookups are on PHP.net and The Code Cave.

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

• ZONE = zen.spamhaus.org
• PROTOCOL & PORT = UDP/53
• QUERY SYNTAX = <REVIP>.zen.spamhaus.org, where "<REVIP>" is the IP you are querying, reversed.

For example, if you want to check 192.168.25.1, you would query 1.25.168.192.zen.spamhaus.org.

• RESPONSE CODES
• IP NOT FOUND = (NXDOMAIN)
• DNS SERVER ERROR = (SERVFAIL) (These are quite rare.)
• IP FOUND = See the Spamhaus DNS Return-Codes list.

Whenever possible, we encourage applications to query zen.spamhaus.org 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 sbl.spamhaus.org to determine whether an IP address is on the SBL, and xbl.spamhaus.org to determine whether an IP address is on the XBL. Either of these zones returns 127.0.0.2 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.