If you are using domain drop-catching software such as Auto DropCatch, knowing the date that a domain will be deleted is only half of the job.

You also need to know when the registry actually releases domains for registration.

Different TLD registries have different deletion processes. Some release expired domains during predictable daily windows, while others publish the exact drop time for each individual domain. Some country-code registries use completely different systems.

This guide covers the known drop times for popular domain extensions and explains how these times should be used when configuring a domain drop catcher.

Quick Domain Drop Time Table

These times should be treated differently depending on the TLD. Some are officially documented registry schedules; others are operational windows observed by the domain industry rather than guaranteed registry timestamps.

.COM Drop Time

Current scheduled drop time: 12:00 UTC

This is particularly important because the .COM schedule is changing.

Starting October 1, 2026, Verisign's scheduled .COM Pending Delete drop time is:

12:00 UTC

NameJet's current documentation explicitly states:

• 12:00 UTCVerisign .COM drop:
• 11:45 UTCNameJet order deadline:

This UTC schedule does not change with daylight saving time.

Older articles and drop-catching guides commonly show .COM dropping around 18:00–19:00 UTC. Those schedules refer to the previous Verisign drop window and should not be used after the October 2026 change.

For a drop-catching application, you therefore should not rely on old hard-coded .COM drop schedules.

A practical configuration might start shortly before 12:00 UTC and continue through the registry's release period.

.NET Drop Time

Current scheduled drop time: 12:00 UTC

.NET is also operated by Verisign and follows the same newly announced schedule as .COM.

Starting October 1, 2026:

.NET drop starts at 12:00 UTC

Therefore .COM and .NET can generally use the same drop-catching window.

For example:

Start catching:

11:59:XX UTC

Continue catching after:

12:00 UTC

The exact strategy depends on registrar API rate limits, latency and how long the registry takes to process that day's deletion batch.

.ORG Drop Time

Approximate drop window: 14:30–15:30 UTC

.ORG is operated by Public Interest Registry.

Unlike the newly documented .COM/.NET schedule, there is less authoritative public documentation specifying an exact second at which every .ORG is released.

Industry observations commonly place the .ORG drop window around:

14:30 UTC – 15:30 UTC

This should therefore be considered an operational estimate rather than a guaranteed registry timestamp.

For automated catching, it makes more sense to use a window rather than assuming that every .ORG becomes available at exactly 14:30:00 UTC.

.INFO Drop Time

Approximate drop window: 10:00–10:30 UTC

Industry drop-time references commonly place .INFO deletions around:

10:00 UTC – 10:30 UTC

.INFO is operated within the Identity Digital registry infrastructure.

Again, this is better treated as an approximate operational window rather than assuming:

Domain becomes available exactly at 10:00:00.000 UTC.

A drop-catching system should monitor the relevant registry/registrar response during the expected release window.

.ME Drop Time

Approximate drop window: 02:30–03:00 UTC

.ME has historically been observed dropping around:

02:30 UTC – 03:00 UTC

Because this happens very early in the UTC day, be careful when calculating the drop date.

Depending on your local timezone, the local calendar date may differ from the UTC date.

For automated software, storing drop dates and schedules internally in UTC is much safer than storing them in local server time.

.UK, .CO.UK and .ORG.UK Drop Times

The .UK namespace is especially interesting for drop-catching developers because Nominet has implemented one of the most transparent systems.

There is no single daily .UK drop time.

Instead, Nominet publishes the exact UTC drop timestamp for each individual domain.

For example, domains might have drop times such as:

00:10:53 UTC

00:12:19 UTC

00:13:18 UTC

00:16:26 UTC

and so on.

Nominet explicitly states that domains no longer drop at random times. Domains have a specified time published in the daily drop list.

The drop-list CSV contains:

• ROID
• Domain
• Drop time

The timestamp represents the exact UTC time from which the domain becomes available for registration.

This makes .UK fundamentally different from .COM.

Instead of configuring something such as:

Catch all .UK domains between 14:00–15:00

drop-catching software can obtain:

example.co.uk → 2026-10-05T04:17:23Z

and schedule its catching process around that particular timestamp.

For developers building automated drop-catching systems, Nominet's drop list is extremely useful.

.CA Drop Time

Canada's .CA registry uses another unusual system.

CIRA operates a To Be Released (TBR) process.

Instead of releasing expired domains through a normal daily Pending Delete batch, CIRA conducts a TBR session:

Every Wednesday at 19:00 UTC

Domains eligible for release are placed on CIRA's TBR list.

Accredited registrars participate in the TBR session beginning at:

Wednesday — 19:00 UTC

If nobody registers a domain during TBR, CIRA says it normally becomes available for ordinary registration shortly after the TBR session.

Therefore .CA drop catching is not simply a matter of sending standard registrar registration requests at a daily drop time.

Your registrar needs to support the CIRA TBR process.

.AU Drop Time

Australia's .AU registry has documented purge cycles.

For expired domains, the purge cycle runs daily at:

13:30 AEST

or

14:30 AEDT

The one-hour difference is caused by Australian daylight saving time.

Importantly, auDA distinguishes between deleted and expired domains.

Its documented purge cycles specify:

Deleted domains: 13:00 AEST / 14:00 AEDT

Expired domains: 13:30 AEST / 14:30 AEDT

Both processes operate every day, including weekends and public holidays.

This is a good example of why simply maintaining one generic "TLD drop time" database can sometimes be insufficient. The reason the domain is being purged can matter.

.DE Drop Time

.DE works differently again.

DENIC provides a 30-day Redemption Grace Period after deletion.

During this period, the previous domain holder—or someone authorized by that holder—can re-register the domain.

Once the 30-day RGP expires without restoration, the domain becomes freely available for registration.

However, DENIC does not provide the same kind of publicly documented universal daily drop batch that Verisign now provides for .COM/.NET, or the exact per-domain timestamp system provided by Nominet.

Therefore you should not hard-code a supposed universal .DE drop time without independently verifying it against current registry behavior.

For .DE, continuous availability monitoring around the expected RGP completion may be more appropriate.

.EU Drop Time

.EU also has a different lifecycle.

When EURid deletes a domain, the domain enters:

40 days of quarantine

During quarantine, the previous holder can restore it.

Once the quarantine period finishes, EURid releases the domain for registration on a first-come, first-served basis.

EURid's WHOIS service can provide the domain's release date, which is much more useful than simply trying to calculate everything from the original expiration date.

For .EU, therefore, use the registry-provided release information whenever possible.

Why Pending Delete Is Important

For most standard gTLDs, you should not start aggressively attempting registrations simply because the domain has expired.

The important status is:

pendingDelete

ICANN explains that after a domain completes its Redemption Period and reaches Pending Delete, it normally remains there for five calendar days before being purged from the registry and becoming available again.

Once a normal domain has entered the final Pending Delete stage, restoration is generally no longer possible.

Conceptually:

Registered

↓

Expired

↓

Auto-Renew / Registrar Grace Period

↓

Redemption Period

↓

Pending Delete — approximately 5 days

↓

Registry releases domain

↓

Drop catcher attempts registration

The registrar's expiration date therefore should not be treated as the drop date.

Why You Should Use UTC in Drop-Catching Software

If you are building or operating software such as Auto DropCatch, all internal scheduling should preferably use UTC.

For example:

TLD: COMDrop Start: 12:00:00 UTCTLD: ORGExpected Start: 14:30:00 UTCTLD: INFOExpected Start: 10:00:00 UTC

Your frontend can convert UTC into the user's local timezone.

This prevents daylight-saving changes, VPS location and server timezone configuration from accidentally shifting catching jobs.

This is especially important with .COM and .NET, because Verisign's new schedule is explicitly based on 12:00 UTC, while the corresponding U.S. local time changes when daylight saving begins or ends.

Don't Assume the Published Time Is the Exact Registration Millisecond

A common mistake is assuming:

Drop time = 12:00:00.000 → domain must become available at exactly 12:00:00.000

That isn't necessarily how a registry batch behaves.

For batch-based TLDs, thousands of domains may need to be processed. The published time can represent the start of the deletion process/window, with individual names becoming available as the registry processes them.

That is why professional drop catchers don't normally send one registration request at exactly the expected time.

They maintain infrastructure capable of attempting registration throughout the relevant release period while remaining within registry and registrar API rules.

There is an important exception: Nominet's .UK system specifically publishes a per-domain UTC drop timestamp. Nominet states that EPP domain:create can succeed at or after that timestamp—even if the underlying purge has not yet completed.

That makes .UK considerably more deterministic from a scheduling perspective.

Recommended Architecture for Auto DropCatch

A robust drop-catching engine should therefore avoid having one universal catching strategy.

Instead, maintain a TLD drop configuration database.

For example:

COMstrategy: BATCHstart: 12:00 UTCNETstrategy: BATCHstart: 12:00 UTCORGstrategy: ESTIMATED_BATCHwindow: 14:30–15:30 UTCINFOstrategy: ESTIMATED_BATCHwindow: 10:00–10:30 UTCMEstrategy: ESTIMATED_BATCHwindow: 02:30–03:00 UTCUKstrategy: DOMAIN_SPECIFICsource: Nominet Drop Listdrop_time: supplied for each domainCAstrategy: TBRschedule: Wednesday 19:00 UTCAUstrategy: REGISTRY_PURGEexpired: 13:30 AEST / 14:30 AEDTDEstrategy: AVAILABILITY_MONITORINGEUstrategy: RELEASE_DATEquarantine: 40 days

This is much safer than treating every extension like .COM.

Final Note

Domain drop times can change.

The .COM/.NET change in October 2026 is an excellent example. Software and articles using the long-standing older Verisign drop window will suddenly have incorrect scheduling.

For a drop-catching application, TLD schedules therefore shouldn't ideally be permanently hard-coded into the application.

Keep them in a database or configuration system so they can be updated without releasing a new version of the software.

And whenever a registry provides an authoritative per-domain release timestamp—as Nominet does for .UK—use that timestamp instead of trying to predict it.