Blacklist / RBL

Three common causes: a compromised account or script on your server is sending spam, you're running an open relay or open proxy, or you inherited a freshly allocated IP with a bad history. The listing page for each list explains its reason; fix the cause before requesting delisting.

Which list matters far more than how many. Spamhaus ZEN, Barracuda and SpamCop are used in production by large providers — a single listing there hurts delivery. Obscure aggressive lists are barely consulted and mean little on their own.

Fix the cause first (close the compromised account, shut the relay, rate-limit outbound). Then use that list's own delisting form. Requests made without fixing the cause usually end in a re-listing and longer cooldowns.

Each IP costs dozens of DNS queries, so a /24 is already 2000+ lookups. Larger blocks would burden the blocklists' infrastructure and burn your query budget. Scan wider ranges in pieces.

For the lists queried, yes — but not every list in the world is queried. Some lists (notably Spamhaus) refuse queries from public resolvers; when that happens the result is reported as an error, never as clean.

Yes. A domain is resolved to its A record first and that IP is queried. URI/domain-based lists (SURBL, URIBL) work differently and need a separate check; this tool focuses on IP-based lists.

Ramp outbound volume gradually, use double opt-in lists, purge bounces, include a working unsubscribe link in every message, and never allow unauthenticated sending through your server.

You inherited the IP's history. Cloud providers recycle addresses; if the previous tenant sent spam, the listing stays with the IP. Saying so on the delisting form usually resolves it quickly.

It varies by list — some propagate in minutes, others in hours. The real delay is in receiving servers' own caches; delivery can take a day to recover.

Over forty DNSBLs, all in parallel for a single IP. CIDR scans query only the most widely used core lists to keep the query count bounded.