Join our Newsletter — 33% off our NHI Course
Home› Guides› Newly Registered Domains Guide: Using Domain Age in…
Guide SOC & Detection Engineering

Newly Registered Domains Guide: Using Domain Age in Filtering, Detection and Triage

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 11 November 2026 13 min read
On this page

Most phishing and malware domains are registered by the attacker shortly before use, so the age of a domain is one of the cheapest and strongest signals a defender has, and one of the most often misapplied. Block every young domain and you break new supplier portals, marketing campaigns and software services; ignore domain age and you let through the infrastructure that reputation feeds have not yet seen. This guide explains what "newly registered" and "newly seen" actually mean, where registration data comes from after the move from WHOIS to RDAP, and how to use domain age in DNS and web filtering, email security, SIEM detection and analyst triage. It is written for SOC analysts, detection engineers and the network and email teams who own the filtering policy.

Key takeaways

  • Newly registered is about the registry, newly seen is about traffic. A newly registered domain (NRD) was created or changed owner recently, commonly within 32 days; a newly seen domain was first queried recently by a provider's users. They catch different things.
  • Young domains are heavily skewed towards abuse. Interisle's Phishing Landscape 2025 found 77% of domains used in phishing were maliciously registered, and Unit 42 research found over 70% of NRDs were malicious, suspicious or not safe for work.
  • Age is a signal to combine, not a verdict. Use it to block in high-risk paths, to raise alert scores elsewhere and to prioritise triage, alongside certificates, hosting, lookalike similarity and sender history.
  • RDAP is now the registration data source for gTLDs. ICANN made RDAP the definitive source on 28 January 2025; the creation date is the "registration" event in the RDAP response.
  • Expired and re-registered domains count as new. A lapsed domain still trusted by your allow lists or code is an NRD in someone else's hands, and age checks are one of the few ways to notice.

Newly registered, newly observed and newly seen

Vendors and feeds use similar words for different measurements. Before writing a policy, confirm which one your product or feed implements.

TermWhat it measuresTypical windowData sourceStrengthWeakness
Newly registered domain (NRD)Registration date or ownership change of the registered domainPalo Alto Networks' PAN-DB category uses the last 32 days; feeds also offer 7, 14 or 90 daysZone file differences, RDAP, registry and registrar dataCatches attacker-registered domains before first useWeak for ccTLDs with no public zone data; misses compromised old domains
Newly seen or newly observed domainFirst time the provider saw the name resolve in DNS trafficCisco Umbrella's Newly Seen Domains keeps a domain in the category for 24 hours after first queryPassive DNS and resolver telemetryCovers subdomains and ccTLDs; reflects real useHigh volume; legitimate new hostnames appear constantly
Young certificateRecent first certificate for a nameHours to daysCertificate Transparency logsOften appears before a phishing site goes liveMany legitimate automated certificates
Low-prevalence domainRarely or never visited in your own estateYour baseline period, often 30 daysYour own DNS and proxy logsTuned to your environmentSays nothing about the wider internet

The Unit 42 definition is worth noting: it counts a domain as newly registered if it was registered or changed ownership within 32 days, which it describes as the window in which NRDs are most often detected as malicious. Cisco's documentation stresses that a newly seen domain is simply that, and that many matches are not malicious.

What the evidence says

  • Interisle Phishing Landscape 2025 (May 2024 to April 2025): 1.96 million phishing attacks across more than 1.5 million domain names; 77% of those domains were maliciously registered rather than compromised; nearly 37% were registered in bulk; new gTLDs held 11% of the domain market but 51% of reported phishing domains, and nearly nine in ten phishing domains in new gTLDs were maliciously registered.
  • Unit 42, Palo Alto Networks (published August 2019, data March to May 2019): over 70% of NRDs were malicious, suspicious or not safe for work, against 7.6% of the Alexa top 10,000; about 1.27% of NRDs fell into strictly malicious categories against 0.07% of popular domains. This is a single vendor's research and is now several years old, so treat the exact ratio as indicative.

The two point the same way: attackers prefer fresh, cheap, often bulk-registered domains because reputation systems have no history on them. The base rate also shows why blanket blocking hurts: most NRDs are not strictly malicious, so a block policy must have a quick exception route.

Where to get registration and first-seen data

  • RDAP: ICANN announced that from 28 January 2025 the Registration Data Access Protocol is the definitive source for gTLD registration data and WHOIS was sunset. RFC 9083 (Standards Track, STD 95, which obsoletes RFC 7483) returns an events array in which eventAction "registration" carries the creation date, alongside "last changed", "expiration", "transfer" and "reregistration", with dates in RFC 3339 format. ICANN Lookup (lookup.icann.org) is the manual front end.
  • Zone files: ICANN's Centralized Zone Data Service (CZDS) lets interested parties request zone files from participating gTLD registries. Comparing successive daily files gives you domains that appeared since the last copy. ccTLDs are not in CZDS; you need the registry's own agreement, and many do not offer one.
  • Commercial and community feeds: NRD and newly observed domain lists from DNS security and threat intelligence providers. Check the window, the TLD coverage, how ownership changes are handled and the delivery delay. See the Threat Intelligence Feed Evaluation Guide.
  • Built into controls: URL filtering, protective DNS and secure email gateways often expose NRD or newly seen categories directly. This is the quickest route, at the cost of less control over the window.
  • Your own logs: first-seen and prevalence calculated over DNS and proxy logs. See the DNS Logging and Detection Guide.

Practical constraints: RDAP servers rate-limit and redact contact data, so cache results by registered domain (not by full hostname) and enrich asynchronously rather than on every query. Always reduce a hostname to its registered domain using the Public Suffix List before looking it up, or you will query subdomains that have no registration record.

Using domain age in prevention

Control pointSuggested policyWhyException handling
Protective DNS or URL filtering, high-risk users and serversBlock NRDs within 32 daysServers and privileged users rarely need brand-new domains; Palo Alto lists block as best practice for the category, with alert as the defaultChange-controlled allow list per registered domain
Protective DNS or URL filtering, general usersWarn page or isolate in remote browser; block where an NRD also matches a lookalike or a risky categoryKeeps business working while adding friction where phishing landsUser can proceed after warning; logged
Email gatewayRaise spam or phishing score for sender and link domains under 30 days; quarantine when combined with failed DMARC alignment or first-time senderFresh sender domains have no reputation; combining signals cuts false positivesSupplier onboarding process registers new partner domains
Newly seen domains categoryAudit only, then alertCisco recommends starting in audit mode because many matches are legitimateReview in reporting before any block
Servers, build agents and OT networksDefault-deny egress with explicit allow lists, which makes NRD blocking redundantAllow listing is stronger than age heuristics where it is feasibleAllow list review on change

For DNS-layer enforcement and bypass control, see the Protective DNS Guide and the Secure Web Gateway and Web Filtering Guide. For sender authentication signals to pair with age, see the DMARC, SPF and DKIM Guide.

Using domain age in detection and triage

Detection ideas

  • Endpoint or server resolving an NRD: alert when a server, domain controller or build agent resolves a domain registered in the last 30 days. Expected volume is low and the signal is strong.
  • Credential submission to a young domain: join proxy POST requests or browser credential events with domain age. A login form on a domain days old is a phishing indicator worth high priority.
  • Click from email to NRD: correlate URL clicks from mail with domain age and with whether the domain resembles your brand or suppliers. See the Domain Portfolio and Lookalike Domain Management Guide.
  • Periodic queries to a young domain: regular callbacks to a recently registered domain combine two weak signals into a strong one. See the Beaconing and C2 Detection Guide.
  • Newly registered lookalikes of your own brand: monitor NRD feeds and Certificate Transparency for permutations of your domains. See the Certificate Transparency Monitoring Guide for Web Teams.

Triage questions for a young domain

  1. When was it registered, and does RDAP show a recent "reregistration" or "transfer" event?
  2. Does the name resemble your organisation, a supplier or a SaaS provider you use?
  3. Which registrar, TLD and name servers does it use, and were sibling domains registered at the same time (a bulk set)?
  4. Does it have MX records, a certificate, or a login page?
  5. Who in your estate contacted it, from which process or mail message, and did anyone submit data?

A young domain with a brand lookalike, a login form and traffic from a mail click is an incident; a young domain on a CDN contacted once by a browser is usually noise. See the Alert Triage Guide.

Where identity fits

Domain age matters most where identities are at stake. Credential phishing pages, OAuth consent lures and adversary-in-the-middle proxies all need a domain the victim will trust for a few hours, and attackers register them fresh. Prioritise NRD alerts that involve sign-in pages, identity provider lookalikes and token exchange. Machine identities are exposed too: webhooks, callback URLs, package registries and Content Security Policy allow lists hard-code domains that may expire. See the AiTM Phishing Guide.

How to implement: a phased approach

  1. Decide the definitions: pick an NRD window (32 days is a common default), confirm whether your controls use registration or first-seen data, and document TLD coverage gaps.
  2. Enrich before you enforce: add domain age to DNS, proxy and email logs in the SIEM for 30 days. Measure how many distinct NRDs your users contact and which business units need them.
  3. Block where it is cheap: servers, privileged admin workstations and build systems first. These have the lowest false-positive cost.
  4. Pilot warn mode for users: a pilot group of a few hundred users for two to four weeks, tracking warn-page proceeds and help desk tickets.
  5. Build the exception path: a short request form, allow listing by registered domain with an expiry date, and an owner for review.
  6. Tune email scoring: raise scores for young sender and link domains, combined with authentication and first-contact signals, and review quarantine release rates.
  7. Roll back safely: keep policy changes as separate rules so enforcement can return to alert-only in minutes if a legitimate service is blocked at scale.

Detection and measurement

  • Coverage: percentage of DNS, proxy and mail events enriched with a domain age.
  • NRD contact rate: distinct NRDs contacted per 1,000 users per week, by business unit.
  • Precision: share of NRD alerts closed as true positive, tracked separately for servers and users.
  • Exception volume and age: allow list entries created per month, and how many are past their review date.
  • Time to block: minutes from first contact with a malicious NRD to a block across all control points.
  • Phishing caught by age: share of confirmed phishing domains that were under 32 days old when first seen, which validates the window you chose.

Common failure patterns

  • Treating age as a verdict: blocking all NRDs for all users with no exception path, then disabling the policy after a week of complaints.
  • Looking up the full hostname: enriching login.example.co.uk instead of the registered domain, which returns no data and silently scores the host as old.
  • Ignoring re-registration: treating a domain as trusted because it once belonged to a partner or to you. In the ForcedLeak Salesforce Agentforce case, an expired domain still on a Content Security Policy allow list was bought for about $5 and became an exfiltration channel.
  • Confusing newly seen with newly registered: applying a block policy designed for registrations to a first-seen category, which floods users with legitimate CDN and SaaS hostnames.
  • Forgetting compromised old domains: 23% of Interisle's phishing domains were not maliciously registered, so age filtering must sit alongside reputation, content inspection and user reporting.
  • No ccTLD coverage: assuming the NRD feed covers every TLD when many country-code registries publish no zone data.

Framework mapping

FrameworkReferenceRelevance
MITRE ATT&CKT1583.001 Acquire Infrastructure: Domains; T1584.001 Compromise Infrastructure: Domains; T1608.005 Stage Capabilities: Link Target; T1566.002 Spearphishing Link; T1568.002 Domain Generation AlgorithmsAttacker behaviours that domain age detects, and the compromised-domain case it does not
MITRE D3FENDD3-DNRA Domain Name Reputation Analysis; D3-URA URL Reputation Analysis; D3-DNSDL DNS Denylisting; D3-DNSAL DNS AllowlistingDefensive techniques that consume domain age
NIST SP 800-53 Rev. 5SC-7 Boundary Protection; SI-4 System Monitoring; SI-8 Spam Protection; SC-21 Secure Name/Address Resolution Service (Recursive or Caching Resolver)Egress filtering, monitoring and mail filtering
NIST CSF 2.0DE.CM-01; DE.AE-02; DE.AE-07; PR.IR-01Network monitoring, analysis with threat intelligence, network protection
CIS Controls v8.1Control 9 Email and Web Browser ProtectionsDNS and URL filtering and mail protections

Practitioner checklist

  • Confirm whether each control uses registration age, first-seen data or both, and the window it applies.
  • Enrich DNS, proxy and email logs with registered-domain age in the SIEM.
  • Block NRDs for servers, build agents and privileged workstations.
  • Use warn or isolation for general users, and block NRDs that also match brand lookalikes.
  • Score young sender and link domains higher in the email gateway.
  • Run an exception process with owners and expiry dates.
  • Alert on credential submissions to domains under 30 days old.
  • Audit allow lists, CSP headers and integrations for domains you no longer own.
  • Track precision and NRD contact rate monthly and adjust the window.

Standards and references

Related NHI Mgmt Group resources: Protective DNS Guide · DNS Security Guide · Brand Impersonation and Lookalike Domain Takedown Playbook · Email Security Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 11 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org