ThreatPrevent
ThreatPrevent
Cyber Trust Intelligence
← Back to the blog
CTlogsDomainIntelligenceCTI

What actually makes a domain dangerous?

A new registration, a valid certificate, a familiar name: each tells you something about a domain. None tells you everything.

By Kevin McMahon · 13 October 2026

A domain was registered yesterday. It contains the name of a well-known company. It has an encrypted connection and sits on infrastructure used by thousands of other websites.

Is it dangerous?

There is not enough information to say.

It could be a fraudulent login page preparing to steal credentials. It could be an authorised campaign website. It could be a defensive registration that will never serve content.

Now consider a domain registered ten years ago, belonging to an established business, with a long history of legitimate use.

Is it safe?

Its history provides useful context. It does not establish what every page on that domain is doing today.

Assessing a domain means understanding its use, examining the evidence and deciding how strongly that evidence supports a conclusion. Getting this right requires more than counting suspicious characteristics.

Start with the behaviour you are trying to identify

“Dangerous” is a broad label.

A domain might host a fraudulent payment portal, distribute malware, collect stolen credentials or support communications between compromised devices and an attacker. Alternatively, a legitimate website might contain a single compromised page.

These situations differ in both scope and ownership. A business whose website has been compromised may be a victim itself.

ICANN’s guidance explicitly includes the scenario of an established domain with malware on one subpage while the rest of the website remains legitimate. That distinction matters when deciding what to investigate and how broadly to act.

Before assigning a verdict, ask a more precise question:

What harmful activity is this domain associated with, and what evidence establishes that association?

Domain age: useful context with an expiry problem

A recently registered domain has little history to examine. That can justify additional scrutiny, particularly when it suddenly appears in a sensitive interaction.

But every legitimate business, product and campaign begins with a new domain.

Age becomes more useful when combined with context. A domain registered yesterday that resembles your supplier’s name and appears in an unexpected request to change payment arrangements deserves closer inspection. Its age alone does not prove fraud.

Older domains need equal care. The registration date does not establish continuous ownership, continuous control or an unbroken record of legitimate behaviour.

There is also a measurement problem: “newly registered” and “newly observed” are different facts. A monitoring system seeing a domain for the first time establishes when that system encountered it. It does not necessarily establish when the domain was created.

An assessment should preserve that distinction.

Certificates: evidence of control, not good intentions

An HTTPS connection protects data in transit. A standard domain-validated certificate establishes control of the relevant domain through the certificate authority’s validation process.

It does not establish that the website’s business claims are true or that its operator deserves your credentials. Let’s Encrypt describes its certificates as domain-validated and separately directs reports of phishing and malware towards services that investigate those threats.

Certificate records can still contribute useful investigative context. They can reveal names included in certificates and when certificates were issued.

The interpretation needs care. A newly issued certificate does not establish a newly created domain. It could be a routine renewal or part of a hosting change.

The useful question is what the certificate adds to the rest of the evidence.

Hosting and DNS: relationships need context

DNS records connect domain names to services and infrastructure. Examining those connections over time can help identify changes and relationships worth investigating.

Suppose a suspicious domain shares an IP address with a known phishing site.

That sounds significant until you discover the address serves thousands of unrelated customers.

Cloudflare explicitly warns that filtering by resolved IP address can create false positives because malicious and legitimate domains can share addresses.

A shared hosting provider, nameserver or content delivery network is therefore a weak basis for attributing common ownership or malicious intent.

A more specific relationship may carry greater weight: several domains appearing together, deploying closely matching deceptive content and using the same unusual collection endpoint, for example.

Even then, the assessment should explain which connections are meaningful and why. Drawing a line between two domains does not, by itself, establish what that line means.

Impersonation: a familiar name is the beginning of the investigation

A domain that resembles a recognised brand deserves attention, especially when it is being used to request credentials, money or sensitive information.

But name similarity needs interpretation.

An authorised reseller, an independent review website and a fraudulent sign-in page might all reference the same company. The questions are whether the claimed relationship is genuine and whether the interaction is deceptive.

Useful checks include:

  • What relationship does the website claim with the organisation?

  • Can that relationship be corroborated through an established official channel?

  • What is the visitor being asked to provide or do?

  • Where does the interaction send their information?

A copied logo supports a different conclusion when it appears on a clearly labelled review page than when it appears above a password form pretending to be the organisation’s official service.

Observed behaviour can provide stronger evidence

There is a substantial difference between a domain having characteristics associated with abuse and a page being observed carrying out a harmful action.

Consider two findings:

The domain is recent and resembles a financial services brand.

The page impersonates that brand and submits entered credentials to an independently verified attacker-controlled endpoint.

The second finding supports a much stronger conclusion because it identifies the deception and the destination of the data.

That does not mean every assessment requires a complete reconstruction of an attack. It means the strength of the verdict should reflect the strength of the evidence.

Observations also have limits. Seeing no harmful content during one visit establishes what was visible in that session. It does not prove that every URL, visitor or later interaction receives the same content.

More signals do not automatically mean more confidence

Imagine a system finding five warning signs:

  • Recent registration.

  • Recent first observation in DNS.

  • A recently issued certificate.

  • Limited historical traffic.

  • No established reputation.

These may largely describe one underlying circumstance: the domain is new.

Treating them as five independent confirmations risks overstating the evidence.

The same problem applies to threat feeds. If several providers repeat one original report, the number of listings is not necessarily the number of independent observations.

A defensible assessment should distinguish between repetition, related indicators and genuinely independent corroboration.

High confidence comes from the quality and relationship of the evidence. Volume alone cannot provide it.

A verdict needs a scope and a timestamp

A useful finding should make clear whether it concerns an entire domain, a particular hostname or a specific URL.

It should also distinguish between historical activity and current observations.

A domain may have been cleaned after a compromise. An attacker may have moved to different infrastructure. A previously legitimate page may have changed since the last check.

Historical evidence remains useful, but its age and scope affect the action it supports.

For an analyst, a practical assessment should answer:

  • What was observed?
  • Which domain, hostname or URL was involved?
  • When was it observed and last checked?
  • How strong and independent is the evidence?
  • What action does the finding justify?

Users may only need a concise warning. The underlying assessment should still be able to answer these questions.

What this means for ThreatPrevent

At ThreatPrevent, our focus is high-confidence intelligence that helps people make better decisions about the domains, IP addresses and email addresses they encounter.

That focus requires care in both directions. Missing a harmful domain can expose a user to fraud or compromise. Incorrectly labelling legitimate activity can disrupt business and weaken confidence in future warnings.

Our view is that a useful assessment should explain the risk it has identified and respect the limits of its evidence.

A new domain can justify closer attention. A meaningful infrastructure connection can strengthen an investigation. Verified harmful behaviour can support decisive action.

The value of domain intelligence lies in how reliably it connects evidence to a decision.