The Domain Expiration Lifecycle, Stage by Stage

Active registration, and where the fixed rules actually are

A generic-extension domain moves through a fixed sequence of registry-side states, the same at every gTLD registry. The day counts attached to those states are not equally binding, and that distinction is the most useful thing to carry into the rest of this guide. Some durations are ICANN consensus policy. Some are registry operational policy that happens to be near-universal. One of the most consequential intervals is entirely at your registrar's discretion.

RFC 3915, the EPP specification that defines the grace period states, is explicit: the duration of each grace period is a matter of registry operational policy not addressed in the document. The standard fixes the names of the states and the mechanics of restoration, not the clock.

While a registration is active the domain shows the EPP status ok, or more commonly clientTransferProhibited alone - the standard registrar transfer lock, which is normal rather than a symptom of a problem. Registrations run in one-year increments to a maximum unexpired term of ten years.

The notices your registrar is required to send

ICANN's Expired Registration Recovery Policy, a consensus policy with compliance required from 31 August 2013, imposes hard notification duties on registrars for generic extensions. There are three notices and the timing is specified.

• Approximately one month before expiry. ICANN Compliance treats 26 to 35 days ahead as compliant.
• Approximately one week before expiry. The compliant range is 4 to 10 days.
• At least one further notice within five days after expiry, including renewal instructions.

Notices must go out by a method that does not require affirmative action to receive them - email or an equivalent push mechanism, not a message sitting unread in a control panel - and in the language of the registration agreement. Registrars must also publish renewal, post-expiration renewal and redemption fees on their website, and resellers carry the same duty.

The obligation is to send, not to prove receipt, and that cuts both ways. If the notices went to a departed employee's mailbox, the registrar has still complied. If it genuinely failed to send them, ERRP gives you a route: a compliance complaint to ICANN.

Expiry day and the auto-renew grace period

At the expiry date the registry, in the standard gTLD model, auto-renews the domain and sets the status autoRenewPeriod. The registrar is billed for a renewal you have not paid for, and if it later deletes the domain within this window it receives a credit - which is why the window exists and why cheap late renewals are possible during it.

The standard duration is 45 days, and that figure deserves careful phrasing. It is well-established registry practice, reinforced by ICANN's Expired Domain Deletion Policy - effective 21 May 2009 - which requires a domain to be deleted within 45 days of either party terminating the registration agreement. EDDP frames that as a deletion deadline rather than defining a grace period length. It is an outer bound, not a promise.

Registrar discretion is very wide here, and this is the most misunderstood point in the lifecycle. The registrar decides when within those 45 days it sends the delete command: some delete around day twenty, some wait until day forty, and some route the name into their own expired-domain auction platform instead.

Recovery at this stage is normally just paying the renewal, possibly with a registrar-set late fee. This is the cheap window, and the one most registrants sleep through - partly because the public record can still look renewed.

When the website and the email actually stop working

The question registrants ask most is when the site goes down, and ERRP answers it precisely.

• If the registrar will delete the domain within 8 days of expiration, DNS resolution must be interrupted from expiration until deletion.
• If it will delete more than 8 days after expiration, resolution must be interrupted for at least the last eight consecutive days of the period during which renewal remains available.
• If it redirects the expired domain's traffic to a holding page, that page must state that the registration has expired and give renewal instructions.

So a domain may keep resolving for weeks after expiry, or go dark on day one. What is guaranteed is that it will be dark for at least the final eight days before deletion, and which pattern applies to you depends on your registrar's practice rather than on policy.

Email breaks at the same instant the website does, because the MX records stop resolving along with everything else. That is usually how the registrant finds out - from a bounced message rather than from any of the three mandated notices. Everything else dependent on the name fails at the same time: single sign-on, SPF and DKIM validation for mail sent from other systems, API callbacks and app deep links.

Deletion and the thirty days of the Redemption Grace Period

When the registrar issues the delete command, the registry places the domain into redemptionPeriod. This duration is genuinely ICANN-mandated: ERRP requires gTLD registries, other than the sponsored extensions carved out when it was adopted, to offer a 30-day Redemption Grace Period.

During RGP the registry must disable DNS resolution and prohibit attempted transfers, and the public record must show the status. The domain is completely dark, registration data is typically stripped from the record, and the name cannot be moved - a change of registrar requires restoring it first and transferring afterwards.

Recovery is possible, but it is a different operation from a renewal and costs materially more. It is a restore, an explicit registry command with constraints.

• Only the sponsoring registrar can request it. You cannot deal with the registry directly.
• The registry charges a wholesale restore fee, separate from and much larger than a renewal fee, which the registrar passes on with its own margin - plus a renewal term. You pay both.
• Under RFC 3915 the domain enters pendingRestore while the registry awaits a restore report containing the pre-deletion and post-restore registration data, timestamps, the reason for restoration and two signed statements.
• Some registrars do not perform restores at all, or only through a manual support ticket. No ICANN rule requires restore to be a self-service product.

This is the last stage at which the name is recoverable by right rather than by luck.

Pending delete: the genuine point of no return

After 30 days in redemption without a restore, the registry moves the domain to pendingDelete. The standard duration is five days. That figure is registry operational policy rather than an ICANN mandate - RFC 3915 leaves grace period durations to registries - but it is near-universal and appears as a published figure in registry lifecycle policies.

Nothing can be done during pendingDelete. The domain cannot be renewed, restored, transferred or updated. No fee retrieves it and no support ticket helps. Registrants routinely spend these five days negotiating with a registrar that has no mechanism to assist them. At the end of the period the name is purged and becomes available again, first-come first-served.

Note the two independent clocks, because a common miscalculation lives here. The 45 days is a maximum for the registrar, and the 30 plus 5 only begins when the registrar actually deletes. A registrant who assumes they have 75 days is wrong: a registrar that deletes on day five has given them 40.

The drop, and who really catches a good name

Historically gTLD drops happened in an unpredictable batch window, which is why a drop-catching industry exists: specialist registrars fire large volumes of registration attempts at the exact release moment on behalf of backorder customers. Be realistic about what that means. A desirable expiring name is caught within seconds by automated systems, not by whoever refreshes an availability page fastest. Attempting a registration by hand at the drop time is close to hopeless; a backorder with a drop-catch service is the only approach with a meaningful chance, and even then a caught name is often resolved through a private auction among that service's own customers.

The more important point is that valuable expiring names rarely reach an open drop at all. Most are intercepted much earlier, on the registrar's own expired-domain auction platform, during the auto-renew grace period and before any delete command is sent. A registrant who lets a good name lapse is far likelier to see it sold at auction than to see it drop.

Some registries have replaced the random drop with a published schedule. Nominet publishes daily drop lists for .uk giving each name's drop time in UTC, and states that domains no longer drop at random times.

Country-code registries do not follow this model

The sequence above applies to gTLDs under ICANN contract. Country-code registries set their own rules, and several differ substantially.

.uk (Nominet), effective 13 September 2022. Days 0 to 30 are an Expiry Grace Period in which the domain stays fully operational and renewable. Days 30 to 90 are a Redemption Grace Period: the domain goes into pendingDelete status and stops resolving, but renewal remains possible throughout. Days 90 to 95 are the Pending Delete Grace Period, still pendingDelete, now with a confirmed drop date and no renewal available. Note the trap: a .uk in pendingDelete may still be recoverable, whereas a gTLD in pendingDelete never is.

.eu (EURid). Deleted or lapsed names enter quarantine for 40 days, during which attached websites and email addresses stop working. Names deleted voluntarily or for non-payment can be reactivated by the holder or a registrar; names revoked by EURid for failing eligibility criteria only by EURid. After 40 days the name is released first-come, first-served.

.de (DENIC). No expiry model at all - registrations run under contract until terminated. DENIC's free TRANSIT service catches domains whose provider has stopped administering them: the name moves to DENICdirect, stays registered to the holder, and is unavailable to others while the holder decides whether to pay, move provider or delete. Miss the deadline in the TRANSIT letter and DENIC terminates the contract without notice.

The general rule: read the registry's own lifecycle. Redemption periods range from none at all to ninety days or more, and some registries reuse EPP status names with different meanings.

The short list of things that actually prevent this

Very few controls genuinely prevent expiry loss, and none is complicated.

• Register long and renew long. A ten-year term removes nine opportunities to forget, and it insulates you from price rises: registries must give six months of notice of an increase, and registrants may renew up to ten years at the pre-increase price.
• Point the registrant email at a monitored role address. All three mandated notices go to the address on file, and abandoned or filtered mailboxes are the commonest cause of accidental expiry.
• Keep auto-renew on and the payment method current. Auto-renew fails silently when a card expires.
• Set clientDeleteProhibited on anything that matters. This registrar-set status causes deletion requests to be rejected. It does not stop expiry, but it guards against accidental or malicious deletion.
• Diarise the expiry date independently of the registrar. Notices can be filtered; a calendar entry cannot.
• Monitor status codes rather than invoices. A domain showing autoRenewPeriod has already expired; one showing redemptionPeriod has been deleted and a 30-day clock is running. Check through RDAP, the definitive source for gTLD registration data since 28 January 2025.
• Keep a working login at your sponsoring registrar. Only it can request a restore.

What does not work is intending to remember. The lifecycle assumes registrants forget, which is why recovery costs rise at every stage and why the last five days offer no remedy.