Expired Domain Loss

What actually happens on the expiry date

Expired-domain loss is what happens when a renewal is missed and the domain moves through a fixed sequence of grace periods — a grace period being a window after a deadline in which an action can still be undone — at rising cost, until it is deleted and anyone in the world can register it.

The sequence is not discretionary and it is not set by your registrar. For .com the day counts come from the registry's own contract, the .com Registry Agreement, Appendix 7, which is the authoritative source and the template most gTLDs follow (.com Registry Agreement, Appendix 7). It is worth knowing where the numbers do not come from: RFC 3915 defines the EPP status names you see in Whois but explicitly declines to set durations, stating that the duration of each grace period is a matter of registry operational policy not addressed in that document (RFC 3915). Durations come from the registry agreement, and they can differ by TLD.

The three numbers that matter are 45, 30 and 5. Everything below is those three numbers and what changes at each boundary.

Stage 1 — Auto-Renew Grace Period: 45 calendar days

At expiry the registry automatically renews the domain and bills the registrar. Appendix 7 gives the Auto-Renew Grace Period as 45 calendar days following that automatic renewal (Appendix 7). During this window the registrar can delete the domain and receive a credit for the renewal fee — which is precisely why registrars can and routinely do delete well before day 45, and why treating 45 days as your personal deadline is a mistake. It is the registry's window with the registrar, not a guarantee to you.

Your protection during this stage comes from a different instrument. ICANN's Expired Registration Recovery Policy requires the registrar to give the Registrant at Expiration — the ERRP's term for whoever was the registered owner on the expiry date — the opportunity to renew during this period (ICANN ERRP).

The ERRP also permits the registrar to interrupt DNS resolution after expiration but before deletion, specifically to help make the registrant aware of the expiration. This is the single most misdiagnosed moment in the whole lifecycle. The site going dark is not a hosting fault and not an outage. It is a deliberate signal, and the hours spent escalating it to a hosting provider are hours spent inside a window that is closing.

Stage 2 — Redemption Grace Period: 30 calendar days

Once the registrar deletes the domain, it enters REDEMPTIONPERIOD for 30 calendar days (Appendix 7). The Redemption Grace Period is the window after deletion in which only the former registrant can restore the name. ICANN states the registrant-facing obligation plainly: your registrar must allow a domain name in the 30-day Redemption Grace Period to be redeemed, or restored, before the end of that period.

What the ERRP requires during RGP is worth knowing because it explains the symptoms (ICANN ERRP): DNS must be disabled, transfers must be prohibited, and Whois must indicate the RGP status. So the domain is dark, you cannot move it to a registrar who is easier to deal with, and the record is publicly visible as redeemable — which is also how the drop-catching industry knows exactly when it will become available.

Restoration carries a redemption or restore fee substantially above the renewal price. The ERRP requires each registrar to publish that fee and make it readily available to registrants, but does not set the amount, so it varies. It does not decline as the period runs. Waiting through RGP in the hope that it will is a strategy I have seen end at day 31 with nothing left to buy.

Stage 3 — Pending Delete: 5 calendar days, and nothing can be done

After the Redemption Grace Period the domain enters PENDING DELETE for five calendar days before it is purged (Appendix 7). ICANN's registrant FAQ describes the same five-day status before the name becomes available for public registration.

State this to clients in the plainest possible terms, because it is the one stage people refuse to believe: nothing can be done during Pending Delete. The domain cannot be restored, renewed or transferred. There is no fee that changes the outcome and no registrar with a better relationship. The name is queued for release and the queue does not accept appeals.

The five days are not a final chance. They are notice.

Stage 4 — the drop, and who is actually waiting

At the end of Pending Delete the registry releases the name, first come first served. In theory it returns to the general pool. In practice, any name with existing traffic, backlinks or trademark value is taken by automated drop-catching services — systems that race to register a name at the instant of release — rather than being available to whoever happens to look that afternoon.

This is the boundary that changes the nature of the problem. Up to day 80 or so you have a renewal problem with a known price structure. After the drop, if a third party has registered the name, you have an acquisition problem or a dispute, and the routes are purchase from the new registrant or a proceeding such as the UDRP where the facts support one. Both are slower and less certain than any restore fee, and a dispute requires counsel. Neither is renewal.

There is a security consequence too. A dropped domain that other people's DNS records still point at — a CNAME chain, an SPF include, a vendor integration — hands the new registrant everything those references confer.

The notice schedule, and its single point of failure

The ERRP sets a notification schedule that runs before the sequence above rather than during it (ICANN ERRP):

• A first expiry reminder approximately one month before expiration, with registrar flexibility of 26 to 35 days.
• A second reminder approximately one week before expiration, with flexibility of 4 to 10 days.
• At least one post-expiration notice, within 5 days after expiration.

The policy requires these to be sent in a manner that does not require affirmative action to receive. All three go to the registrant contact on file, which makes that address the single point of failure for the entire regime. If it belongs to a departed employee, a decommissioned mailbox, or — the version that is genuinely circular — the expiring domain itself, then every notice ICANN requires is delivered correctly to nobody.

The scope caveat matters as well. These are gTLD rules. ccTLDs such as .uk, .de and .ca operate their own lifecycles with different day counts and sit outside ICANN consensus policy entirely, so check the relevant registry rather than assuming 45, 30 and 5.

How this happens to organizations that are paying attention

Expiry is rarely a decision. It is usually a small administrative gap that nobody owns.

• The renewal notice goes to a stale registrant address, so every required notification is technically sent and practically invisible.
• Auto-renew is enabled but the card on file expired, belonged to a former employee, or was declined once and never retried.
• The domain was registered in an employee's, developer's or agency's name, so the notices reach someone with no reason to act on them.
• The site going dark is escalated as a hosting incident, spending the very window the darkness was meant to flag.
• Nobody internally knows who the domain administrator is, so even after the cause is identified there is a delay before anyone can log in.

The publicly documented case that illustrates the whole pattern is Marketo in July 2017. The company failed to renew its primary domain, its services went offline for roughly two and a half hours, and a customer noticed and renewed the domain before the company did — after which Marketo had to locate its own domain administrator before the nameservers could be corrected. Its chief executive publicly attributed the failure to process errors with auto-renewals as well as human errors. Every element there is procedural. None of it required an adversary.

What good practice looks like

• Register for multiple years and enable auto-renew, then verify annually that the payment method on file is current and not tied to a departed employee.
• Keep the registrant email on a domain you control that is not the domain being registered. If the domain lapses, its own mail stops working, and the notices about the lapse go into the outage they are describing.
• Use a role address plus a personal backup as registrar account contacts, so that one departure does not orphan the account.
• Diarize the expiry date independently of the registrar's reminders. Treat ERRP notices as a backstop, not as the system.
• Verify the expiry date in Whois or RDAP directly — RDAP being the successor protocol for looking up registration data — rather than trusting a dashboard that may be showing you a cached or aggregated value.
• Keep the registration in the company's legal name, with the company controlling the registrar account and its recovery email. This is also what makes ownership provable later, which is a separate and larger problem.
• Know your registrar's published restore fee before you need it. The ERRP requires it to be readily available; finding it at speed on day two of an RGP is not the moment to discover it is not.

One structural point. Almost every item above is cheap and preventive, and the entire cost curve of this failure runs the other way — renewal, then restore fee, then acquisition or dispute. There is no stage at which acting later is cheaper than acting now.

Frequently Asked Questions