Blacklist checks

The blacklist check queries your domain and its resolved IP addresses against 49 sources (DNS-based blacklists plus Google Safe Browsing) in parallel every 6 hours. Spamhaus ZEN, Spamhaus DBL, and Sender Score were removed — they require paid API keys for cloud-hosted queries. Every listing is confirmed with a second query before firing an alert — this eliminates transient DNS false positives. Providers that return an undocumented response code are marked unknown rather than listed. Informational or policy-based responses (dynamic IP, missing PTR record, Tor exit node) are classified as advisory — they appear on the check detail page but do not fire alerts or mark the domain as listed. Blacklist listings block email delivery, trigger browser warnings, and can suppress your site in search results.

What it monitors

The check runs two phases in parallel.

Phase 1 — domain-based lookups query the domain name directly against blacklists that track spam domains, phishing, malware, and botnet command-and-control:

• SURBL, URIBL, 0spam domain, NordSpam domain, ZapBL, Suomispam domain, Woody domain, Swinog URI
• Abusix domain list (when configured)
• Google Safe Browsing API (checks for malware, social engineering, unwanted software, and potentially harmful applications)

Phase 2 — IP-based lookups resolve the domain to up to three IPv4 addresses and query each against IP reputation lists:

• Spam / exploit: SpamCop, PSBL, DroneBL, 0spam IP, Anonmails, Backscatterer, blocklist.de, Mailspike, Spamrats (when configured), Abusix combined (when configured)
• Proxy / abuse: DAN Tor, DAN Tor Exit, IMP Spam, IMP Worm, SPFBL, Truncate, UCEProtect L1
• Reputation: HostKarma, IBM DNSBL, Swinog IP, Suomispam IP, NordSpam IP, and others

In total the check queries 49 sources across both phases — DNS-based blacklists plus Google Safe Browsing (HTTP).

How often it runs

The blacklist check runs every 6 hours (21,600 seconds). A single check result showing any listing immediately fires a blacklist_listed alert — there is no debounce, because a confirmed listing on a major DNSBL requires action now.

Alerts this check produces

Event	Tone	When it fires
blacklist_listed	Failure	One or more sources returned a confirmed listing for the domain or its IPs
blacklist_delisted	Recovery	All previous listings are cleared; domain and IPs are clean across all sources

The alert includes which source(s) listed the domain and the category where available (e.g. "spam source", "phishing domain", "botnet C2").

Advisory vs listed

Some DNSBL response codes are informational — they flag a property of the IP (e.g. "this is a dynamic/residential IP" or "no reverse DNS") rather than confirmed abuse. DomainCare classifies these as advisory so they don't trigger false-positive alerts on clean domains.

Advisory responses come from:

• Spamhaus PBL — dynamic/residential IPs not intended for direct mail delivery
• HostKarma yellowlist/brownlist — mixed or low-reputation senders
• SPFBL — unidentifiable sender or dynamic/residential IP
• SpamRATS — dynamic IP or missing PTR record (confirmed spam stays "listed")
• Abusix — generic or missing reverse DNS
• DAN — Tor exit node (not malicious per se)
• Mailspike — low reputation only
• DroneBL — open resolver
• Cymru bogons — IP in reserved/bogon space
• URIBL greylist — probable but unconfirmed spam
• 0spam — non-RFC-compliant mail server

Advisory results appear in an amber section on the check detail page. They do not fire the blacklist_listed alert and do not affect the domain health score. If you only see advisory results with no red "listed" entries, your domain is clean.

What to do when alerts fire

• Identify the source — the alert details show which DNSBL reported the listing and the category. Google Safe Browsing listings affect browser and search visibility; DNSBL listings primarily affect email deliverability.
• Find and fix the root cause — common causes include a compromised server sending spam, an infected script, or phishing content hosted on the domain.
• Request removal — each DNSBL has its own removal process. Spamhaus has a self-service lookup tool at check.spamhaus.org. Google Safe Browsing removals go through Search Console. Fix the underlying issue before requesting removal — most lists will relist quickly if the problem persists.
• Monitor for re-listing — after delisting, watch the next few 6-hour check cycles. If the blacklist_listed alert fires again quickly, the root cause (compromised account, spam script, etc.) is still active.
• Check for unknown results — sources show unknown when rate-limited, unreachable, returning an undocumented response code, or when a listing could not be confirmed on re-query. These do not fire alerts. The blacklist_listed alert only fires on confirmed listings.

Related

• Email deliverability — broken SPF or DMARC can contribute to spam listings
• Alert reference