A newly registered domain is a name that was created days or weeks ago. Teams treat it with caution because reputation systems learn about bad domains after they are seen, so a fresh name has no history either way. Domain age is a risk signal to weigh, not proof that a site is malicious.
What is the actual gap?
Protective DNS services block lookups for domains they already know are bad. The UK National Cyber Security Centre describes its service as preventing access to domains known to be malicious by not resolving them, using rules built from commercial, internal and open sources, and reviewed so legitimate sites are not caught.
Read that closely. The key word is known. A domain registered this morning cannot have been reported, analysed and added to a list. An attacker who registers a name for one campaign, uses it for a few hours and moves on spends most of its life in that gap.
The same property causes false positives. A small business launching a new site, a product team registering a campaign domain and a vendor moving to a new brand are all new too. Age alone cannot tell them apart from a phishing page.
How do you find out how old a domain is?
The Registration Data Access Protocol, RDAP, is the standard way to query registration data. RFC 9083 defines its JSON responses. Domain, entity and other objects carry an events array, and one of the defined event actions is registration with a date.
That gives you a machine-readable creation date without parsing free-text WHOIS output. A policy engine can fetch it, compare it with today's date and cache the result. Not every registry returns the same fields, and privacy rules hide some contact data, so treat a missing date as unknown rather than as new or old.
A constructed example
A finance team receives an invoice email linking to a domain registered four days ago. Their mail gateway looks it up, sees a registration event from four days back, and applies a rule: links to domains younger than 30 days open only after a warning page, and attachments from those senders are held for review.
Two things happen over the week. The warning page stops a user from entering credentials on a lookalike login page. And it also flags a genuine supplier that has just rebranded, which the team clears with a phone call and adds to an allow list. Both outcomes are the policy working as designed.
What are the options?
Teams usually pick one of three postures.
Block. Simple and strict. It suits high-risk environments such as payment systems or administrator workstations, where the cost of an exception is small.
Warn or isolate. Show an interstitial page, or open the link in a remote browser, and let the person continue after reading. This keeps work moving and puts a pause in front of credential entry.
Observe. Log every request to a young domain and review them. This is where to start if you do not yet know how many legitimate lookups you would break.
A reasonable threshold is a number you choose and revisit, such as 14 or 30 days. No authority sets one for you, so measure your own traffic before settling on it.
How do you reduce false positives?
Combine age with other signals. A young domain that also has no history of mail, a name close to a brand you use, a certificate issued the same day and a link in an unsolicited message deserves more suspicion than a young domain that a colleague asked for.
Keep an allow list with owners and expiry dates. Review it so exceptions do not become permanent holes.
Give staff a fast way to ask for a domain to be cleared. If the process takes three days, people will find a way around it.
How to check or apply this
- Decide where domain age will be evaluated: DNS resolver, web proxy, mail gateway or all three.
- Pull creation dates through RDAP and cache them, treating missing data as unknown.
- Choose a threshold and a response per risk group: block, warn or log.
- Run in log only mode for two weeks and count what would have been affected.
- Combine age with lookalike matching and unsolicited message context.
- Set an exception process with an owner and an expiry for every allow list entry.
- Review the policy quarterly against what the logs show.
Quick check
Is a young domain always malicious?
No. Many legitimate sites are new. Age is one input to a decision and works best alongside other signals.
Will protective DNS catch brand-new phishing domains?
Not reliably. Services that block known malicious domains need the domain to be identified first, so pair them with age checks and user warnings.
Sources
- NCSC, Protective Domain Name Service (PDNS)
- RFC 9083, JSON Responses for the Registration Data Access Protocol (RDAP)
Last reviewed: 18 October 2026.
