Skip to main content
Download

Check an IP against the DNSBLs that actually block your mail

Reverse the octets, query the zone, read the 127.0.0.x code, across 8 DNSBL zones on the Mac, 10 on iPhone and iPad.

By Lucas Russo, developer of SSHive · Updated

Download SSHive FreeAll network tools
Also on iPhone and iPad
Mail that arrived yesterday is bouncing today. The SMTP log shows a 5.7.1 rejection with a URL buried in it, or worse, nothing at all: the receiving side accepted the message and quietly dropped it. The first question is always the same: is the sending IP on a blocklist, and if so, which one? A DNSBL (a DNS-based blocklist, still widely called an RBL) answers that in one DNS query per zone. There is no API, no login and no scraping involved. You reverse the four octets of the address, append the zone's domain, and ask for an A record. NXDOMAIN means not listed. An answer inside 127.0.0.0/8 means listed, and the low byte tells you which sublist caught you and why. The catch is that the answer is only useful if you query the right zones and understand what each one is saying. There are hundreds of public lists; a handful are actually consulted by the mail servers that matter, and several of the rest are aggressive, stale, or shut down entirely. A tool that reports "listed on 3 of 100 lists" without naming the three is worse than no answer: it sends you filling in removal forms for zones nobody queries while the one listing that is genuinely blocking your mail stays in place. SSHive runs the check itself, on whatever device you have with you. On macOS it queries 8 zones in parallel and pulls the TXT record on every hit, so you get the operator's own reason string and removal pointer next to the return code. On iPhone and iPad it queries 10 zones and shows the raw 127.0.0.x code for each. It is IPv4 only, it runs unchanged inside the sandboxed Mac App Store build, and it is free on every platform: no account, no ads, and no server of ours anywhere in the path.

What SSHive does

8 zones on the Mac, 10 on iPhone and iPad, all named

macOS queries zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net, dnsbl.sorbs.net, bl.mailspike.net, dnsbl-1.uceprotect.net, psbl.surriel.com and all.s5h.net. iPhone and iPad query the same set minus psbl.surriel.com, plus dnsbl-2.uceprotect.net, ix.dnsbl.manitu.net and dnsbl.dronebl.org, ten in total. The lists differ by platform, and every zone is shown by name.

The reason string, not just a red flag

On macOS, every hit triggers a second TXT query against the same name, so the Reason column shows the operator's own explanation, usually including the URL of its removal page. When no TXT is published, the raw 127.0.0.x return code is shown instead. On iPhone and iPad the TXT record is not fetched: the return code alone is displayed under each listed zone.

IP or hostname, resolved for you

The field accepts a dotted-quad IPv4 or a hostname. A hostname is resolved to its first A record before any zone is queried, so you can paste the name straight out of a bounce message. Bear in mind that resolving a domain gives you its web address, not its mail exchangers; for a mail domain, run MX Lookup instead.

Works inside the App Sandbox

A DNSBL query is an ordinary A-record lookup through the system resolver: no raw sockets, no privileged ports, no spawned binaries. That is why the blacklist check runs unchanged in the sandboxed Mac App Store build, and is fully functional on iPhone and iPad, as is every other tool in the panel.

Every MX server checked automatically

On the Mac, MX Lookup runs the same DNSBL engine on its own results: each mail exchanger is resolved, reverse-resolved, and its first IPv4 address checked against all 8 zones, with a Not listed or Blacklisted pill per row. Only the first IPv4 per exchanger is checked, and IPv6-only mail servers are not covered.

Free, on every platform, with no account

The whole network-tools suite is free on Mac, iPhone and iPad. There is no Pro gate on the blacklist check, no ad interstitial before a result, and no sign-up. SSHive Pro is a separate one-time purchase (about $12.99, a Universal Purchase across Mac, iPhone and iPad) that unlocks other features entirely, never these.

How to do it, step by step

  1. 1

    Open Network Tools

    On the Mac, click the network icon in the sidebar, or the Network Tools pill on the Welcome screen: either one opens a Network Tools tab. On iPhone, tap Tools in the bottom tab bar. On iPad, select Network tools in the split-view sidebar.

  2. 2

    Find the DNSBL Check card

    On the Mac, DNSBL Check is the second card of the Lookup and reputation section, between DNS Lookup and MX Lookup. On iPhone and iPad, Blacklist Check is the second row of the Email & IP section, directly under MX Lookup.

  3. 3

    Enter an IPv4 address or a hostname

    Type a dotted quad such as 203.0.113.25, or a hostname (the placeholder on the Mac reads "e.g. 1.2.3.4 or domain.com"). A hostname is resolved to its first A record before the zones are queried. Press Check blacklists. All zones go out in parallel, so a full run takes roughly as long as the slowest single DNS lookup.

  4. 4

    Read the summary, then the per-zone rows

    On the Mac, a summary pill reads "<n>/8 blacklists", green at zero and red otherwise, above a three-column table of Zone, Status and Reason. iPhone and iPad show a green Clean shield or a red count of lists, then a Listed section, a section for the zones that gave no usable answer, and a Clean section; each listed row carries its raw 127.0.0.x return code.

  5. 5

    Follow the reason string to the right removal form

    On macOS the Reason column carries the zone's TXT record, which usually contains the operator's explanation and the address of its removal page. Note the exact zone name, fix the underlying cause first, then go to that operator's own form. Never use a bulk service promising removal from a hundred lists at once.

Reading the result: which listings actually block mail

Not all rows carry the same weight, and treating them as equal is the most common mistake. zen.spamhaus.org is the one that decides whether your mail arrives. It is a composite zone, and the return code says which component fired. 127.0.0.2 and 127.0.0.3 are SBL and CSS: a known spam source or a snowshoe range. 127.0.0.4 through 127.0.0.7 are XBL: a compromised machine emitting through a proxy, bot or worm, which normally means something on your network is infected rather than misconfigured. 127.0.0.9 is DROP, for hijacked or criminal netblocks. 127.0.0.10 and 127.0.0.11 are PBL, and PBL is not an accusation of spamming at all: it states that the address sits in dynamic or end-user space that the network operator itself declared should not deliver directly to MX. A home connection or a fresh cloud instance hitting PBL needs to relay through a smarthost, not file an appeal. Anything in 127.255.255.0/24 is not a real listing. It is the zone refusing the query, usually because it arrived via a large public resolver such as 8.8.8.8 or 1.1.1.1, and how that shows up depends on the device. The Mac counts any answer beginning with 127. as listed, so on a public resolver Spamhaus can come back as a red Listed row whose return code is 127.255.255.254: a refused query, not a blocklisting, so read the code, not the colour. The Mac also records a zone that answers with a DNS error as clean, so a Clean row there can mean no answer at all. iPhone and iPad keep both cases apart: a 127.255.255.x code or a failed query lands in a separate group of zones that gave no usable answer, counted neither as listed nor as clean. On either device, re-run the check on a network using its own or its ISP's recursive resolver before trusting the result. Below Spamhaus, b.barracudacentral.org and bl.spamcop.net are widely consulted and worth acting on. bl.mailspike.net is a reputation score, not a binary verdict. psbl.surriel.com and ix.dnsbl.manitu.net are spamtrap-driven and expire on their own, often within hours. dnsbl-1.uceprotect.net lists a single IP; dnsbl-2.uceprotect.net, queried only on iPhone and iPad, lists a whole allocation because a neighbour spammed, so a lone level-2 hit beside otherwise clean rows is usually noise. dnsbl.sorbs.net is a special case: its operator shut the service down in 2024, so that row tells you nothing about your reputation, whatever it shows. Do not read it as a clean bill of health. Finally, a full sweep of clean rows is not a delivery guarantee. Gmail, Outlook.com and Yahoo run internal reputation systems that no public DNSBL exposes.

Frequently asked questions

Is the blacklist check available in the Mac App Store version of SSHive?+
Yes, in full: all the zones, the TXT reason lookup, no sandbox guard. A DNSBL query is a plain A-record lookup through the system resolver, so it needs none of the privileges Apple's sandbox withholds, and nor, as it turns out, do ping and traceroute, which send real ICMP from the App Store build through a datagram socket.
Why does my iPhone check 10 lists and my Mac only 8?+
The two codebases ship different zone sets. macOS checks 8 zones; iPhone and iPad check 10: the same list minus psbl.surriel.com, plus dnsbl-2.uceprotect.net, ix.dnsbl.manitu.net and dnsbl.dronebl.org. So a result can legitimately differ between your Mac and your phone. The most common case is a UCEPROTECT level 2 hit visible only on mobile, which reflects your allocation's neighbours rather than your own IP.
Can I check an IPv6 address?+
No. The tool is IPv4 only on every platform: anything that is not a dotted quad (or a hostname resolving to one) is rejected. IPv6 blocklisting requires a 32-nibble ip6.arpa-style encoding, and real coverage across the major zones remains thin, so SSHive declines the query rather than return a result it cannot stand behind. If your MTA is dual-stacked, check its IPv4 address and use provider postmaster tooling for the v6 side.
I'm listed on Spamhaus PBL. Did my server send spam?+
Almost certainly not. PBL (return codes 127.0.0.10 and 127.0.0.11 in the zen composite) is a policy list, not an abuse list. It records that the address sits in a range the network operator itself declared as dynamic or end-user space that should not talk directly to remote MX servers. Typical triggers are a residential connection or a cloud IP whose provider has not opened port 25. The fix is to relay through your provider's smarthost, or ask the operator to declassify the range, not to file an abuse appeal.
Every zone says Clean but my mail still bounces at Outlook. Why?+
Two reasons, and both are worth ruling out. First, the large mailbox providers maintain private reputation systems that no public DNSBL exposes; a Microsoft or Google block is theirs alone and is handled through their own postmaster channels, not a delisting form. Second, the zone may not have answered the question you think it did. When a blocklist refuses a query (most do this for traffic arriving via 8.8.8.8 or 1.1.1.1), it usually replies with a code in 127.255.255.0/24. The Mac shows that as a red Listed row, so check the return code before you believe a hit; and when a zone replies with a DNS error instead, the Mac records it as clean, so a Clean row there can be no answer at all. iPhone and iPad set both cases apart as zones that gave no usable answer. Re-test from a network using its own recursive resolver before concluding anything.
Can I check a domain instead of an IP address?+
You can type a hostname, and it is resolved to its first A record before the zones are queried. But be clear about what that tests: for example.com you are checking the IP behind the website, which is frequently not the machine that sends the mail. To check the machines that actually deliver your mail, use MX Lookup: on macOS it resolves every mail exchanger and runs the same 8-zone DNSBL check on the first IPv4 of each one automatically.
Do I need SSHive Pro to run a blacklist check?+
No. The entire network-tools suite (blacklist check, MX lookup, DNS lookup, whois, ping and traceroute) is free on Mac, iPhone and iPad, with no account and no ads. SSHive Pro is an optional one-time purchase (about $12.99), a Universal Purchase across Mac, iPhone and iPad, that unlocks unrelated features. There is no subscription, and none of these diagnostics is behind a paywall on any platform.

How a DNSBL query works, and why delisting order matters

A DNSBL is a database published entirely through DNS, which is exactly why querying one needs no privilege on any platform SSHive ships on. To test 203.0.113.25 against zen.spamhaus.org, the client reverses the four octets and asks for an A record at 25.113.0.203.zen.spamhaus.org. The reversal is not cosmetic. DNS delegates hierarchically from right to left, so writing the address backwards lets a zone operator delegate by /8, /16 or /24 exactly the way in-addr.arpa does for reverse lookups. NXDOMAIN means not listed. Any answer inside 127.0.0.0/8 means listed, with the low bytes encoding which sublist matched. A TXT record at the same name, where the operator publishes one, carries the human-readable reason and the removal URL. SSHive implements this twice. On macOS the main process fires all eight zone queries in parallel through Node's c-ares resolver, each caught individually so a dead or rate-limited zone cannot fail the whole run; on a hit it issues a second TXT query against the same name for the reason string. On iPhone and iPad the Swift implementation fans the ten zones out across a throwing task group on a utility queue, one getaddrinfo pinned to AF_INET per zone, then sorts the results: listed first, then the zones that gave no usable answer, then alphabetically. Both accept a literal dotted quad or a hostname, resolving the hostname to its first A record before touching any zone. Because all of that is an ordinary A-record lookup through the system resolver, there are no raw sockets, no privileged ports and no spawned binaries involved, so the check runs unmodified inside the App Sandbox. The same is true of every tool in this panel, ping and traceroute included: they send real ICMP from a datagram socket that needs no privileges, so there is no platform here where a diagnostic answers less than it does elsewhere. It also means every query leaves your device for the zone's nameservers directly, through whatever resolver your network assigned: there is no SSHive backend and no third-party web API in the path. Two limits are deliberate. The tool is IPv4 only, and it checks IP-based zones only: no URIBL or SURBL domain-based lists, no listing timestamps, no clickable removal links. Which brings you to delisting, where the order of operations decides everything. Fix the cause before you submit anything: removing a listing while the source is still active gets you relisted, usually with a longer penalty. The usual causes, roughly by frequency: one compromised SMTP AUTH account (look for a single username authenticating from many source IPs), an abused web contact form, an open relay, a malware-infected workstation sharing your public IP behind NAT, and a legitimate mailing list gone stale enough to hit spamtraps. Then confirm the basics: forward-confirming reverse DNS that matches your HELO name, plus SPF, DKIM and DMARC. Only then use each operator's own removal page. Spamhaus, Barracuda and SpamCop all run self-service forms; PSBL, NiX Spam and UCEPROTECT level 1 expire on their own once the traffic stops. Skip any service offering to remove you from a hundred lists at once, and expect delivery to recover days after the listing itself clears.

Related tools

MX lookup

DNS lookup

Whois