Email Blacklist Check

A DNS-based blocklist (DNSBL, also called an RBL after the original Realtime Blackhole List from 1997) is a list of IP addresses published as a DNS zone. Instead of downloading the whole list, a mail server asks the zone about one address at a time, using the same DNS query it would use for any hostname. That makes the check fast enough to run on every inbound connection before the server has read a single line of the message.

The query name is the IP address with its octets reversed, followed by the zone. To check 203.0.113.5 against Spamhaus ZEN, the mail server asks for an A record at 5.113.0.203.zen.spamhaus.org. The reversal mirrors the in-addr.arpa layout of reverse DNS, so that a whole network can be listed with one wildcard entry. If the name resolves, the address is listed, and the returned address (always in 127.0.0.0/8) says why: Spamhaus returns 127.0.0.2 for SBL, 127.0.0.4 for XBL and 127.0.0.10 or 11 for PBL. If the name does not exist (NXDOMAIN), the address is clean.

Our blacklist check sends that query to seven zones in parallel from our own resolver and reports the result, the return code and the response time for each. When you give it a domain, it resolves the domain to its IPv4 and IPv6 addresses (up to eight) and checks every one. IPv6 addresses are checked against the lists that publish IPv6 data, which today means Spamhaus ZEN.

Reverse the octets of the IP address, append the zone of the list and query the name with dig. An answer in 127.0.0.0/8 means the address is listed, and NXDOMAIN means it is clean. The example uses 8.8.8.8, which reads the same in both directions, so for 203.0.113.5 the name would be 5.113.0.203.zen.spamhaus.org. Repeat the query for each list you care about, or let the DNSX API run all of them at once.

dig 8.8.8.8.zen.spamhaus.org +short
dig 5.113.0.203.zen.spamhaus.org +short
dig 5.113.0.203.bl.spamcop.net +short

What matters is how many receiving servers consult a list. A listing on one nobody queries costs you nothing.

Microsoft, Google and Yahoo do not publish their internal reputation systems as DNSBLs, so a clean result on every public list does not guarantee inbox placement. It does rule out the most common cause of hard bounces.

Because those two levels list networks rather than addresses. Level 2 lists an entire allocation once a number of addresses inside it have hit UCEPROTECT's traps, and Level 3 lists a whole autonomous system once the proportion of listed addresses crosses a threshold. Your address is included because of what your neighbours did. Cloud provider ranges are on Level 3 more or less permanently.

You cannot delist yourself from Level 2 or 3, only the network owner can, and the listing expires on its own after seven days without new trap hits. UCEPROTECT offers immediate removal for a fee, which the wider anti-spam community treats as a reason to distrust the list, and few receivers act on these levels. If Level 1 is clean and Spamhaus is clean, a Level 2 or 3 listing is almost never the cause of a delivery problem.

1. Find the cause. A listing almost always follows real spam from the address: a compromised account, a web form abused for relaying, malware on a machine behind the NAT, or a mailing list sending to addresses that no longer exist. Check the mail logs for the days before the listing and look for volume you did not expect.
2. Stop it. Lists that see continued spam relist within hours, and repeated listings take longer to clear.
3. Check the basics. Confirm the address has a PTR record that matches the mail server hostname, that SPF and DKIM pass, and that the server is not an open relay. Our SMTP test and reverse DNS lookup cover those.
4. Request removal at the list. Each row in the result links to the operator's lookup page, which shows the reason for the listing and offers the removal form. Spamhaus explains the exact category and what it needs to see. SpamCop and PSBL expire automatically. Barracuda asks for a short form.
5. Wait, then re-check. Removal takes anywhere from minutes to a day. Run the check again rather than assuming.

No. The Policy Block List is a list of address ranges whose owners have said that no mail server should be sending directly from them: residential broadband, mobile networks, dynamic pools and similar. It is included in ZEN, so a query against ZEN returns a hit for these ranges, but the reason code is 127.0.0.10 or 127.0.0.11 rather than the SBL or XBL codes.

If you are running a mail server on a home or small business connection and see a PBL listing, the answer is to relay outbound mail through your ISP's SMTP server or a transactional mail provider, or to move the server to an address that is meant for it. If the address is a static one that your provider assigned for servers and it is still on the PBL, Spamhaus lets the address owner remove it through its website, after confirming the address is static and has a matching PTR record.