Reputation and blacklist monitors

A reputation problem is invisible from your own browser and catastrophic for everyone else's. If Google Safe Browsing flags your URL, Chrome, Firefox and Safari all show visitors a full-screen red interstitial — and nearly all of them turn back. If your server's IP lands on a DNS blacklist (DNSBL), receiving mail servers start rejecting your email outright. In both cases the first you'd normally hear of it is a confused customer. A Reputation monitor checks both on a schedule so you hear it from CompleteStatus instead.

Reputation monitors are available on every plan, including Free.

What CompleteStatus checks

On each run, the monitor performs two read-only lookups:

• Google Web Risk — the target URL is checked against Google's lists of unsafe web resources through the Google Web Risk API. This is the same threat data behind the Safe Browsing warnings in Chrome, Firefox and Safari, so a match here means the browser warning is already up (or imminent). CompleteStatus keeps a local copy of the lists (checked for updates every 30 minutes) and checks your URL against it on our servers; only when part of the URL's hash matches a listed entry do we ask Google to confirm, and Google then receives a short hash prefix, never the URL itself.
• IP blacklists (DNSBL) — the target's hostname is resolved to its IPv4 address, and each blacklist zone you configure is queried the standard DNSBL way: the IP's octets are reversed and looked up under the zone (for IP 1.2.3.4 and zone zen.spamhaus.org, the query is 4.3.2.1.zen.spamhaus.org). An answer in the 127.0.0.x range means the IP is listed.

Both are lookups against third-party reputation data — nothing is ever sent to your site itself.

Setting it up

1. Go to /monitors/create and choose the Reputation monitor type.
2. Enter the site's URL (for example https://example.com) as the target.
3. Leave Check Google Web Risk on (it is by default) — see the next section for what it detects.
4. Optionally add IP blacklist (DNSBL) zones with the + Add blacklist button — one zone per row, e.g. zen.spamhaus.org. Leave the list empty to skip DNSBL checks entirely.
5. Tick the ownership attestation and save. A daily interval is typical — reputation data doesn't change minute to minute, and a day is well within the window you need to react.

The Google Web Risk toggle

With the toggle on, CompleteStatus checks whether the URL is currently on Google's lists for any of three threat types:

Any match flags the URL and produces a critical finding naming the threat type.

The lookup uses the platform's Google Web Risk API key. If no key is configured (self-hosted installs set GOOGLE_WEB_RISK_KEY), the local copy of the threat lists has not finished downloading or has fallen out of date, or Google's confirmation request fails, the check degrades gracefully: the Google Web Risk card shows Not checked with the reason, and nothing is flagged. A skipped lookup never fails the check, and it is never reported as clean: if no blacklist gave an answer either, the panel shows Not verified.

Adding DNSBL zones

DNSBLs mainly matter if the target's IP sends mail — mail servers consult them on every incoming connection, and a listing typically means your messages are rejected or spam-foldered. Widely used zones:

Each configured zone is checked independently on every run, and each produces its own Listed / Not listed row in the results. A listing on any zone fails the check and produces a high finding for that list.

Note: DNSBLs are IPv4-based, and the monitor checks the single IPv4 address the target's hostname resolves to at check time. If your site and your outbound mail run on different IPs (common with hosted email), point a separate Reputation monitor at the mail host to cover its IP too.

Pass or fail

A check passes when Google Web Risk finds no threats and no configured blacklist lists the IP. Either a Web Risk match or any DNSBL listing fails the check; after two consecutive failed checks CompleteStatus opens an incident and sends down alerts to the monitor's channels. Because a listing tends to persist until you act, the monitor stays failing — and the incident stays open — until you're delisted, which makes recovery easy to confirm: the next passing check resolves it.

Reading the results panel

Open the monitor from /monitors. The Reputation & blacklists panel shows a Clean, Flagged or Not verified badge and two cards:

• Google Web Risk — Clean, Threats found (with the matched threat types), or Not checked with the skip reason. Results from before September 2026 are labelled Google Safe Browsing, the API we used until then.
• IP blacklists (DNSBL) — one row per configured zone with a Listed / Not listed badge.

Below the cards, findings are listed by severity with a short recommendation each.

When you get flagged

Google Web Risk match: treat it as evidence of a compromise on your site — injected phishing pages, malware, or spam redirects — not a Google mistake. The order of operations matters: find and remove the compromise first, then request a review in Google Search Console; a premature review request just burns days. Our blog post Google Safe Browsing blacklist removal walks through the full cleanup and review process step by step.

DNSBL listing: find out why first — a compromised account sending spam, a misconfigured form or open relay, or simply a shared IP with a bad neighbor. Fix the cause, then request delisting through the list operator's own lookup/removal page (Spamhaus, SpamCop and Barracuda all have one; the listing page usually explains the reason). Requesting removal without fixing the cause gets you relisted quickly.

What this check does not do

The Reputation check queries third-party reputation data only — it never sends requests, payloads or crawlers at your site, and it can't tell you what on your site caused a listing. To catch injected content or defacement directly (often before it triggers a listing), pair it with a content Change monitor, and see Security-posture scans for the hardening baseline that helps prevent the compromise in the first place.

Related guides

• Security-posture scans — header and TLS grading.
• Email authentication monitoring — SPF, DKIM and DMARC, the other half of mail deliverability.
• Getting started — alert channels and rules.
• Why are my emails going to spam? — deliverability triage when a blacklist listing is only part of the story, on the blog.