Newly Registered Domains: How to Detect Them and Use Them as a Threat Signal

Introduction

The operational window for a malicious domain is short. Attackers register a domain, activate it within 24 to 72 hours, execute the campaign — phishing, malware delivery, BEC, credential harvest — and abandon the infrastructure before a takedown request completes. This operational constraint creates a consistent forensic artifact: a domain creation date within the last 30 days.

Threat intelligence teams have known about this pattern for years. Studies of phishing and malware infrastructure consistently show that newly registered domains — those less than 30 days old — appear at a rate far exceeding their share of the total domain population. The signal is probabilistic, not conclusive, but it is reliable enough to form the backbone of a first-order risk filter.

The data is already available in WHOIS and RDAP responses. The WhoisJSON API pre-computes it as a boolean field (age.isNewlyRegistered) so no date arithmetic is required in application code. What is missing in most pipelines is not the data — it is the integration. This article covers why the signal is reliable, how to read it via the API, how to combine it with DNS, SSL, and EPP data into a composite risk score, and three production patterns for integrating it into real security workflows. For the broader approach to phishing domain detection, see detecting phishing domains programmatically.

Why Domain Age Is a Reliable Threat Signal

The adversary model behind this signal is structural. Legitimate organizations register domains months or years before they go live — time for DNS propagation, SSL provisioning, infrastructure build-out, and legal review. Malicious operators work on the opposite timeline: register, activate within hours, execute, abandon.

Three properties make this structural asymmetry exploitable:

• No reputation history.  Traditional threat feeds and reputation systems require evidence of past behavior to score a domain. A fresh domain has no indexed pages, no passive DNS history, no known-good certificate history, no abuse reports. It bypasses legacy blacklists by default — which is precisely why attackers prefer fresh infrastructure.
• Low registration cost.  Generic TLDs like .xyz, .top, .click, and .online frequently offer first-year registrations for under $1. Disposable domain infrastructure has essentially no economic barrier. Volume is trivial; detection friction is the only meaningful cost to the attacker.
• Short TTL campaigns.  Modern phishing kits are designed to run for hours or days, not weeks. By the time a threat feed ingests and propagates a block for the domain, the campaign payload has already been delivered and the infrastructure abandoned. A detection model that flags at registration time — before first malicious use — closes this gap.

What “Newly Registered” Means in Practice

The WhoisJSON API returns two pre-computed age thresholds in the age  object — available when source  is rdap:

A full API response containing these fields looks like the following. Theage  object is always present when source  equals rdap. For domains where the API falls back to legacy WHOIS, the age  object will be null  — in that case, compute age manually from the created  field if it is present. For the complete field reference, see the WHOIS API JSON response guide.

{
  "name": "example-phishing.com",
  "registered": true,
  "source": "rdap",
  "created": "2026-04-20 14:23:11",
  "expires": "2027-04-20 14:23:11",
  "age": {
    "days": 12,
    "months": 0,
    "years": 0,
    "isNewlyRegistered": true,
    "isYoung": true
  },
  "expiration": {
    "daysLeft": 353,
    "isExpiringSoon": false,
    "isExpired": false
  }
}

The Three Data Sources That Matter

When building a newly registered domain detection pipeline, the choice of data source determines both what you can detect and how fast you can detect it.

1. WHOIS / RDAP on demand

The approach covered in this article. You query a specific domain, get the full registration record including the age  object, and decide. Ideal for enriching incoming IOCs, validating domains extracted from email headers or DNS logs, and scoring suspicious domains before an analyst invests time in manual investigation. WhoisJSON provides this via /api/v1/whois.

Latency is real-time and per-domain. No pre-registration detection — you only learn about a domain after it exists.

2. Zone file feeds

Zone file feeds deliver a list of all new domain registrations in a TLD, typically on a daily basis. They enable proactive detection: you receive new registrations before any traffic or campaigns are observed, and can pre-screen for brand lookalikes or high-risk naming patterns before they activate.

3. Passive DNS

Passive DNS detects a domain when it starts resolving, not at registration. A domain can be registered and sit dormant for days before DNS records are provisioned. Passive DNS therefore has an inherent lag relative to registration date, and misses domains that never resolve publicly.

Passive DNS is useful as a complementary signal — it tells you a domain has gone from dormant to active, which may correlate with campaign activation. It does not replace registration-date data.

For enrichment workflows — receiving a list of suspicious domains from an EDR alert, SIEM correlation, or threat feed, and scoring them — WHOIS/RDAP is the most direct and operationally simple approach.

Detecting Newly Registered Domains: Python

The following script takes a list of suspect domains, queries the WhoisJSON API concurrently, and returns a report separating newly registered domains from the rest. It uses asyncio  with aiohttp  and a semaphore to stay within rate limits. For more on the async pattern and bulk lookup strategies, see the Python WHOIS API guide.

import asyncio
import aiohttp

API_KEY = "YOUR_API_KEY"
BASE    = "https://whoisjson.com/api/v1"
HEADERS = {"Authorization": f"TOKEN={API_KEY}"}


async def check_domain(session: aiohttp.ClientSession, domain: str) -> dict:
    try:
        async with session.get(
            f"{BASE}/whois",
            params={"domain": domain},
            timeout=aiohttp.ClientTimeout(total=15),
        ) as resp:
            if resp.status != 200:
                return {"domain": domain, "error": f"HTTP {resp.status}"}
            data = await resp.json()
    except Exception as exc:
        return {"domain": domain, "error": str(exc)}

    age = data.get("age") or {}
    return {
        "domain":            domain,
        "registered":        data.get("registered", False),
        "isNewlyRegistered": age.get("isNewlyRegistered", False),
        "isYoung":           age.get("isYoung", False),
        "days_old":          age.get("days"),
        "source":            data.get("source"),
    }


async def bulk_scan(domains: list[str], concurrency: int = 5) -> list[dict]:
    sem = asyncio.Semaphore(concurrency)

    async def bounded(domain: str) -> dict:
        async with sem:
            return await check_domain(session, domain)

    async with aiohttp.ClientSession(headers=HEADERS) as session:
        return await asyncio.gather(*[bounded(d) for d in domains])


if __name__ == "__main__":
    suspects = [
        "paypa1-secure-login.com",
        "microsoft-helpdesk-update.net",
        "google-workspace-portal.org",
    ]

    results = asyncio.run(bulk_scan(suspects))
    flagged = [r for r in results if r.get("isNewlyRegistered")]

    print(f"Scanned: {len(results)}  |  High risk (newly registered): {len(flagged)}")
    for r in flagged:
        print(f"  [!] {r['domain']}  —  {r['days_old']} days old  (source={r['source']})")

Edge cases to handle in production

• Domain not registered.  When registered  is false, the age  object will be absent. This is not an error — the domain simply has no registration record to compute age from. Handle it as a separate bucket: "unregistered" is not the same as "safe."
• Legacy WHOIS source.  When source  is whois  (not rdap), the age  object will be null. Fall back to computing age manually: (today - created).days < 30. The created  field is usually present even for legacy WHOIS.
• GDPR privacy shield.  Registrant contacts may be fully redacted, but the creation date is almost always preserved even under privacy protection — registrars are not required to redact dates. An absent creation date in a GDPR-shielded record is itself a mild signal.

Combining Domain Age with Other Signals

The isNewlyRegistered  signal alone generates false positives: legitimate startups, new product launches, and marketing campaigns all create new domains. A scoring model that combines multiple independent signals produces far fewer erroneous alerts than any single indicator.

The following table assigns risk points based on observable signals available via the WhoisJSON API. Points are additive; domains above 60 warrant automated escalation.

One combination deserves special attention: isNewlyRegistered  combined with an EPP status of clientHold  is an extremely strong signal. A domain that has been suspended by the registrar within days of registration has almost certainly triggered an abuse or fraud check. The statusAnalysis.isOnHold  flag from the EPP status codes reference  makes this trivial to check programmatically.

For the SSL certificate issuance timing check, compute the difference between valid_from  (from the SSL certificate API) and the domain created  date. A gap of under 7 days indicates the certificate was provisioned immediately after registration — typical of rapidly activated attack infrastructure. For the DNS signals, query the DNS lookup API  and check for active MX records and DMARC presence.

Integration Patterns

Three production patterns cover the majority of use cases for this signal.

1. Email gateway enrichment

When an inbound email arrives from an unknown sender domain, extract the domain from the From:  header, query the WhoisJSON API, and apply a score. If age.isNewlyRegistered  is true, the base score is already 40 — typically sufficient to trigger a user warning or quarantine header.

Implementation note: cache WHOIS results per domain with a 1-hour TTL. Most email attack campaigns reuse the same sending domain across many messages within a short window. Without caching, a campaign sending 500 messages from one domain will generate 500 API calls for identical data.

2. SOC IOC triage

During incident response and threat hunting, analysts receive lists of potentially malicious domains from EDR alerts, SIEM correlations, or external threat feeds. Bulk-enriching these with WHOIS age data helps prioritize work: a domain under 30 days old with no reputation history gets investigated first; a domain registered 3 years ago with a clean SSL history and active DMARC moves to the back of the queue.

The nrd_scan.py  script above handles this workflow directly. For larger IOC lists, see the patterns in the bulk WHOIS lookup guide  for concurrency tuning and retry handling.

3. Domain inventory sweep

Periodically audit all domains appearing in network logs, proxy logs, and DNS queries against your known-good domain inventory. Flag domains that appear in traffic but are absent from your inventory AND are newly registered — these are high-priority candidates for investigation.

Common findings: typosquatting domains that employees have clicked through, phishing infrastructure that has already been contacted by a user before the alert fired, and shadow IT assets registered by team members outside the procurement process.

For an end-to-end ASM pipeline that integrates this pattern, see WHOIS API for attack surface management.

Monitoring for New Registrations That Resemble Your Brand

The integration patterns above are reactive: you start with a domain and score it. Brand protection adds a proactive layer: you watch the namespace and alert as soon as a dangerous registration appears, before it is used in a campaign.

The recommended workflow:

• Generate lookalike variants.  Character transpositions, omissions, homoglyph substitutions, hyphen insertions, and TLD swaps of your brand name. A typical brand of 8 characters generates several hundred meaningful variants.
• Daily availability sweep.  Query /domain-availability  for each variant once per day. This costs 1 API credit per domain per day — 500 variants cost 500 credits, well within the free tier for small watchlists.
• Trigger full enrichment on state change.  When a variant transitions from available: true  to available: false, run the full WHOIS + DNS + SSL enrichment. If age.isNewlyRegistered  is true (it will be — the domain was just registered), compute the composite score and alert if it exceeds your threshold.
• Use domain monitoring for high-priority variants.  For exact-match variants with a different TLD (yourcompany.xyz  when you own yourcompany.com), the WhoisJSON domain monitoring  feature fires an alert the moment any WHOIS, DNS, or SSL change is detected — without polling costs or latency.

For a complete implementation of this pattern including Python code for variant generation and tiered polling schedules, see the brand protection domain monitoring guide.

Conclusion

The domain age signal is simple, high-value, and systematically underused. The majority of phishing, BEC, and malware delivery infrastructure relies on newly registered domains — domains that have no history, no reputation, and no place in legitimate-domain inventories. A single boolean field flags them.

The age.isNewlyRegistered  field is available in every WhoisJSON WHOIS response for RDAP-supported domains, pre-computed with no additional configuration. Combine it with DNS, SSL certificate timing, and EPP status data for a composite risk score that closes the gap between fresh domain registration and first malicious use. The logical next step on EPP signals: EPP status codes: complete reference for developers.