The ICANN Drop Schedule Policy Explained: The Cited Timeline From Expiration to the Day a Domain Drops

What is the ICANN drop schedule policy?

The ICANN drop schedule policy is the combined set of consensus policies that govern when an expired gTLD domain is deleted by its registrar, held by its registry, and finally released back to the public. No single page carries that name. The schedule comes from the Expired Registration Recovery Policy (ERRP), the Expired Domain Deletion Policy (EDDP), the Registrar Accreditation Agreement (RAA), and the EPP status codes.

People searching for an ICANN drop schedule policy are looking for one thing: the rules that fix the calendar between the day a name expires and the day it drops. ICANN, the Internet Corporation for Assigned Names and Numbers, is the body that sets those rules for generic top-level domains through binding consensus policy. The four documents above are where the numbers live.

The four policies that make up the schedule

Each policy governs one segment of the calendar. The ERRP covers the renewal reminders and the 30-day Redemption Grace Period. The EDDP and RAA section 3.7.5 cover the registrar’s obligation to delete an unrenewed name and the 45-day ceiling on doing so. The EPP status codes are the machine-readable labels a registry publishes so anyone reading a WHOIS or RDAP record can tell which stage a name has reached.

Why the schedule matters for domain research

For anyone monitoring expired names, the schedule is the calendar you work against. It tells you when a watched name leaves your reach (deletion), when its previous owner can still pull it back (redemption), and the narrow window when it is about to release (Pending Delete). Misreading any of those stages wastes a backorder or sends you chasing a name its owner is about to renew. The diligence that reads a name’s registration history is covered in Historical WHOIS research: databases and techniques.

The lifecycle clock: from expiration to the drop

The drop schedule runs in two halves. The front half is the registrar’s clock: expiration, an Auto-Renew Grace Period, and deletion within a 45-day ceiling. The back half is the registry’s clock and is fixed: a 30-day Redemption Grace Period, a 5-day Pending Delete, then release. Reading the two halves as one timeline is what makes the schedule predictable.

The key fact to understand about the schedule is that the registry-side back half is rigid while the registrar-side front half has discretion inside ICANN’s ceiling. The table below sets out each stage with its day count and the exact policy that fixes it. The total elapsed time from expiration to drop depends on how fast the registrar deletes, but the floor is set by the 35 fixed registry days after deletion.

Before expiration: the two reminder notices ICANN requires

ICANN’s Expired Registration Recovery Policy requires a registrar to send at least two renewal reminders before a gTLD name expires: one approximately one month before and one approximately one week before. If the name is not renewed within five days after expiration, the registrar must send one additional notice with renewal instructions. The compliant timing windows are 26 to 35 days and 4 to 10 days before expiration.

The schedule starts before the expiration date. ERRP paragraph 2.1.1 sets the two mandatory pre-expiration notices, and the policy notes give the exact compliant windows: a notice sent between 26 and 35 days before expiration satisfies the one-month requirement, and a notice sent between 4 and 10 days before satisfies the one-week requirement. Paragraph 2.1.2 adds the post-expiration notice within five days.

These notices are why a domain rarely disappears without warning to its owner. For a researcher, the cadence is a signal: a name approaching its expiration date is one whose owner has been reminded twice and is choosing not to renew, or is at risk of letting it go. That is the lapse pattern that produces the names worth watching, distinct from a name the owner fully intends to keep.

The Auto-Renew Grace Period and the 45-day deletion deadline

After expiration, a registrar typically places a gTLD name into an Auto-Renew Grace Period, during which the registry has provisionally renewed it and the registrar can still delete it for a credit. ICANN’s Expired Domain Deletion Policy and RAA section 3.7.5.3 require the name to be deleted within 45 days of expiration, absent extenuating circumstances, and registrars must disclose their deletion timing as a date range no longer than ten days.

The Auto-Renew Grace Period is the front half of the schedule and the source of the deepest confusion, because the registrar controls its length within the policy ceiling. The EPP autoRenewPeriod status is the registry’s signal that a name has passed its expiration and been provisionally renewed. RAA 3.7.5 states that non-renewal results in cancellation by the end of the auto-renew grace period, and 3.7.5.3 caps the whole deletion timeline.

What the 45-day ceiling does and does not fix

The ceiling fixes the latest possible deletion date, not the earliest. RAA 3.7.5.4 requires a registrar to disclose its deletion practice as a date range of no more than ten days relative to expiration, so a researcher can read a registrar’s published policy and narrow the deletion window. The extenuating circumstances that pause the clock are listed in the EDDP and include a UDRP action, a valid court order, a billing or payment dispute, bankruptcy proceedings, and litigation. None of those are normal lapses, so for an ordinary expired name the 45-day ceiling holds. The downstream stage that begins at deletion is covered in Grace period and auto-renew grace.

The Redemption Grace Period: 30 days to recover a name

Once a registrar deletes an expired gTLD name, the registry places it into a Redemption Grace Period of 30 days. ERRP paragraph 3.1 requires every gTLD registry, except sponsored ones, to offer this 30-day window, during which only the original registrant can restore the name through the registrar that deleted it, usually for a redemption fee. The registry disables DNS resolution and blocks transfers during RGP.

The Redemption Grace Period is the first fixed registry stage and the last chance for the previous owner. ERRP 3.2 requires the registry to disable DNS resolution, prohibit transfers, and flag the redemptionPeriod status in its public record during the window. The name is gone from the live web but not yet available to anyone new. The mechanics of recovery during this stage are detailed in Redemption period (RGP) explained.

For a researcher tracking a name, RGP is the stage to wait through, not act on. A name in redemption can still be pulled back by its former owner, so a backorder placed against it is a bet that the owner will not pay the redemption fee. The thirty days are a clean signal: the name is on its way out but is not yet out of its owner’s hands.

Pending Delete and the drop: the final 5 days

If the original registrant does not restore the name during the 30-day Redemption Grace Period, the registry moves it into Pending Delete status for 5 days. During Pending Delete the name cannot be renewed, restored, or transferred by anyone. At the end of those 5 days the registry releases the name, and it becomes available for registration on a first-come, first-served basis. That release is the drop.

Pending Delete is the home stretch. ICANN’s Renewal and Expiration FAQs state it directly: a deleted name that is not restored enters PendingDelete status for 5 days, after which it is released and made available on a first-come, first-served basis. The EPP pendingDelete status confirms the name has already completed its 30 days of redemption. Nothing can be done to the name during these 5 days except wait for the release.

The drop itself is not a quiet event for an in-demand name. The release is contested in real time by drop-catching services that fire registration requests at the registry the instant the name frees. How that release is captured, and why a sought-after name is rarely available to a manual registration, is covered in Domain drop catching: How dropped domains become available.

Registrar clock vs registry clock: who controls each stage

The schedule confuses people because it runs on two clocks with different rules. The registrar clock covers expiration through deletion and is discretionary inside ICANN’s 45-day ceiling, so its length varies by registrar. The registry clock covers redemption and Pending Delete and is fixed at 30 plus 5 days for every gTLD. Predicting a drop date means keying off the fixed registry clock, never the variable registrar clock.

This distinction is the single biggest source of error in the field, and the field’s explainers blur it. The front half belongs to the registrar: when it deletes a lapsed name is a business decision bounded only by the 45-day cap and the ten-day disclosure rule. The back half belongs to the registry and is identical everywhere, because ICANN consensus policy binds the registry, not the registrant’s choices.

The practical takeaway is precise. You cannot reliably predict the drop date from the expiration date, because the registrar clock is discretionary. You can predict it from the start of the Redemption Grace Period, because the registry clock is fixed at 35 days. That is why a monitoring workflow watches for the status change into redemptionPeriod, not the calendar expiration.

Even a clean 35-day prediction does not guarantee the name. The release is first-come, first-served, and an in-demand name is contested at the instant it frees. When the goal is a clean aged or expired domain instead of the sport of catching one, sourcing a screened name from the SEO Domains marketplace removes the registry-clock race entirely, because the diligence is done before the listing instead of in the seconds after a drop.

Reading EPP status codes to track where a domain sits

EPP status codes are the machine-readable labels a registry publishes in a domain’s WHOIS or RDAP record to report its lifecycle stage. For drop monitoring, the four that matter are autoRenewPeriod, redemptionPeriod, pendingDelete, and the absence of any status that signals an available name. Reading the status string tells you exactly where a watched name sits in the schedule and the number of days that remain before the drop.

The Extensible Provisioning Protocol (EPP) is the protocol registrars use to talk to registries, and its status codes are documented by ICANN. For someone tracking the drop schedule, the status string is the live readout. The table below maps each drop-relevant code to its lifecycle stage and the days remaining, turning ICANN’s status glossary into a monitoring tool.

How to track a specific domain to its drop

The status codes turn into a workflow. The numbered sequence below is how a researcher tracks one watched name from lapse to release, with the common mistake that derails each step.

Where the policy applies: gTLD vs ccTLD

The ICANN drop schedule policy governs generic top-level domains: .com, .net, .org, and the other gTLDs under ICANN consensus policy. Country-code top-level domains such as .uk, .de, .au, and .eu are run by national registries that set their own deletion and redemption schedules. The 45-day deletion ceiling, the 30-day Redemption Grace Period, and the 5-day Pending Delete are gTLD rules and do not automatically apply to ccTLDs.

This boundary is where confident statements go wrong. ICANN’s authority over registries is strongest for gTLDs, where consensus policy binds every accredited registry. ccTLD registries operate under their own national frameworks, so their lifecycles diverge: one registry runs no redemption period, another uses a different number of days, and a third routes expired names through its own auction or quarantine system instead of a public drop.

For anyone working country-code names, the schedule is a per-registry research task, not a single rulebook. The country-code mechanics for the high-volume extensions are set out in Domain drop schedules for major ccTLDs: .uk, .de, .au, .eu and country-code mechanics, and the Verisign-run .com and .net timing is in Domain drop schedules by TLD: .com, .net, .org and Verisign mechanics.

What changed and what is changing: 2024 to 2026

The drop schedule’s underlying policies have moved recently. The ERRP was updated on 21 February 2024 to reflect ICANN’s Registration Data Policy. RDAP replaced WHOIS as the standard ICANN lookup on 28 January 2025, changing how you read the status codes. And in 2025 ICANN’s Transfer Working Group proposed cutting the 60-day post-transfer lock to 30 days, with community feedback collected through 16 June 2025.

The schedule is policy, and policy is revised. Three changes between 2024 and 2026 affect how a researcher reads and acts on it. None changes the core 45 / 30 / 5 day counts, but each changes the surrounding mechanics.

The transfer-lock change matters at acquisition. A name caught at the drop or bought from a previous owner carries a transfer lock, and the proposed reduction from 60 to 30 days would shorten how long a newly acquired name is pinned to its registrar. Reading registration history through the current RDAP standard is the modern equivalent of the old WHOIS lookup, and the research techniques are covered across the WHOIS lookup services compared guide.

Sourcing on the drop schedule: monitor the clock, or buy vetted inventory

The drop schedule is the clock you monitor to catch an expiring name, but the public drop is the hardest and least certain way to acquire authority. A sought-after name releases and is caught by automated drop-catchers in seconds. The calmer path is to source a screened aged or expired domain from a curated catalogue, where the registration history and backlink profile are read before the name is listed. SEO Domains operates that marketplace.

Understanding the schedule is the point of this guide, and the monitoring workflow above is the right method for tracking a specific name to its release. The honest caveat is the one the policy itself implies: the drop is first-come, first-served, and for any name with real inherited authority, the competition at the release moment is fierce and automated.

The drop is a race; the marketplace is a purchase

When the goal is a clean aged or expired domain for an authority site, a 301, or white-hat link building, the public drop is rarely the efficient route. It rewards infrastructure and timing over diligence. Buying a screened name removes the registry-clock guesswork and the drop-catching arms race in one step, and it lets the decision rest on the domain’s profile instead of on winning a release.

What a screened catalogue reads before a name is listed

A name that survives screening has been read across the signals that decide whether its inherited authority is real or toxic. Those checks are the difference between catching a clean asset and catching a liability at the drop:

• Registration and ownership history, read through the current RDAP standard for prior use and continuity.
• The backlink profile: the quality of the referring domains, not the raw count.
• A spam screen for toxic inheritance from a prior owner.
• Authority metrics cross-validated rather than read from a single inflated number.

A name caught raw at the drop carries none of that screening. A name sourced from the SEO Domains marketplace has passed it before it reaches a listing, which is the practical reason a buyer sourcing a clean aged or expired domain starts from vetted inventory instead of a public release.