Expiration is a sequence, not an event
A domain that expires does not vanish. It enters a defined sequence of grace periods — windows after a deadline in which an action can still be undone — and moves through them on a published schedule, with the cost of recovery rising at each step and the option disappearing at the end.
The day counts in this guide are the ones in the .com registry agreement, specifically Appendix 7, which is the operative contract for .com and the template most generic top-level domains follow. They are not universal. Other gTLDs may differ, and country-code TLDs such as .uk, .de and .ca run their own lifecycles entirely outside ICANN consensus policy. Check the registry for the TLD you actually have.
One more scope note before the numbers. ICANN's Expired Registration Recovery Policy (ERRP) — which sets the registrar's obligations around expiry notices and redemption — applies to all gTLD registries except sponsored TLDs, and all ICANN-accredited registrars and gTLD registries were required to comply by 31 August 2013.
Stage one: the Auto-Renew Grace Period, 45 days for .com
At expiry, the registry automatically renews the name and bills the registrar. Appendix 7 of the .com registry agreement gives the Auto-Renew Grace Period as 45 calendar days following that automatic renewal. During this window the registrar can delete the domain and receive a credit — which is exactly why registrars can and routinely do delete names well before day 45. Do not treat 45 days as a budget. It is the registrar's window, not yours.
The ERRP requires the registrar to give the Registrant at Expiration — whoever was the registered owner on the expiry date — an opportunity to renew during this period. It also permits the registrar to interrupt DNS resolution after expiration but before deletion, specifically to help make the registrant aware of the expiration.
That last point resolves a recurring panic. When the site goes dark after a missed renewal, that is usually a deliberate signal permitted by policy, not a hosting fault. Marketo's marketo.com outage in July 2017 ran roughly two and a half hours and ended when the nameservers were restored — after the company located its domain administrator, and after a customer had renewed the domain on its behalf.
Stage two: the Redemption Grace Period, 30 days for .com
Once the registrar deletes the name, it enters REDEMPTIONPERIOD — the Redemption Grace Period (RGP), the window during which only the previous registrant can restore it. Appendix 7 gives this as 30 calendar days for .com, and ICANN states the registrant-facing obligation plainly: your registrar must allow a domain in the 30-day RGP to be redeemed or restored before the end of the RGP.
What happens during RGP is fixed by the ERRP. DNS resolution is disabled, transfers are prohibited, and WHOIS must indicate RGP status. So the name is fully dark and cannot be moved to another registrar — you must go back to the registrar that deleted it.
Restoration carries a redemption or restore fee substantially above the normal renewal price. The ERRP requires that fee to be published and readily available to registrants, but does not set its amount, and it varies by registrar. Two consequences follow: find out what your registrar charges before you need it, and do not wait through RGP hoping the fee will fall. It will not, and day 31 costs you the option entirely rather than the money.
Stage three: Pending Delete, five days, nothing works
After the Redemption Grace Period the domain enters PENDING DELETE for five calendar days before it is purged. ICANN's registrant FAQ says the same: five days in PendingDelete before the name becomes available for public registration.
This stage needs one sentence of explanation and one of emphasis. The explanation: it is a queue, not a window. The emphasis: nothing can be done during Pending Delete. The domain cannot be restored, renewed, or transferred, by you, by your registrar, or by anyone else you pay to try. Believing otherwise is one of the most common misunderstandings in the whole lifecycle, and it costs people money paid to services that cannot deliver.
If a name you need is in Pending Delete, the correct use of those five days is preparation for what comes after the drop, not attempts to intervene before it.
Stage four: the drop, and who is waiting for it
At the end of Pending Delete the registry releases the name, first come first served. In theory it becomes available to anyone. In practice, any name with residual traffic, links or brand value is taken by drop-catching services — automated systems racing to register a name at the instant of release — rather than by an ordinary registrant refreshing a search page.
Once a third party holds the name, renewal is no longer the question. The remaining routes are commercial purchase or a dispute proceeding, and a dispute proceeding requires grounds. A lapsed registration alone is not one; if the new holder registered the name without targeting your trademark, a trademark-based procedure has nothing to work with.
There is a security dimension too. An expired domain that other people's DNS still references is a live vulnerability for them: OWASP records the expired-domain variant of subdomain takeover, where a CNAME record — an alias saying one name is really another — points at a domain that has since expired, and the attacker simply registers it. Letting a domain drop can hand someone a foothold in a partner's infrastructure, not just cost you a website.
Why the day counts come from the registry, not the protocol
It is worth understanding where these numbers actually live, because it explains why they differ between TLDs and why generic advice about them is so often wrong.
The status names — redemptionPeriod, pendingRestore, pendingDelete — are defined in RFC 3915, "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)," published in September 2004 as a Proposed Standard. That is why the same strings appear in WHOIS output regardless of which registrar you use. But RFC 3915 explicitly declines to set durations: the duration of each grace period is a matter of registry operational policy that the document does not address.
So the protocol standardizes the vocabulary and leaves the calendar to each registry. For .com, the calendar is in Appendix 7 of the registry agreement, which also gives Add, Renew/Extend and Transfer grace periods of five calendar days each. Sources that quote a single universal redemption period — some general references say 30 to 90 days — are describing a range across registries, not a rule. For .com it is 30 days; for anything else, read that registry's agreement.
Why renewals fail in the first place
The causes are mundane and highly repeatable.
- Renewal notices going to a dead address. The ERRP requires notices to be sent in a manner that does not require affirmative action to receive — worthless if the mailbox no longer exists. Registrars must send a reminder roughly one month before expiration, another roughly a week before, and at least one notice within five days after expiration.
- An expired card on file, so auto-renew fails silently. Marketo's chief executive publicly attributed its 2017 lapse to process errors with auto renewals as well as human errors.
- Registration in the wrong name — an employee's, a developer's, or an agency's — so the notice never reaches the business and nobody with authority sees it.
- Contact email at the domain itself, so when the domain lapses its own mail stops working and the warnings cannot arrive.
- Treating the dark site as a hosting problem and spending the RGP debugging DNS.
- Not knowing who the domain administrator is. Marketo had to locate its domain administrator before the nameservers could be corrected.
What good practice looks like
Everything that prevents expiry loss is unglamorous and cheap relative to a restore fee, let alone a buyback.
Register for multiple years and enable auto-renew, then verify annually that the payment method on file is current and not tied to someone who has left. Keep the registrant email on a domain you control that is not the domain being registered. Use a role address with a personal backup as the registrar account contact. Put the expiration date in your own calendar system, independently of the registrar's reminders — treat ERRP notices as a backstop rather than the system. Verify the expiry date directly in WHOIS or RDAP, the successor protocol for looking up registration data, rather than trusting a dashboard that may be reading stale data. Keep the registration in the company's legal name, with the company controlling both the registrar account and its recovery email.
And find out your registrar's published restore fee now, while it is a piece of trivia rather than an emergency. The ERRP requires it to be readily available. Knowing the number in advance is the difference between a fast decision and a lost week.