Check when a domain expires

Expiry is not deletion

The most common misunderstanding about domain expiry is that the expiry date is the deadline. It is not. For most generic extensions there is a sequence of stages after expiry, and the domain remains recoverable through most of it — at steadily increasing cost and decreasing certainty.

What the expiry date marks is the point at which the domain may stop working. Many registrars suspend DNS resolution at or shortly after expiry, which takes the website down and, more damagingly, breaks email. Businesses routinely discover an expired domain not because they were watching the date but because email stopped arriving.

The stages after expiry

• Auto-renew grace period. Immediately after expiry the registry auto-renews the domain and bills the registrar, so the record may still look renewed. The registrar can usually still renew at the ordinary price, possibly with a late fee. Standard practice is a window of around forty-five days, reinforced by ICANN's requirement that a domain be deleted within forty-five days of the registration agreement terminating — but the registrar decides when inside that window to delete, so the outer bound is not a promise.
• Redemption Grace Period. Once the registrar deletes the domain, the registry holds it in redemption for thirty days — this one is ICANN-mandated for generic extensions. Only the sponsoring registrar can request a restore, at a registry restore fee substantially larger than a renewal, plus the registrar's margin and a renewal term. Some registrars will not perform restores self-service, or at all.
• Pending delete. After redemption ends the domain enters a short final stage, near-universally five days, during which nothing can be done at all. This is the genuine point of no return.
• The drop. The domain is released to anyone. Desirable names are caught within seconds by automated drop-catching services, and most valuable expiring names never reach an open drop at all because the registrar auctioned them during the grace period instead.

Note the two independent clocks. The forty-five days is a maximum for the registrar, and the thirty-plus-five only begins when the registrar actually deletes. A registrant who assumes they have seventy-five days is wrong: a registrar that deletes on day five gives them forty. One thing is guaranteed rather than discretionary — for generic extensions, DNS resolution must be interrupted for at least the last eight consecutive days during which renewal remains available. The site and the mail may go dark on day one, or may not, but they will be dark before the end.

What the status codes say about where it sits

The status codes in a lookup place a domain in the lifecycle precisely, which is more useful than the expiry date alone.

• autoRenewPeriod — it has expired and the registry auto-renewed it. The record can look healthy at a glance, which is exactly why people miss this. Act now, while recovery is still just a renewal.
• clientHold — the registrar has pulled the domain out of the DNS. Nothing resolves even though the registration is valid. If a working site goes dark and shows this code, it is not a DNS problem.
• redemptionPeriod — it has been deleted. Restore only, through the sponsoring registrar, at a restore fee, and the clock is thirty days.
• pendingDelete — for a generic extension, it is gone. Prepare to re-register or move on.
• inactive — no nameservers are set. A configuration gap rather than a lifecycle problem, but nothing is being served.

Two cautions. Country-code registries are not bound by any of this and several differ substantially: Nominet applies the status pendingDelete to .uk domains across a long span that includes a period where renewal is still perfectly possible, so the code does not carry its generic meaning there. And RDAP renames the statuses — the healthy state ok appears as active, and the rest as spaced lower-case phrases.

Setting up your own expiry monitoring

Registrars are required to warn you: for generic extensions, a notice roughly one month before expiry, a second roughly a week before, and at least one more within five days after, sent by a method that does not require you to log in and look. The obligation is to send them, not to prove you received them, and that gap is what swallows domains. Monitoring that actually works has four parts.

• An inventory. Every domain the organisation holds, with its registrar, registrant email, expiry date, auto-renew state and a named owner. Most organisations are wrong about how many they have, because marketing campaigns, an acquired company and a former agency all registered some.
• Independent alerts. Calendar entries at ninety, sixty and thirty days before each expiry, in a shared calendar rather than one person's. Beyond a handful of names, poll the expiry dates from registration data and alert on the data rather than on the registrar's goodwill.
• Auto-renew plus a valid payment method. Auto-renew fails silently when the stored card expires, and cards expire on a shorter cycle than domains. Check it annually, and prefer a card not tied to an individual employee.
• Coverage of the boring domains. The redirects, the defensive registrations, the domain your mail records reference, and above all the domain your account-recovery mailbox lives on. Those are the ones nobody watches and the ones whose loss cascades.

Why the registrant email is the real single point of failure

Every expiry notice goes to the registrant email address, and so does every account recovery message. Whoever controls that mailbox can reset the registrar password and take the domain. It is the control channel, and usually the weakest link in the chain.

ICANN's Security and Stability Advisory Committee has documented two specific failure modes. The first is self-referential recovery: it is not safe to send credential recovery for a domain to an address inside that same domain, because an attacker who has redirected the mail records receives your password resets — and because the mailbox stops working at the exact moment the domain lapses. The second is abandoned mailboxes: accounts expire through disuse or with the domain they sit on, and attackers have registered expired domains belonging to administrative contacts specifically in order to intercept password-reset mail. The same body found that registrants who let their records go stale appear more vulnerable to attack generally.

What follows is concrete.

• Use an address on a different domain from the one being protected, at a provider you do not otherwise depend on.
• Make it a role account that more than one person can reach, not an individual's mailbox — otherwise the domain becomes unrecoverable when that person leaves.
• Give it its own two-factor authentication. Protecting the registrar account while leaving its recovery mailbox unprotected achieves nothing.
• Keep it accurate. Registrants are obliged to maintain accurate data and to respond to registrar enquiries within fifteen days; an unread mailbox risks suspension for inaccurate data quite apart from the hijacking risk.

One scheduling note: changing the registrant email is treated as a change of registrant, which triggers a mandatory sixty-day inter-registrar transfer lock unless you opted out in advance. Make the change when you are not about to move the domain.

What to do with the answer

If you are checking your own domain, the useful outcome is not the date but the changes it should prompt: turn on auto-renew, verify the card on file has not expired, and confirm the registrant email is an address someone still reads.

If you are checking someone else's domain because you want it, the odds are poor for any name with commercial value, and expiry dates shift when the owner renews. A backorder through a drop-catching service is the realistic route, and even that is a bid rather than a purchase.