Where the number comes from
There is exactly one trustworthy source for domain age: the Creation Date field the registry publishes. This tool queries IANA for the TLD's WHOIS server, asks that registry directly over port 43, follows the registrar referral once, and computes the difference from the creation date it finds. Nothing is inferred from archive snapshots, first-seen DNS data, or certificate history — if a registry does not publish a creation date, the result says so instead of estimating.
That matters because several registries genuinely do not publish it. DENIC (.de) omits creation dates entirely. A number of ccTLDs publish only status and nameservers. When you see "age unknown" here it is a fact about the registry, not a failure of the lookup.
What domain age is actually good for
Age is a weak signal that people routinely over-read. It is genuinely useful in three situations, and misleading in most others.
Read the full explanation of domain age checker results ↓Show less ↑
- Acquisition due diligence. A domain being sold as "aged" should have a creation date to match. Check it before money moves; the claim is easy to make and easy to falsify.
- Abuse triage. Domains registered in the last few days and already sending mail or hosting a login form are disproportionately phishing. Age alone should never block anything, but combined with a missing DMARC policy and freshly issued certificates it is a reasonable input to a risk score.
- Renewal planning. The same lookup gives you days-until-expiry, which is the field that actually causes outages.
Where it is misleading: age is not a Google ranking factor in any direct sense — Google has stated repeatedly that the difference between a six-month-old and six-year-old domain is not itself meaningful. What correlates with age is accumulated links, content, and history, and those are measurable directly. Equally, a very old domain that changed hands three times may carry spam history that makes it worse than a fresh registration.
Reading the expiry side of the result
Days-until-expiry is the operationally dangerous number. For most gTLDs the lifecycle after the expiry date runs like this:
| Phase | Typical length | What is true during it |
|---|---|---|
| Auto-renew grace | ~30 days | The domain often stops resolving; the registrar can restore it at the normal renewal price |
| Redemption period | 30 days | Deleted from the zone; only the registrant can redeem, usually for $80–200 |
| Pending delete | 5 days | No recovery possible; the name is queued for release |
| Released | — | Anyone can register it, including drop-catchers watching your domain |
The critical detail is that resolution usually breaks at the *start* of that sequence. An expired domain is an outage weeks before it is a loss. Set a calendar reminder at 60 days and confirm auto-renew is on with a card that has not expired — a lapsed payment method is the most common cause of a domain going down.
clientTransferProhibited) does not prevent expiry. Locks stop transfers; only payment stops deletion.Checking age from the command line
whois google.com | grep -Ei "creation date|registry expiry date"
Creation Date: 1997-09-15T04:00:00Z
Registry Expiry Date: 2028-09-14T04:00:00Zcreated=$(whois google.com | grep -i "creation date" | head -1 | grep -Eo '[0-9]{4}-[0-9]{2}-[0-9]{2}')
echo $(( ( $(date +%s) - $(date -d "$created" +%s) ) / 86400 )) days
# on macOS: date -j -f %Y-%m-%d "$created" +%sFor the full registration record — status codes, DNSSEC state, registrar identity, and the raw response — use the WHOIS lookup. To confirm the delegation matches what your DNS provider serves, run an NS record lookup.