What browser blocklists can and can't do about a phishing site

Our guide to registrar abuse reports covers the layer that can take a domain away. This one covers a layer that's easy to overlook: browser-side blocklists. They work differently from the registrar layer.

A blocklist doesn't take the site down. The phishing site can stay live, with valid DNS and a normal HTTP 200, while the visitor's browser shows a full-page "Deceptive site ahead" warning. That's why this layer matters: it protects visitors without the registrar having to act. This article explains what each layer does and where it falls short. It isn't a filing guide.

The landscape: three layers

Each is run by a different company with its own review process. None of them publishes how long a review takes, and none offers a way to ask for a faster decision.

Google Safe Browsing

Safe Browsing is the list behind the warning screens in most major browsers. A site gets on it when Google's own systems confirm that the page is phishing, so a report is an input to that review, not an order.

Google publishes no turnaround, and we will not invent one. What we have measured is small: in the one case we timed end to end (a .cn site reported on April 25, 2026), three days passed with no visible warning, while a registrar-side channel had the same site offline in about a day. The case study has the table.

Two things stand out from that case and from what we see elsewhere:

• Entries are tied to specific addresses, not whole domains, so an attacker who changes the page address can step outside an existing entry.
• A site that hides from Google's re-check, by refusing scanners or whole countries, may never get a warning at all.

Microsoft SmartScreen

SmartScreen protects Microsoft's own products. Analysts review reports and judge the evidence themselves, and a report they can't verify tends to stall. The warning doesn't appear in browsers outside the Microsoft ecosystem, so it's only part of the picture. Microsoft publishes no timeline for it either.

DNS-level blocklists

These block at the resolver, before the browser even reaches the site. Several filtering resolvers exist, and each draws on its own threat feeds. Coverage depends on which resolver a visitor happens to use, which is why this layer helps most on corporate networks that standardize on one. Turnaround isn't published here either.

Why a report is not the same as a warning

Filing a report doesn't mean a warning appears. Reviews are slow, the outcome isn't guaranteed, and the three layers don't share decisions: a site can be blocked in one and untouched in another. Being on a list also doesn't stop the site from existing. The server stays up, and the operator can move the same kit to a new address.

That is why blocklists are best understood as one layer next to the registrar, which controls the domain, and the host, which controls the server. In our one timed case, the registrar-side channel was the one that actually ended the site.

What OpenBait does

Once a reported site is confirmed as phishing, OpenBait:

1. Captures the page in a headless browser as evidence
2. Submits the URL to the blocklists the major browsers and antivirus vendors draw on
3. Records each submission on the case, with its state, so you can see what was sent and when

What happens to a report from start to finish is on how a report becomes a takedown.

---

Finding a lookalike domain doesn't mean waiting on any one channel, and blocklists are only one of them. They aren't a substitute for action at the registrar or host: in our one timed case, no warning appeared in three days. If you'd rather have us handle this, start free.