Check an IP against the DNSBLs that actually block your mail

A DNSBL is a database published entirely through DNS, which is exactly why it is the one diagnostic that behaves identically on every 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 and Windows 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 results listed-first and 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. That matters, because it is not true of every tool here: traceroute needs ICMP raw sockets, so it works on the direct-download macOS DMG and on Windows, is deliberately disabled in the Mac App Store build, and is not a genuine traceroute on iPhone or iPad. The DNSBL check carries no such asterisk. 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.