Domain Registration Date Lookup: Find When a Domain Was Registered

Finding out when a domain was first registered is a small task with a surprising number of edge cases. For a .com it takes one command. For many country-code domains the answer is not published at all, and for a domain that has changed hands the date you get back may not mean what you assume. This guide covers how to run the lookup properly, how to read the result, and what to do when the registry gives you nothing.

TL;DR / KEY TAKEAWAYS

• Two protocols answer the question: WHOIS (text, legacy) and RDAP (JSON, current). RDAP is the better choice for anything scripted.
• The field name varies: "Creation Date", "Created On", "registered", "Domain Registration Date" — in RDAP it is the event with eventAction: "registration".
• Not every registry publishes it: many ccTLDs omit creation dates entirely, and some have no RDAP server at all, producing the "no registry RDAP server was identified" error.
• The date describes the registration record, not the business: transfers, deletions and re-registrations can reset it, and a rebrand breaks the link to the organisation entirely.
• Bulk lookups are not viable over WHOIS/RDAP: registries rate-limit per IP, and both protocols answer one domain at a time by design.
• For population-scale work, use zone data: 1,538 packages — 716 TLD zone files, 716 enriched zone sets (NS, MX, IP, CMS), 79 technology site lists, 27 curated datasets — covering 279,944,703 domains. Registration dates are present only where the source zone publishes them.
• No contact data: the packages carry domain and infrastructure attributes only.

TABLE OF CONTENTS

1. Why the Registration Date Is Asked For
2. How to Look Up a Registration Date
3. What the Date Can and Cannot Tell You
4. Working at Population Scale
5. Common Mistakes
6. Frequently Asked Questions
7. Conclusion
8. Related Resources

Why the Registration Date Is Asked For

The creation date of a domain is one of the few registration facts that survived the post-GDPR redaction of WHOIS records, which is part of why it gets used so heavily. Contact fields are gone; dates, registrar and name servers remain.

Three questions account for most lookups. The first is verification: a site claims to have been operating since 2009, and a creation date of 2021 is a reason to ask a follow-up question. The second is risk assessment — domains registered days ago are disproportionately represented in phishing and fraud, so age is a common input to a risk score, though a weak one on its own. The third is domain acquisition: when evaluating an expired or aftermarket name, registration age is one signal among several about whether the name has a history worth inheriting.

What all three have in common is that the date is an input, not a conclusion. It tells you when a registration record began. Everything else — who ran the domain, what was published on it, whether it has changed hands — requires other evidence.

How to Look Up a Registration Date

RDAP, the current protocol. RDAP returns JSON, which means no parsing of free-form text. The date lives in the events array:

curl -s https://rdap.org/domain/example.com | jq '.events[] | select(.eventAction=="registration")'

rdap.org acts as a bootstrap redirector, resolving the authoritative server for the TLD via the IANA registry and forwarding the query. The response also carries expiration and last changed events, the sponsoring registrar, and the domain's status codes.

WHOIS, the legacy protocol. Still ubiquitous and still useful, especially for ccTLDs that never deployed RDAP:

whois example.com | grep -i -E 'creat|regist'

Expect variation. Different registries label the same field "Creation Date", "Created On", "created", "Domain Registration Date" or "registered", and date formats differ too. Any parser you write needs to handle several spellings and at least ISO-8601 plus a couple of regional formats.

A ccTLD example. Take aajtak.in. The .in namespace is administered by NIXI, and a lookup goes to its WHOIS service:

whois aajtak.in

You will typically get the creation, update and expiry dates, the sponsoring registrar, status codes and name servers, with the registrant contact block redacted. That pattern — technical fields present, contact fields withheld — is now the norm for gTLDs and most ccTLDs alike.

When there is no RDAP server. The error "no registry RDAP server was identified for this domain" means the TLD has no entry in the IANA bootstrap registry, so an RDAP client has nowhere to send the query. RDAP is contractually required for gTLDs but optional for ccTLDs, which are run under national policy. Fall back to WHOIS for that TLD, or to the registry's own web lookup. Retrying the RDAP query will not help; the endpoint does not exist.

When the date is not published at all. Several registries deliberately omit creation dates from public responses. In that case, the alternatives are indirect and none of them is authoritative: the earliest capture in the Internet Archive's Wayback Machine puts an upper bound on when the site was live, and the earliest Certificate Transparency log entry for the hostname shows when a certificate was first issued. Both give you "no later than" evidence, which is often enough, but neither is the registration date.

What the Date Can and Cannot Tell You

It reflects the registration record, not the organisation

A company founded in 2003 may hold a domain created in 2018 because it rebranded, bought a better name, or consolidated onto a new one. A domain created in 2003 may be in the hands of an entirely different owner today. The date is a property of the record, and the record survives changes of owner without necessarily showing them.

Deletion and re-registration reset it

If a domain expires, completes the redemption and pending-delete cycle, and is registered again by someone else, the new registration typically shows the new creation date. The domain's earlier life is invisible in the current record. This matters most in aftermarket evaluation, where a name presented as "registered since 2006" may have lapsed and restarted in between.

Age is a weak risk signal on its own

Newly registered domains are over-represented in abuse, which makes age a reasonable feature in a scoring model. It is a poor rule in isolation, because every legitimate new business also has a recently registered domain. Combine it with signals that carry independent information — whether the domain resolves, whether it has mail configured, what the hosting network is, whether a real site is served.

Age is not an SEO ranking factor in the way it is often described

Search engines have consistently said domain age by itself is not a ranking signal. What correlates with age is the accumulation of links, content and usage history over time — which is a real effect, but it belongs to what the domain has done, not to how long it has existed. An old domain that never published anything carries none of it.

What it does establish cleanly

A creation date is solid evidence for one narrow claim: this registration record did not exist before this date. That is sufficient to contradict an "established in" claim, to bound a timeline in an investigation, or to separate domains registered during a specific window when clustering a campaign.

Working at Population Scale

Everything above concerns a single domain. Once the question is about many domains — how many were registered in a zone last quarter, which hosting networks the newest domains use — WHOIS and RDAP stop being an option. Both answer one domain per query, registries rate-limit per IP, and a job over even a hundred thousand domains will be throttled long before it finishes.

The alternative is zone-level data distributed as files. WebTrackly's catalog holds 1,538 packages: 716 TLD zone files, 716 enriched zone sets adding name servers, MX records, resolved IPs and detected CMS, 79 technology site lists, and 27 curated datasets. Together the zone packages cover 279,944,703 domains, of which 163,422,083 are .com; the all-registered-domains dataset holds 272,614,863 rows. WordPress is detected on 21,639,326 domains and Joomla on 607,765.

What a package contains

Each is a CSV inside a ZIP:

Registration dates appear only where the source zone publishes them — for many ccTLDs they are not available, and the column is absent rather than estimated. There is no registrant column and no contact column: no email addresses, no phone numbers, no personal data of any kind.

Deriving registration activity without a date column

When dates are absent you can still measure registration activity, by comparing snapshots. Buy the same package at two points in time and the domains present in the newer file but not the older one are the ones registered in the interval:

-- domains added between two snapshots
SELECT n.domain, n.ns, n.mx
FROM read_csv_auto('snapshots/com-2026-07-01.csv') n
LEFT JOIN read_csv_auto('snapshots/com-2026-04-01.csv') o USING (domain)
WHERE o.domain IS NULL;

-- and which name servers the new registrations chose
SELECT ns, count(*) AS new_domains
FROM (
  SELECT n.domain, n.ns
  FROM read_csv_auto('snapshots/com-2026-07-01.csv') n
  LEFT JOIN read_csv_auto('snapshots/com-2026-04-01.csv') o USING (domain)
  WHERE o.domain IS NULL
)
GROUP BY ns ORDER BY new_domains DESC LIMIT 20;

This is often better than a date column for the questions people actually ask, because it comes with the infrastructure attributes attached. The requirement is simply that you keep and date every file you download.

Getting the files

Browse /zones/ for zone files and enriched sets, /datasets/ for curated collections, and /packages/ for the full catalog; row counts are shown before purchase. Packages start at $3.50 and download immediately, exported fresh at the moment of purchase. Pro is $29/month (50 packages, 10 datasets, 30,000 API calls) and Enterprise is $99/month (200 packages, 50 datasets, 300,000 API calls) — see /pricing/.

unzip com-enriched.zip
head -3 com-enriched.csv
wc -l com-enriched.csv

# list zone-file packages via the API
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

# technology packages matching a keyword
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

The API exposes the package catalog — what exists, what it costs, how many rows it has. It does not accept a domain name and return facts about it; per-domain registration data comes from WHOIS or RDAP. Reference at /api/.

Common Mistakes

Mistake 1: Reading the creation date as the company's founding date

The record describes the registration, not the organisation. Rebrands, aftermarket purchases and consolidations all break the link. Corroborate against a company register or the site's own history before making a claim about the business.

Mistake 2: Assuming every registry publishes the date

Several ccTLDs omit creation dates from public responses entirely. When that happens, Wayback captures and Certificate Transparency entries give you a "no later than" bound, which is useful but is not the registration date and should not be presented as one.

Mistake 3: Retrying when RDAP reports no server

"No registry RDAP server was identified for this domain" means the TLD is absent from the IANA bootstrap registry. There is no endpoint to reach. Fall back to WHOIS for that TLD instead of adding retry logic.

Mistake 4: Building a bulk pipeline on per-domain queries

Registries rate-limit by IP and both protocols are per-domain by design. A large job will be throttled and produce partial results you cannot use for percentage claims. Take the population from zone-level data and reserve lookups for the subset that needs authoritative status.

Mistake 5: Using age as a standalone risk rule

Newly registered domains are over-represented in abuse, but so is every legitimate business that launched this month. Use age as one feature among several — resolution, mail configuration, hosting network, presence of real content — rather than as a rejection rule.

Mistake 6: Overstating what a single snapshot shows

One file describes a state. Growth, churn and migration all require two observations. Archive and date every download; a snapshot you discarded is a comparison you can no longer make.

Frequently Asked Questions

Q: How do I find when a domain was registered?
A: Query RDAP and read the event with eventAction: "registration", or run whois and look for a field named "Creation Date", "Created On", "created" or "registered". RDAP is preferable for scripting because it returns structured JSON.

Q: Why does the field name keep changing between TLDs?
A: WHOIS has no enforced response schema, so each registry labels and formats fields its own way. RDAP standardises this, which is the main practical reason to prefer it.

Q: Why is there no creation date for some domains?
A: Some registries do not publish it. There is no workaround that produces the true date; Wayback captures and Certificate Transparency entries give an upper bound on when the domain was in use.

Q: What does "no registry RDAP server was identified for this domain" mean?
A: The TLD has no RDAP entry in the IANA bootstrap registry, so the client cannot determine where to send the query. RDAP is required for gTLDs but optional for ccTLDs. Use WHOIS for that TLD instead.

Q: Does the registration date change when a domain is sold?
A: A straightforward transfer usually preserves it. A domain that expires, is deleted and is registered again generally shows the new creation date, with the earlier history invisible in the current record.

Q: Can I look up registration dates in bulk?
A: Not through WHOIS or RDAP. Both are per-domain and rate-limited. For population-scale work, use zone-level files and compare dated snapshots to derive registration activity.

Q: Does WebTrackly offer a domain lookup?
A: No. WebTrackly distributes bulk packages as downloadable files — you buy a package, download a ZIP containing CSV, and process it yourself. There is no per-domain lookup service.

Q: Do the packages include registration dates?
A: Only where the source zone publishes them. Where the registry does not expose dates, the column is absent rather than estimated.

Q: Do the packages include contact details?
A: No. They contain domain, name servers, MX, resolved IP and detected CMS. No email addresses, phone numbers or registrant identities.

Q: What does it cost?
A: Packages from $3.50 as one-time purchases. Pro is $29/month (50 packages, 10 datasets, 30,000 API calls); Enterprise is $99/month (200 packages, 50 datasets, 300,000 API calls). See /pricing/.

Conclusion

For one domain, a registration date lookup is a single RDAP query or a single whois call, with the caveats that the field name varies, some registries publish nothing, and some TLDs have no RDAP endpoint at all. Read the result narrowly: it establishes when the registration record began, not when a company was founded and not who controls the name today.

For many domains, the per-domain protocols are the wrong tool entirely. Zone-level files give you the whole population at once, with name servers, mail routing, resolved addresses and detected CMS attached, and comparing dated snapshots reconstructs registration activity even for zones that publish no dates at all. The schema is deliberately narrow and contains no personal data — knowing that in advance is what keeps a project from failing at the last step.

Browse the zone file catalog →

Related Resources

• Package Catalog — 1,538 downloadable domain databases
• Zone Files by TLD — .com, .net, .de and 700+ more
• Curated Datasets — all registered domains, MX servers, e-commerce
• API Documentation — catalog access with a bearer token
• Pricing — one-time purchases from $3.50