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 Safe Browsing — the target URL is submitted to Google's Safe Browsing v4 threatMatches API, which returns any current listings for the URL. This is the same threat list Chrome, Firefox and Safari consume, so a match here means the browser warning is already up (or imminent).
• 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 Safe Browsing 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 Safe Browsing toggle

With the toggle on, CompleteStatus asks Google whether the URL is currently listed 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 configured Safe Browsing API key. If no key is configured (self-hosted installs set GOOGLE_SAFE_BROWSING_KEY), or the API request itself fails, the check degrades gracefully: the Safe Browsing card shows Not checked with the reason, and the result is treated as clean rather than raising a false alarm. A skipped Safe Browsing lookup never fails the check.

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 Safe Browsing finds no threats and no configured blacklist lists the IP. Either a Safe Browsing 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 or Flagged badge and two cards:

• Google Safe Browsing — Clean, Threats found (with the matched threat types), or Not checked with the skip reason.
• 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

Safe Browsing 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.