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.
| Term | What it measures | Typical window | Data source | Strength | Weakness |
|---|---|---|---|---|---|
| Newly registered domain (NRD) | Registration date or ownership change of the registered domain | Palo Alto Networks' PAN-DB category uses the last 32 days; feeds also offer 7, 14 or 90 days | Zone file differences, RDAP, registry and registrar data | Catches attacker-registered domains before first use | Weak for ccTLDs with no public zone data; misses compromised old domains |
| Newly seen or newly observed domain | First time the provider saw the name resolve in DNS traffic | Cisco Umbrella's Newly Seen Domains keeps a domain in the category for 24 hours after first query | Passive DNS and resolver telemetry | Covers subdomains and ccTLDs; reflects real use | High volume; legitimate new hostnames appear constantly |
| Young certificate | Recent first certificate for a name | Hours to days | Certificate Transparency logs | Often appears before a phishing site goes live | Many legitimate automated certificates |
| Low-prevalence domain | Rarely or never visited in your own estate | Your baseline period, often 30 days | Your own DNS and proxy logs | Tuned to your environment | Says 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
eventsarray in whicheventAction"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 point | Suggested policy | Why | Exception handling |
|---|---|---|---|
| Protective DNS or URL filtering, high-risk users and servers | Block NRDs within 32 days | Servers and privileged users rarely need brand-new domains; Palo Alto lists block as best practice for the category, with alert as the default | Change-controlled allow list per registered domain |
| Protective DNS or URL filtering, general users | Warn page or isolate in remote browser; block where an NRD also matches a lookalike or a risky category | Keeps business working while adding friction where phishing lands | User can proceed after warning; logged |
| Email gateway | Raise spam or phishing score for sender and link domains under 30 days; quarantine when combined with failed DMARC alignment or first-time sender | Fresh sender domains have no reputation; combining signals cuts false positives | Supplier onboarding process registers new partner domains |
| Newly seen domains category | Audit only, then alert | Cisco recommends starting in audit mode because many matches are legitimate | Review in reporting before any block |
| Servers, build agents and OT networks | Default-deny egress with explicit allow lists, which makes NRD blocking redundant | Allow listing is stronger than age heuristics where it is feasible | Allow 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
- When was it registered, and does RDAP show a recent "reregistration" or "transfer" event?
- Does the name resemble your organisation, a supplier or a SaaS provider you use?
- Which registrar, TLD and name servers does it use, and were sibling domains registered at the same time (a bulk set)?
- Does it have MX records, a certificate, or a login page?
- 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
- 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.
- 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.
- Block where it is cheap: servers, privileged admin workstations and build systems first. These have the lowest false-positive cost.
- 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.
- Build the exception path: a short request form, allow listing by registered domain with an expiry date, and an owner for review.
- Tune email scoring: raise scores for young sender and link domains, combined with authentication and first-contact signals, and review quarantine release rates.
- 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.ukinstead 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
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1583.001 Acquire Infrastructure: Domains; T1584.001 Compromise Infrastructure: Domains; T1608.005 Stage Capabilities: Link Target; T1566.002 Spearphishing Link; T1568.002 Domain Generation Algorithms | Attacker behaviours that domain age detects, and the compromised-domain case it does not |
| MITRE D3FEND | D3-DNRA Domain Name Reputation Analysis; D3-URA URL Reputation Analysis; D3-DNSDL DNS Denylisting; D3-DNSAL DNS Allowlisting | Defensive techniques that consume domain age |
| NIST SP 800-53 Rev. 5 | SC-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.0 | DE.CM-01; DE.AE-02; DE.AE-07; PR.IR-01 | Network monitoring, analysis with threat intelligence, network protection |
| CIS Controls v8.1 | Control 9 Email and Web Browser Protections | DNS 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
- IETF: RFC 9083 JSON Responses for the Registration Data Access Protocol (RDAP)
- ICANN: Launching RDAP; Sunsetting WHOIS
- ICANN: Centralized Zone Data Service help
- CIS: Control 9 Email and Web Browser Protections
- Interisle Consulting Group: Phishing Landscape 2025
- Palo Alto Networks Unit 42: Newly Registered Domains: Malicious Abuse by Bad Actors
- Palo Alto Networks: URL risk categories
- Cisco: Enable Newly Seen Domains security category in Umbrella
Related NHI Mgmt Group resources: Protective DNS Guide · DNS Security Guide · Brand Impersonation and Lookalike Domain Takedown Playbook · Email Security Guide