How to check a domain expiration date

Domains don't fail loudly. An expired certificate throws a browser warning; an expired domain just quietly stops resolving, takes email down with it, and, after a grace window, goes up for grabs to whoever's watching the drop lists. Companies with real engineering teams have lost production domains this way: a renewal card expired, the reminder emails went to an inbox nobody read, and the first anyone heard about it was a customer.

Checking an expiration date takes thirty seconds. This guide covers how to do it (WHOIS, RDAP, and the web tool), which date field to actually trust, what happens after expiry, and how to make the check automatic so you never do it manually again.

Step 1. Run a WHOIS lookup

The fastest path is the WHOIS Lookup tool. Enter the domain (the registrable name, example.com, not www.example.com or a full URL) and the registration record comes back parsed, with the expiry date pulled out for you.

From a terminal, the classic CLI works on macOS and most Linux distros out of the box:

whois example.com

For .com and .net you'll often get two responses concatenated: one from the registry (Verisign) and one from the registrar. Both contain an expiry date. More on which one to believe below.

Step 2. Find the expiry field

In raw WHOIS output, look for a line like:

Registry Expiry Date: 2027-08-13T04:00:00Z

Field naming is not standardised. Depending on the TLD and registrar you may see Expiration Date, Expiry date, paid-till (.ru), renewal date, or Expires On. Some ccTLDs (.de is the famous one) don't publish an expiry date in WHOIS at all; for those, the only authoritative source is the registrar account the domain lives in.

Dates are usually UTC in ISO 8601 format. If you're cutting it close, remember the domain can stop resolving at the registry's rollover, not midnight your time.

Step 3. Prefer RDAP if you're scripting it

WHOIS is a 1980s plain-text protocol with no schema, which makes it miserable to parse reliably. RDAP (Registration Data Access Protocol) is its JSON replacement, mandatory for all gTLDs since 2019. Same data, machine-readable:

curl -s https://rdap.org/domain/example.com | jq '.events'

rdap.org is a bootstrap redirector that forwards you to the correct registry's RDAP server. In the response, the expiry lives in the events array:

{
  "eventAction": "expiration",
  "eventDate": "2027-08-13T04:00:00Z"
}

If you're building anything automated (a script that audits your domain portfolio, a cron job, a dashboard), use RDAP. Parsing free-form WHOIS text across registrars is a project in itself.

Registry date vs registrar date

When you see two different expiry dates for the same domain, here's what's going on. The registry date is when the domain expires at the TLD operator. The registrar date can lag or lead it slightly because of how renewals batch, and some registrars display a date that already includes an auto-renew they intend to perform.

Rule of thumb: the registry's date is the one that matters for whether the domain keeps resolving. If the dates disagree by more than a day or two, log in to the registrar and find out why before assuming the later one.

While you're in the record, check the status flags too. clientTransferProhibited is normal (transfer lock). autoRenewPeriod, redemptionPeriod, or pendingDelete mean the domain has already expired and is moving through the post-expiry lifecycle; act immediately.

What actually happens when a domain expires

For most gTLDs the lifecycle after the expiry date looks like this:

1. Auto-renew grace period: typically 0-45 days, registrar-dependent. The domain usually stops resolving (registrars commonly park it), but the original owner can still renew at the normal price.
2. Redemption grace period: 30 days. The domain can still be recovered, but only through the registrar and usually with a redemption fee that runs well above a normal renewal, often in the $80-200 range depending on registrar.
3. Pending delete: 5 days. Nobody can recover it. At the end, it drops and becomes available for registration, and dropped domains with any traffic history get snapped up by drop-catching services within seconds.

The takeaway: "expired yesterday" is recoverable and cheap. "Expired six weeks ago" is recoverable and expensive. "Expired ten weeks ago" may be gone for good.

Step 4. Fix the failure modes before they fire

A calendar reminder is better than nothing, but the actual causes of accidental expiry are usually upstream of the date itself. While you're checking, audit these:

• Auto-renew: confirm it's on at the registrar. This is the single highest-value setting.
• Payment method: auto-renew fails silently when the card on file has expired. Check the card's expiry against the domain's.
• Contact email: registrar warnings go to the registrant email. If that's admin@ on the very domain that's about to expire, the warnings die with it. Use an address on a different domain.
• Multi-year renewal: for domains you know you're keeping, renew 5-10 years out and remove the annual ritual entirely.
• Ownership of the registrar account: the classic agency failure: the domain was registered by a contractor or a long-gone employee, and nobody currently at the company can log in. Find out now, not during redemption.

Step 5. Automate the check

Manual WHOIS checks work until the one quarter you forget. A domain expiry monitor does the same lookup on a schedule and alerts you at configurable thresholds (60, 30, 14 days out and so on), so the renewal conversation happens with weeks of slack instead of during an outage.

If you manage more than a couple of domains (client domains especially), put every one of them under monitoring and treat the alert as the system of record. Spreadsheets of expiry dates rot the moment someone renews early or transfers a domain without updating the sheet.

Domain expiry pairs naturally with DNS record drift monitoring on the same domains: expiry tells you the domain is about to fall over; drift tells you someone changed where it points. Together they cover the two ways a domain you own stops being the domain you own.

Common mistakes

Checking the wrong name. WHOIS operates on registrable domains. Querying www.example.com or app.api.example.com either errors or falls back to the parent; the expiry you want is on example.com itself.

Trusting a stale cached result. Some WHOIS aggregator sites cache aggressively. If a date looks wrong, confirm against the registry's own RDAP endpoint or the WHOIS tool, which queries live.

Assuming the site being up means the domain is fine. During parts of the grace period DNS may keep serving from caches while the domain is already in trouble at the registry. A DNS lookup tells you what resolvers see now; only the registration record tells you the expiry state.

Confusing domain expiry with certificate expiry. Different systems, different dates, different fixes. A TLS certificate expiring doesn't touch the domain registration, and vice versa. Monitor both.

TL;DR

1. Run the domain through the WHOIS Lookup tool, or whois example.com in a terminal.
2. Find Registry Expiry Date; the registry's date is authoritative.
3. Scripting? Use RDAP: curl https://rdap.org/domain/example.com and read the expiration event.
4. Verify auto-renew, the payment card, and that the registrant email isn't on the expiring domain.
5. Put the domain on a domain expiry monitor and stop checking by hand.