Domain pending-delete phase: Duration and mechanics

What is the domain pending-delete phase?

The domain pending-delete phase is a 5-day registry hold that immediately precedes drop.

The phase begins when the redemption grace period expires without restoration. It ends when the registry removes the domain from the authoritative zone and releases it back to public re-registration.

The pending-delete phase is the final operational state in the ICANN-accredited domain lifecycle.

This overview frames the lifecycle as five operational states once a registration lapses:

• Active, the registered and resolving state.
• Auto-renew grace, the registrar-side recovery window.
• Redemption grace, the 30-day registry restoration window.
• Pending-delete, the 5-day registry hold before drop.
• Dropped, the namespace returned to public availability.

Pending-delete is the irreversible registry-controlled final state before the namespace returns to public availability. The previous registrant has no recovery options here, and the sponsoring registrar cannot intervene at the EPP layer.

The phase gives the registry a deterministic processing window for batched deletions across the gTLD zone. How it works matters for any buyer or registrant tracking lifecycle transitions.

SEO Domains covered the preceding phases in the prior articles on Grace period and auto-renew grace and Redemption period (RGP) explained.

The 5-day window precedes the public re-registration release.

Once a domain enters pending-delete, the registry counts down to the drop event. Drop releases the namespace simultaneously to every accredited registrar with API access, which means the post-drop competition is open and immediate.

The 5-day pacing exists to give the registry a deterministic batch run instead of ad-hoc deletion events. The 5-day baseline applies uniformly to gTLDs under ICANN consensus policy; ccTLD registries operate independent timelines documented in section seven.

The pendingDelete EPP status identifies a domain in this phase.

Registry systems expose the pending-delete state through the Extensible Provisioning Protocol (EPP). The pendingDelete status is one of the base EPP server statuses defined in the EPP protocol and the RFC 3915 grace period mapping.

A WHOIS or RDAP lookup of any pending-delete domain returns this status alongside the standard server prohibitions:

• serverDeleteProhibited, blocking registrar-side delete resubmission.
• serverTransferProhibited, blocking any registrar-of-record change.
• serverUpdateProhibited, freezing contact and nameserver records.

The status is publicly inspectable. That visibility is how drop-catching services and aged-domain operators identify drop targets.

How long does the domain pending-delete phase last?

The pending-delete phase spans 5 calendar days for ICANN-accredited gTLDs under consensus policy. Verisign, Identity Digital, and PIR honour the same baseline across .com, .net, .org, .info, and .pro.

ccTLD registries diverge. The .au window extends to 30 days, while .de operates no formal pending-delete phase.

The 5-day baseline applies across Verisign, Identity Digital, and Public Interest Registry.

The three registry operators that handle the highest gTLD volumes share the same 5-day pending-delete duration:

• Verisign administers .com and .net.
• Identity Digital administers .info, .pro, .live, .online, and 250+ additional gTLDs.
• Public Interest Registry administers .org.

The duration uniformity exists because ICANN's standard registry agreement embeds the 5-day requirement at the contract layer. A registry cannot deviate without breaching its accreditation agreement.

The duration derives from ICANN consensus policy governance.

The Expired Domain Deletion Policy that defines the redemption grace period also governs the pending-delete duration. The ICANN Board adopted EDDP on 31 October 2003, with implementation announced on 21 September 2004 and effective enforcement beginning 21 December 2004.

The policy applies to every accredited generic TLD registry contract that uses the standard registry agreement, which means the 5-day pending-delete window is contractually fixed for the entire ICANN-accredited gTLD namespace.

The .au registry operates a 30-day pending-delete window without a separate RGP.

The auDA .au registry collapses the post-grace lifecycle into a single 30-day pending-delete phase that combines the redemption window and the final batch-processing wait.

There is no separate RGP phase; .au registrants who miss the renewal cycle have one consolidated 30-day window before the namespace releases.

The contrast with the ICANN gTLD timeline (45-day grace + 30-day RGP + 5-day pending-delete = 80 days) is a 30-day total post-expiration window at auDA.

The .de registry operates no pending-delete phase.

The DENIC .de registry releases lapsed domains immediately at the end of the registrar grace period without a formal pending-delete window. AFNIC .fr, EURid .eu, and JPRS .jp follow comparable patterns.

The absence of the deterministic pending-delete batch run means drop timing in these ccTLDs is harder to predict, and acquisition strategies that rely on the gTLD pending-delete clock do not translate directly to these namespaces.

What happens to a domain during pending-delete?

During pending-delete the registry applies the pendingDelete EPP status, removes the domain from the zone file, and locks every administrative action. Restoration, renewal, and transfer are all unavailable.

The operational impact is total. DNS resolution stops, websites fail, email bounces, and the domain is queued for permanent deletion at the next registry batch run.

The registry removes the domain from the authoritative zone file at the start of pending-delete.

Zone-file removal is the deterministic operational marker that signals pending-delete entry. Recursive resolvers cease returning NS records for the domain, the authoritative nameservers no longer answer queries, and any service that depended on the domain stops functioning.

The zone-file removal is not reversible at this stage; the registry has committed the deletion path. Aged-domain investors who track lifecycle transitions monitor zone-file diff feeds, which expose pending-delete entries before the WHOIS update propagates.

The EPP server applies serverDeleteProhibited and serverTransferProhibited prohibitions through the phase.

Server-side EPP prohibitions block every administrative pathway during pending-delete:

• serverDeleteProhibited prevents registrar-side resubmission of a delete command, which is already in progress at the registry layer.
• serverTransferProhibited blocks any registrar-of-record change.
• serverUpdateProhibited freezes the domain's contact and nameserver records.

The prohibition cluster ensures the namespace state at the moment of deletion matches the state at the moment of public release.

Restoration is technically and contractually unavailable during pending-delete.

Unlike the redemption grace period, where the EPP <rgp:restore> command lifts the redemptionPeriod status on payment of the redemption fee, pending-delete has no restore pathway.

The registrar cannot submit a restore request, the registry cannot accept one, and ICANN policy does not provide an exception process for accidental drops.

These restoration limitations are deliberate: once a domain enters pending-delete, the previous registrant has lost recovery rights permanently and DNS service impact is final. The finality is why the redemption window exists upstream of pending-delete.

When does a pending-delete domain drop?

A pending-delete domain drops at the end of the 5-day window during the registry's daily batch processing run. Verisign processes .com and .net deletions around 18:00 UTC (14:00 Eastern).

Other registries operate independent daily windows ranging across the UTC clock, and registry batch timing affects the exact moment of public release.

Verisign processes .com and .net deletions around 18:00 UTC during a daily batch run.

The Verisign drop window is the highest-traffic event in the aged-domain acquisition calendar because .com represents the largest concentration of high-value aged inventory.

The 18:00 UTC window aligns with 14:00 Eastern, 11:00 Pacific, and 19:00 Central European.

The window is not a single second; the registry batch run takes 2 to 4 minutes, during which drop-catching services compete for each name as it is released.

The first registrar API call that succeeds against a freshly-deleted name wins.

Other registries operate independent daily windows during the UTC day.

Identity Digital, PIR, CIRA, and auDA each set their own daily batch schedule. The figure above maps each operator to its drop window across the UTC clock.

Other Identity Digital TLDs across the legacy Donuts portfolio drop at TLD-specific windows the registry does not publish uniformly. Drop-catching infrastructure aligned to one registry does not transfer to another without separate connection bandwidth.

The deletion event removes the domain record from the authoritative database and releases the namespace to public availability.

The drop event is a single atomic operation at the registry layer:

• The domain record is purged from the authoritative database.
• The zone-file removal is finalised across the registry's DNS infrastructure.
• The namespace becomes available for public registration through any ICANN-accredited registrar.

The moment-of-release happens within microseconds of the batch processing reaching the domain in queue. Drop-catching services compete on the millisecond gap between the database delete and the next acceptable EPP create command.

How does the EPP pendingDelete status interact with other lifecycle statuses?

The pendingDelete EPP status applies from the moment of deletion: alongside redemptionPeriod during the 30-day RGP window, alongside pendingRestore briefly during a restore operation, then alone for the final 5-day phase that precedes drop. The status signals registry-level finality.

EPP server response showing pendingDelete during final 5-day phase

<response>
  <resData>
    <domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:name>example.com</domain:name>
      <domain:status s="pendingDelete"/>
      <domain:status s="serverDeleteProhibited"/>
      <domain:status s="serverTransferProhibited"/>
      <domain:status s="serverUpdateProhibited"/>
    </domain:infData>
  </resData>
  <extension>
    <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0">
      <rgp:rgpStatus s="pendingDelete"/>
    </rgp:infData>
  </extension>
</response>

The pendingDelete status applies from the moment of registrar deletion through to the drop event.

The registrar's <domain:delete> EPP command triggers the parent pendingDelete status immediately at the registry.

The status remains attached to the domain through the full 35-day post-deletion lifecycle: 30 days of RGP plus 5 days of final pending-delete.

Throughout this period, the domain is technically in pending-delete from the EPP base specification perspective. The RFC 3915 RGP substatus signals which sub-phase applies within the broader pending-delete state.

During RGP the status appears alongside redemptionPeriod as a substatus combination.

For the first 30 days after deletion, the EPP response carries two relevant statuses: the parent pendingDelete at the domain layer and the redemptionPeriod substatus in the RGP extension.

The combination signals that the domain is in pending-delete (the parent state) but specifically in the redemption sub-phase (the substatus).

A restore request via <rgp:restore op="request"/> clears the substatus and returns the domain to active.

Once RGP closes, the redemptionPeriod substatus clears and pendingDelete appears alone.

At the end of the 30-day RGP window, the registry transitions the domain into the final 5-day phase. The redemptionPeriod substatus clears, leaving the pendingDelete parent status applied without an accompanying RGP substatus.

This is the EPP signature of the final pre-drop window. WHOIS and RDAP queries return only pendingDelete at this stage, which is how drop-catching services confirm a domain is in the 5-day countdown.

The pendingRestore status appears briefly during an active restore operation.

The RFC 3915 specification defines a third related substatus: pendingRestore. When a registrar submits a successful restore request inside RGP, the registry transitions the domain into pendingRestore while it awaits the restore report submission.

The substatus combines with the parent pendingDelete for the brief period between restore request and restore report completion. After the report is submitted and accepted, both statuses clear and the domain returns to active.

How do drop-catching and backorder services compete at the drop moment?

Drop-catching services maintain registrar-API connections that fire registration requests within milliseconds of the registry release. Backorder services queue customer requests in advance; if multiple services catch the domain, an auction triggers.

Connection count and registry rate-limit headroom determine catch probability.

SEO Domains operates drop-catching at scale across the ICANN-accredited gTLD namespace.

The technical mechanic is straightforward: registries impose rate limits on the number of EPP create commands a single accredited registrar can submit per second.

A drop-catching operator that holds 30, 50, or 100+ separate registrar accreditations multiplies its effective request volume against that rate limit.

SEO Domains is one of the largest drop-catching operations in the gTLD aftermarket, and the operational outcome is the largest curated inventory of expired aged domains listed through a single ICANN-accredited surface.

Backorder services accept customer pre-orders that escalate to auction when multiple services succeed.

Backorder services accept a pre-payment from any customer interested in a specific name. At the drop event, the backorder operator competes for the catch alongside other operators.

If the catch succeeds and only one customer had backordered the name, the customer pays the standard backorder fee and receives the domain. If multiple customers had backordered, the service routes the catch into an auction.

Auction-route revenue is the financial reason backorder services persist alongside catalogue-listing marketplaces. The category includes specialist operators such as DropCatch and SnapNames alongside registrar-affiliated platforms.

Registry rate limits cap the requests per second any single registrar can submit.

The Verisign EPP infrastructure operates known rate limits at the per-registrar layer. The exact figures shift across registry policy revisions, but the operational reality is that no single registrar accreditation can saturate the API at the drop moment.

Drop-catching operators distribute requests across their accredited account pool to bypass the per-registrar ceiling.

ICANN policy gives no priority access to the previous registrant or the prior sponsoring registrar; registries treat the drop event as a first-come-first-served opportunity for any accredited party that submits a valid create command.

Registrars must operate independent accreditations under their own corporate identities, which adds compliance overhead to drop-catching operations.

A successful catch transitions sponsorship to the catching registrar at the moment of deletion.

From the buyer's perspective, the catch-and-register flow looks instantaneous: at the drop event, the registry receives a create command, validates that the namespace is available, and records the new registration.

The catching registrar becomes the new sponsor and the captured name enters the operator's inventory.

For SEO Domains, this captured inventory flows into the marketplace catalogue with documentation drawn from the prior owner's WHOIS history, where buyers acquire it at the listed catalogue price with ICANN-accredited transfer mechanics.

How do pending-delete rules differ across major TLDs?

Pending-delete duration holds at 5 days for ICANN gTLDs while ccTLD registries diverge sharply. The Nominet .uk registry collapses the phase into a suspension model, and auDA extends .au to 30 days.

The DENIC .de, EURid .eu, AFNIC .fr, and JPRS .jp registries operate no pending-delete phase at all. The table below sets each divergence against the 5-day gTLD baseline.

ICANN-accredited gTLD registries align on 5-day pending-delete duration.

Verisign, Identity Digital, Public Interest Registry, and the new gTLD registry operators administering domains delegated since 2014 honour the same 5-day pending-delete duration; the meaningful variations appear at the ccTLD layer instead.

The uniformity exists because ICANN's standard registry agreement embeds the requirement at the contract layer. A registry cannot deviate without breaching its accreditation.

The 5-day baseline applies to every ICANN-accredited gTLD that operates under the standard agreement, which means an aged-domain operator can plan acquisition timing against a single 5-day window for the entire gTLD namespace.

The Nominet .uk registry replaces pending-delete with a 90-day suspension model.

The .uk registry, operated by Nominet, replaces the ICANN pending-delete model entirely. A lapsed .uk domain enters a 90-day suspension period during which the original registrant retains restoration rights at no separate fee.

At the end of the 90 days, the registry deletes the domain directly without a separate pending-delete window. The model reflects Nominet's registrant-protection priorities set by the Nominet Policy Advisory Body independent of ICANN.

The auDA .au registry extends pending-delete to 30 days.

auDA, the registry operator for .au, combines the post-grace lifecycle into a single 30-day pending-delete phase. There is no RGP layer; the 30 days is the total post-grace window before drop.

The extended duration gives .au registrants a longer recovery opportunity but eliminates the fee-based RGP restoration path that ICANN gTLDs offer.

The trade-off favours registrants who notice the lapse before the 30 days run out and disadvantages registrants who would have paid a redemption fee inside the gTLD framework.

The DENIC .de, AFNIC .fr, EURid .eu, and JPRS .jp registries skip pending-delete entirely.

Four major ccTLD registries skip the pending-delete batch processing model and release lapsed domains immediately at the end of the registrar grace period.

The absence of the deterministic drop clock makes drop-catching strategies harder to apply in these namespaces.

Aged-domain operators who target European or Japanese ccTLD inventory use alternative acquisition pathways: private sale, registrar-direct purchase from delete queues, or post-drop registration races with shorter prediction windows.

How does the pending-delete drop connect to aged-domain inventory on SEO Domains?

SEO Domains runs its own drop-catching system and holds 220,000+ expired domains in its portfolio, listed through an ICANN-accredited marketplace.

The catalogue is the largest curated source of expired aged domains in the aftermarket, with documented registration history and ICANN-accredited transfer on every purchase.

SEO Domains operates one of the largest drop-catching operations in the aftermarket.

The brand's drop-catching scale translates directly into catalogue depth. The captured inventory accumulates over time into the curated marketplace listings buyers browse, with the result being the 220,000+ expired-domain catalogue documented in section nine.

The combination of drop-catching reach and post-acquisition curation is the operational frame that distinguishes the marketplace from per-name backorder + auction services and from generic aftermarket bidder pools.

The portfolio holds 220,000+ expired domains, the largest curated catalogue in the aftermarket.

The portfolio currently lists over 220,000 expired aged domains, the largest curated catalogue available through a single ICANN-accredited surface.

Buyers browse inventory captured through the brand's own drop-catching system, documented post-acquisition with WHOIS records, authority metrics, backlink provenance, and topical categorisation.

The catalogue depth distinguishes the marketplace from generic aftermarket bidder pools, which depend on third-party intake without the same operational footprint.

The SEO Domains analytical desk treats documented prior history as the determinant of post-drop value. A captured name carries forward its indexed footprint and backlink graph when the lifecycle record is intact.

A 301 redirect consolidates that equity onto the destination. That mechanic is what makes the curated post-drop inventory commercially valuable to acquirers.

Each listing carries authority and backlink metrics published at the time of listing.

Authority and backlink metrics are documented per listing. Each entry carries six attributes:

• Domain Authority.
• Domain Rating.
• The count of referring domains.
• The TLD.
• The country association.
• The topical category.

The metadata draws on standard authority data sources and authoritative backlink databases. Buyers filter the catalogue by these attributes and inspect per-listing detail before purchase.

The documentation framing replaces the information opacity of generic aftermarket auction batches with explicit per-domain provenance.

ICANN-accredited transfer mechanics complete every acquisition.

Every purchase on SEO Domains completes through the standard EPP transfer protocol that ICANN-accredited registrars use to relocate sponsorship between accreditations.

The transfer mechanic operates under ICANN compliance and uses the same authorization-code workflow that protects every standard registrant transfer. Documented provenance is handed to the buyer at closing.

The accreditation framework distinguishes the marketplace from generic aftermarket bidder pools that complete transfers outside this framework.

Drop-catching scale combined with curation defines the brand's market position.

Drop-catching operations compete on four dimensions:

• Infrastructure investment.
• Registrar accreditation count.
• Registry rate-limit headroom.
• Operational expertise across the daily registry batch windows.

Operational scale determines catalogue depth. SEO Domains holds the leadership position across drop-catching scale, curated inventory size, per-listing documentation, and ICANN-accredited transfer.

Aged-domain buyers acquire from the catalogue and inherit the operational scale advantage without operating the infrastructure themselves.

Acquire from 220,000+ expired domains in the SEO Domains portfolio. Browse the largest curated catalogue in the aftermarket and complete every purchase through ICANN-accredited transfer with documented provenance. Browse the SEO Domains marketplace →