A company’s own client-facing domain ended up on blocklists, reported by its own security team. Every piece of evidence available said “brand,” and nothing said “owner.”
A financial services firm deployed a client-facing tool on a short, memorable domain they had owned for over a year. The page carried their name in the title bar and their logo as the favicon. It was, unambiguously, theirs. Six weeks later it was submitted to blocklists as an impersonation site, and the request came from inside the company.
We are writing this up with the customer and domain removed, because none of the ingredients were exotic. Every one of them is a default that thousands of companies are running right now. And the case does not turn on a missed step. We asked the owner directly whether the domain was theirs, and told them we thought it was benign. It turns on what a vendor should do when the answer comes back wrong.
What happened
The reversal is still in progress. Unwinding a blocklist submission is not the same operation run backwards. It is slower, it involves different people at every provider, and success is not guaranteed at all of them.
The page shouted "brand" and whispered nothing about "owner"
Set the observable evidence for a genuine counterfeit site beside the evidence for this legitimate corporate domain, and read down the columns.
The important row is brand markers sitting directly above ownership markers. This page was not discreet. It announced the company loudly: the browser tab showed the company’s name and its logo, and the markup carried brand strings throughout. What it never did, anywhere a stranger could check, was claim to be operated by that company.
That combination, strong brand claim, zero ownership claim, is not a neutral state. It is the defining signature of impersonation. A phishing kit is built to produce exactly that pattern.
Why domain age proved nothing
The tempting conclusion is that the domain’s age should have cleared it. It should not have, and we should be the last people to argue otherwise, because we have published data that says the opposite.
These numbers come from our own detection data, published in Domain Age Myth: Why Most Phishing Infrastructure Evades Detection.
Aging is a tactic, not an accident. Interisle Consulting’s research documents criminals acquiring domain names months and even years before using them in a campaign, with phishing traced back to registrations as old as 1986. There is an active secondary market in expired and aged domains, bought precisely to inherit the clean reputation a fresh registration cannot have. Sixteen months is an entirely ordinary aging period.
Compromised legitimate sites break the signal completely. A large share of phishing runs on hacked real websites. Vipre’s Q2 2025 data puts compromised sites second among link delivery methods at 30%. The standard pattern is to hide the malicious content in a subdirectory and leave the homepage untouched, because the homepage is usually the only thing analyzed.
Here age is not merely uninformative, it is actively misleading. The domain genuinely is old. It genuinely was legitimate. Its history genuinely is clean. Every trust signal reads green while /secure/login/ harvests credentials.
The base rate cuts both ways. There are hundreds of millions of registered domains, and the overwhelming majority of sixteen-month-old ones are benign, as are the overwhelming majority of five-year-old ones. Age has poor precision in both directions. It is a weak prior, never a verdict.
One honest tension. Aggregate phishing feeds report the opposite skew from ours: Interisle found 81% of phishing domains reported in December 2025 were registered that same year, 47% in the final quarter alone. That is not a contradiction, it is a different population. Bulk feeds capture mass disposable spam campaigns; we measure targeted brand-impersonation infrastructure aimed at specific financial institutions. If someone raises the “most phishing domains are new” statistic, that is the reconciliation, and it does not rescue the argument, because a defender cannot know in advance which population a given domain belongs to.
“It’s sixteen months old” answers a question nobody should be asking. What is it serving, who controls it now, and is it impersonating you? Age answers none of these.”
Three ownership signals that were missing
If age cannot do this work, something has to. The three defaults below each removed an identity signal, and unlike age, each of them is a claim a stranger can actually verify.
A DV certificate proves the connection, not the company. A Domain Validated certificate attests to one fact: whoever requested it could demonstrate control of the domain at that moment. Its subject contains a hostname and nothing else, because DV does not validate an organization. That is fine for encryption and useless for identity.
An Organization Validated certificate carries your legal entity name in the subject, verified by the CA against public records. It is one of very few signals that let an outside analyst confirm ownership without picking up the phone.
Redaction protects individuals. A brand domain is not an individual. WHOIS privacy exists for good reasons, and for a personal domain it is straightforwardly correct. But the field it removes on a corporate domain is Registrant Organization, which for you is not private data. It is your company name, already on your homepage, your filings, and your certificate, if you bought one that carries it.
Publishing an organization name exposes no employee; keep a role address rather than a person’s. What redaction buys against a targeted attacker is close to nothing. They already know who you are, which is why they are imitating you. What it costs is your ability to prove you are you.
An error page at the apex is a wasted asset. The application was deployed on a path. The apex, the bare domain, the thing a person types when they half-remember your URL, the thing every automated system checks first, returned a framework error under a tab showing the company’s own name and logo.
GET / -> 200 404, Route not found!!
To an analyst, a branded domain serving nothing but an error reads as staging infrastructure, or as a kit not yet switched on. To a customer who typed the domain off a business card, it reads as broken. To a search engine, it is a dead root. A redirect to your main site resolves all three, and it is a one-line change.
How to prevent your domain from being blocklisted
A few days, one purchase order
Buy an OV certificate for any domain that faces your customers
One registrar setting
Publish the registrant organization
One line of configuration
Never leave the apex serving an error
One shared document
Make sure whoever answers "is this ours?" can find out
This is the one that actually broke the case. Brand-protection alerts land with your security team, and they are the people who will be asked to confirm ownership — but new domains get launched by digital, marketing and product teams who never touch that queue. The person who answered here did so in good faith and had no way to check. An inventory of owned domains, updated at launch rather than after an incident and reachable by whoever dispositions alerts, is what turns that question into a lookup instead of a recollection.
So what is a brand protection vendor to do?
It would be tidy to file this as a process failure on our side, and we initially wrote it up that way. The framing does not survive contact with what actually happened.
We detected the domain. We assessed it correctly. We told the customer in writing that we did not think it was malicious and recommended they resolve it as such. We asked the owner, through the product, whether the domain was theirs. They answered four days later by overriding us and requesting a takedown.
So the cheap control was in place and was exercised. The question was put to exactly the right organisation, and the answer that came back was wrong, given in good faith by someone who did not have the fact and had no easy way to get it.
We do not think you refuse. A vendor that overrides its customer’s explicit instruction about their own property, on evidence it has itself called inconclusive, has a worse problem than this one. The customer is normally the authority on their own estate, and deferring to them is normally correct. It was simply wrong this time.
Which leaves two things a vendor can actually improve, neither of which is “trust the evidence over the customer.”
Ask with the evidence attached. “Is this domain yours?” invites a snap answer from memory. The same question with the registration record attached invites a check with IT:
| Is this yours? | my-example.co |
| registered | 16 months ago, three-year term |
| registrar | your corporate registrar, all four locks set |
| DNS | your cloud provider's nameservers |
| page | your name in the title, your logo as the favicon |
Nobody reading that answers “not ours” without checking first. This is the honest use for registration data, and the direction matters: it is not evidence that clears a domain in our analysis, the section above is exactly why. It is context that makes the customer’s answer an informed one. The decision was always theirs; the job is to stop asking them to make it blind.
Bound the cost of a wrong answer. Match the action to its reversibility. Monitoring, re-scanning, and watchlisting are cheap and undoable, and should happen immediately on thin evidence with no deliberation. Third-party blocklist submissions and registrar or host abuse reports take weeks to unwind and may never fully unwind. Those are the ones worth a confirmation step, and worth sequencing after the reversible actions rather than alongside them.
Had that ladder been in place here, the wrong answer would have cost a monitoring entry and a rescan instead of a blocklist campaign that is still being undone. The answer would have been exactly as wrong. It would simply have mattered far less.
The four fixes above are what let a stranger answer the ownership question without a phone call at all. Until a domain carries them, the phone call is the control, and the least a vendor can do is make sure the person picking up has something to go on.
Key Takeaways
The damage is difficult to reverse. Blocklist submissions propagate across multiple providers, and removing a domain from blocklists is slower, involves different teams at each provider, and may never fully succeed. In this case, the customer’s own client-facing domain was blocklisted based on the customer’s own incorrect confirmation that the domain was not theirs.
Domain age is a weak signal in both directions. Allure Security’s own detection data shows that 90 percent of confirmed malicious domains targeting financial institutions were more than 90 days old, and 41 percent were more than five years old. Attackers deliberately age domains or purchase aged domains to inherit clean reputations. Compromised legitimate sites, which account for 30 percent of phishing delivery, have pristine age and history by definition.
Three verifiable signals distinguish a company’s own domain from an impersonation: an Organization Validated TLS certificate carrying the legal entity name, a published registrant organization in WHOIS records, and meaningful content or a redirect at the apex. A Domain Validated certificate, redacted WHOIS, and an error page at the root are the defaults that thousands of companies run today, and they are indistinguishable from the setup of a phishing kit.
Purchase an OV certificate with the legal entity name in the subject, publish the registrant organization name while redacting individual contacts, configure the apex to redirect to the main site or serve a branded page, and maintain a shared domain inventory accessible to whoever dispositions brand protection alerts. These four steps let an outside analyst confirm ownership without a phone call.
Sequence actions by reversibility. Monitoring, rescanning, and watchlisting should happen immediately on thin evidence because they are cheap and reversible. Blocklist submissions and abuse reports should follow only after ownership confirmation, because they take weeks to unwind and may never fully reverse. When asking the customer to confirm ownership, attach the registration evidence so the answer is a lookup rather than a recollection.
