Ask how most security products decide whether a website is dangerous, and the answer is almost always the same: they check a list. A list of known-bad URLs, domains, or IP addresses, compiled from threats that have already been reported and analysed. If the site is on the list, it’s blocked. If it isn’t, it’s allowed.
This is the model behind web filters, secure email gateways, browser safe-browsing databases, and DNS-based filtering services. It’s cheap, fast, and genuinely useful against the enormous volume of known threats. But it shares one fundamental weakness: a blocklist can only stop what someone has already seen, reported, and added to the list. Against anything new, it is blind by design.
The window attackers live in
Every blocklist has a gap between when a malicious page goes live and when it finally appears on the list — after it’s been discovered, analysed, and distributed to every tool that relies on the feed. That can take hours or days. Attackers operate entirely inside that window.
The timing is brutal for defenders. The median person clicks a phishing link about 21 seconds after receiving it, [1] while phishing sites are often live for only a few hours before being abandoned. By the time a page is reported and blocklisted, the campaign is frequently over and the attacker has moved to fresh infrastructure. The list updates to block a site that no longer exists.
DNS-based filtering has the same blind spot
DNS filtering is often presented as a different, stronger category of protection. It isn’t fundamentally different — it’s a blocklist applied at the DNS layer. When you visit a site, your device asks a DNS resolver to translate the domain into an IP address; a DNS-filtering service refuses to resolve domains that appear on its block list of known-bad names.
That’s valuable for blocking known malware and command-and-control domains. But it inherits every limitation of the list it depends on:
- It can’t judge a brand-new domain. A domain registered minutes ago, not yet on any feed, resolves normally — the user reaches the phishing page.
- It works at the domain level, not the page level. DNS filtering decides yes/no on a whole domain. It cannot see that one page on an otherwise-legitimate, allowed domain has been turned into a credential-harvesting form.
- It evaluates the name, not the content. DNS resolution happens before the page is ever rendered, so the filter never actually inspects what the page does.
In other words, DNS filtering asks the same question every blocklist asks — “is this name already known to be bad?” — and gets the same wrong answer for anything new.
“Just check the domain age” — and why that fails too
A common refinement is to treat newly registered domains as suspicious. It’s a reasonable signal: a lot of phishing does run on domains registered moments before an attack. But domain age has quietly become one of the most over-trusted signals in security, and attackers exploit that trust directly.
Consider the numbers. One 2025 analysis found that only about 7% of phishing domains are under 30 days old, and that the average age of domains which successfully bypassed Microsoft’s native security and secure email gateways was 3,829 days — more than ten years. [2] If your defence assumes “old domain = safe,” you are trusting exactly the infrastructure that beats the best filters.
There are three ways attackers turn the age signal against you.
1. “Pickled” (strategically aged) domains
Attackers register domains and then deliberately wait — sometimes for years — letting them sit dormant with no malicious activity. The goal is to build a clean record that sails past reputation and age checks. Security researchers call these strategically aged domains, and the data is striking: Palo Alto Networks’ Unit 42 found that strategically aged domains are roughly three times more likely to be malicious than newly registered ones, and that around 22% of aged domains they studied posed some form of danger. [3] In some cases a domain stayed quiet for two years before its DNS traffic suddenly spiked by 165 times as the attack began. The SolarWinds operation famously relied on domains registered years before they were ever used.
A domain bought on the secondary market — registered in, say, 2018 and parked ever since — carries an aged, clean reputation that a fresh registration simply can’t. To a blocklist or an age-based filter, it looks trustworthy. There is nothing to block, because nothing bad has happened on it yet.
2. Compromised legitimate domains
Attackers don’t even need to own a domain. They can break into a legitimate, well-established website and quietly host their phishing page in a subdirectory. The malicious page then inherits the real site’s age, its reputation, and often its valid SSL certificate. [4] Industry datasets attribute a significant share of phishing URLs — on the order of 16% — to compromised legitimate sites rather than attacker-registered domains. [5]
No blocklist will flag the domain, because the domain is genuinely reputable. No age filter will flag it, because the site really is old. No DNS filter will block it, because resolving the domain is the correct behaviour. The threat is a single hidden page on a trusted site — invisible to every list-based control.
3. Trusted platforms and the secondary market
Attackers increasingly host phishing content on trusted file-sharing and cloud platforms whose domains can never be blocklisted wholesale, and buy aged domains through aftermarkets that now function as ready-made “infrastructure suppliers” for fraud. [4] In each case the economics are simple: a small premium for clean, aged, or trusted infrastructure pays for itself by defeating detection.
The common thread
Newly registered domains, pickled domains, compromised legitimate sites, abused trusted platforms — they look completely different, but they defeat protection the same way. Every one of them is designed so that the question a blocklist asks — “have we seen this exact thing be bad before?” — returns “no.” Reputation, age, and DNS lists all answer that same question, so they all share the same blind spot.
What actually works: judge the page, not its reputation
If you can’t rely on whether infrastructure is known to be bad, you have to evaluate whether a page is bad — in real time, by what it actually does. That means analysing the page itself as it loads:
- Visual analysis — does this page look like a login for a brand it has no right to imitate, regardless of the domain’s age or reputation?
- Structural “x-ray” analysis — what do the page’s forms, scripts, and components actually do? Credential-harvesting behaviour shows up in the structure even on a trusted, aged, or compromised domain.
- Per-page, not per-domain — judging each page individually is the only way to catch one malicious page hiding on an otherwise-legitimate site.
This is the approach SafeToOpen takes. Because it inspects each page in the browser as it renders — rather than asking whether the domain is on a list — it can flag a phishing page that is brand new, hosted on a decade-old “pickled” domain, or injected into a compromised legitimate site. The verdict comes from the page’s own behaviour, so a clean reputation is no longer a free pass.
Protection that doesn’t wait for a list
SafeToOpen Browser Security inspects pages in real time and blocks malicious ones — including those on new, aged, or compromised domains that blocklists and DNS filters miss.
How Browser Security works →The takeaway
Blocklists and DNS filtering aren’t useless — they cheaply absorb the huge volume of already-known threats, and they belong in a layered defence. But they cannot, by design, stop what they haven’t already catalogued, and “new” isn’t the only thing they miss: aged domains, pickled domains, and compromised legitimate sites all wear the trusted reputation a list looks for. Closing that gap requires a layer that evaluates each page on its own merits, in real time — judging what a page does, not what its domain’s history says.