How to Catch an Expiring Domain with Drop-Catching Services?

When a domain is finally deleted after its owner fails to renew it, it does not quietly become available for anyone to pick up at leisure. Desirable names are usually registered again within a fraction of a second of being released, by companies that do nothing but race for them. That race is called drop-catching. This guide goes deep on how it works: how a domain moves from expiry to deletion, how to work out the day it will drop, what drop-catch services actually do at the registry, how to choose and combine services, and how to build your own monitoring with RDAP and DNS so you are never surprised. If you are new to the idea of placing an order on a registered domain, read what domain backordering is and how it works first; this article assumes you know the basics.

The Road to the Drop

For gTLDs such as .com and .net, a domain that is not renewed passes through several stages before anyone else can register it. In brief:

1. Expiration. The registration term ends. The registry typically auto-renews the domain and the registrar has a window, up to 45 days, to delete it or keep it.
2. Grace period. The registrant can still renew. Many registrars sell expired names through auctions during this time, which means some domains never reach the drop at all.
3. Redemption grace period (RGP). If the registrar deletes the domain, it enters redemptionPeriod for 30 days. The domain stops resolving, and only the previous registrant can restore it, usually for a fee.
4. Pending delete. After redemption, the domain sits in pendingDelete for 5 days. It cannot be restored or renewed.
5. The drop. The registry purges the domain, and it becomes available to any registrar.

The grace and redemption mechanics are explained in detail in the domain grace period and redemption period. For drop-catching, the important part is that the last two stages are fixed and predictable: once a domain enters pending delete, you can work out the drop date.

Predicting the Drop Date

The pending delete stage has a fixed length, which makes it the most reliable signal in the whole lifecycle.

Signal you observe	Estimated drop	Confidence
Status changes to pendingDelete	About 5 days later	High
Status changes to redemptionPeriod	About 35 days later (30 days RGP plus 5 days pending delete)	Medium, the owner may still restore
Expiration date passes	Anywhere from about 35 to 80 days later, if not renewed	Low

Why is the expiration date so unreliable? Because the registrar decides when, within the auto-renew grace window, to delete the domain, and the owner can renew at any point up to the start of pending delete. Some registrars delete expired domains quickly; others hold them for most of the 45 days to run auctions.

For .com and .net, Verisign processes deletions in a daily batch, and the drop is commonly observed in the afternoon, US Eastern time. The exact order and timing within the batch are not published, and they can vary, so the realistic goal is to know the drop day, not the second.

Country-code TLDs are different. Some delete domains on fixed schedules, some release them in public auctions, and some have no redemption period at all. Always check the registry's own policy for the extension you are targeting.

What Happens at the Moment of the Drop

When the registry releases a domain, any accredited registrar can send an EPP create command for it. The first valid create that the registry processes wins. Everyone else receives an error saying the object already exists.

This is where specialists come in. A registrar's connection to the registry is limited. Registries cap the number of simultaneous connections and the rate of commands each registrar can send, and they charge for registrations. A single retail registrar sending a few requests per second is no match for a company that controls many registrar accreditations and spreads its attempts across all of them. This is why drop-catching companies typically operate many separate registrar accreditations rather than one.

The practical consequence:

• You cannot realistically win a contested drop by hand or with a script that calls a retail registrar's API. By the time your request is processed, a drop-catcher will usually have registered the name.
• Uncontested names are different. Many domains drop with nobody trying to catch them. Those can be registered normally at any registrar, minutes or hours after the drop, and a monitoring script is exactly what you need for them.

How Drop-Catching Services Operate

A drop-catch service combines three things:

1. Lists. They know which domains are scheduled to drop, from registry pending delete data, zone file differences, and their own monitoring.
2. Connections. They operate or partner with many accredited registrars, each with its own registry connections, and fire carefully timed create commands at drop time.
3. Allocation. They decide who gets a caught domain. If one customer ordered it, that customer gets it at the backorder price. If several did, there is usually a private auction.

Many also have partnerships with retail registrars that pass expired domains to them before deletion. A domain registered at a partner registrar may be sold during its grace period and never drop.

Choosing a Service

Ask these questions before placing an order:

Question	Why it matters
Which TLDs do you support?	Catching capacity varies a lot by extension
Do you have expired-domain partner registrars?	Partners can give access before the drop
Do you charge only on success?	Determines your cost if the catch fails
What happens with multiple backorders?	Most run an auction; know the starting price and duration
How is the domain delivered?	Usually to an account at the service's registrar, then transferable after any lock period

Using More Than One Service

Because different services compete at the drop, placing orders with two or three of them can raise your odds on a contested name. The trade-offs are that you may be charged by whichever one succeeds, and you may end up bidding in an auction you would rather have avoided. Decide your maximum price before the drop, not after.

Building Your Own Monitoring

Even when you rely on a drop-catch service, you should track the domains you care about yourself. That way you know when a name enters redemption, when it is in pending delete, and whether it was actually caught or is now available to register by hand.

Check the Current Status

RDAP gives you the status in a consistent JSON format:

curl -sL https://rdap.org/domain/example.com | jq -r '.status[]'

RDAP status values are written in lowercase words, so pendingDelete appears as pending delete and redemptionPeriod as redemption period. After the drop, the registry's RDAP server returns HTTP 404 because the domain no longer exists:

curl -sL -o /dev/null -w "%{http_code}\n" https://rdap.org/domain/example.com

A 404 means the domain is not registered. A 200 means it is. If the domain was in pending delete yesterday and returns 200 with a brand-new creation date today, someone caught it.

Check Whether the Domain Is Still in the Zone

Domains in redemption and pending delete are removed from the TLD zone, so they stop resolving. You can ask a .com TLD server directly, without any resolver caching in the way:

dig +norecurse @a.gtld-servers.net example.com NS

If the response is a referral with the domain's NS records in the AUTHORITY section, the domain is delegated. If the response status is NXDOMAIN, the domain is not in the zone. That alone does not tell you whether it is available, because domains in redemption are also absent from the zone, so combine this check with RDAP. If you need a refresher on reading dig output, see how to use the dig command for DNS lookups.

A Monitoring Script That Estimates the Drop

This Python script, using only the standard library, tracks a watchlist, records when each domain first enters pending delete, estimates the drop date, and reports when a name becomes available or is re-registered. It stores state in a small JSON file so it can run from cron.

#!/usr/bin/env python3
import json
import urllib.error
import urllib.request
from datetime import datetime, timedelta, timezone
from pathlib import Path

WATCHLIST = ["example.com", "example.net"]
STATE_FILE = Path("drop_watch_state.json")
PENDING_DELETE_DAYS = 5


def rdap_lookup(domain):
    """Return (http_status, json_or_None)."""
    req = urllib.request.Request(
        f"https://rdap.org/domain/{domain}",
        headers={"Accept": "application/rdap+json"},
    )
    try:
        with urllib.request.urlopen(req, timeout=20) as resp:
            return resp.status, json.load(resp)
    except urllib.error.HTTPError as err:
        return err.code, None


def creation_date(data):
    for event in data.get("events", []):
        if event.get("eventAction") == "registration":
            return event.get("eventDate")
    return None


def main():
    state = json.loads(STATE_FILE.read_text()) if STATE_FILE.exists() else {}
    now = datetime.now(timezone.utc)

    for domain in WATCHLIST:
        record = state.setdefault(domain, {})
        code, data = rdap_lookup(domain)

        if code == 404:
            if record.get("phase") != "available":
                print(f"[ALERT] {domain} is not registered. Register it now.")
            record["phase"] = "available"
            continue
        if code != 200 or data is None:
            print(f"[WARN] {domain}: RDAP returned HTTP {code}")
            continue

        statuses = {s.lower() for s in data.get("status", [])}
        created = creation_date(data)

        if "pending delete" in statuses:
            if "pending_delete_seen" not in record:
                record["pending_delete_seen"] = now.isoformat()
                print(f"[INFO] {domain} entered pending delete.")
            seen = datetime.fromisoformat(record["pending_delete_seen"])
            drop = seen + timedelta(days=PENDING_DELETE_DAYS)
            print(f"[INFO] {domain} estimated drop on or around {drop.date()}")
            record["phase"] = "pending delete"
        elif "redemption period" in statuses:
            if record.get("phase") != "redemption":
                print(f"[INFO] {domain} is in redemption. Restorable by owner for ~30 days.")
            record["phase"] = "redemption"
        else:
            previous = record.get("created")
            if previous and created and created != previous:
                print(f"[ALERT] {domain} was re-registered on {created}.")
            record["phase"] = "registered"
            record.pop("pending_delete_seen", None)

        if created:
            record["created"] = created

    STATE_FILE.write_text(json.dumps(state, indent=2))


if __name__ == "__main__":
    main()

A few notes on how it works:

• The estimate is based on the first time the script sees pending delete. If you run it once a day, the estimate can be up to a day late, so run it more often as a name approaches the drop.
• The re-registration check compares creation dates. A domain caught at the drop gets a new registration event.
• rdap.org is a convenient bootstrap redirector. For heavy use, query the registry's RDAP server directly. The official list of RDAP servers for each TLD is published by IANA at data.iana.org/rdap/dns.json.

Schedule It with Cron

Run the script every 15 minutes and append the output to a log:

*/15 * * * * cd /home/alex/dropwatch && /usr/bin/python3 dropwatch.py >> dropwatch.log 2>&1

Be considerate with frequency. RDAP servers apply rate limits, and a watchlist of a few dozen domains checked every 15 minutes is plenty. Querying thousands of names in a tight loop will get you blocked.

Get Alerts Instead of Reading Logs

To be notified on your phone or in a chat channel, pipe alert lines to a webhook. This Bash wrapper sends any [ALERT] lines to an incoming webhook URL, such as one from Slack or a similar service:

#!/usr/bin/env bash
set -euo pipefail

WEBHOOK_URL="https://hooks.example.com/services/your-webhook-id"

alerts=$(python3 /home/alex/dropwatch/dropwatch.py | grep '^\[ALERT\]' || true)

if [[ -n "$alerts" ]]; then
  payload=$(jq -n --arg text "$alerts" '{text: $text}')
  curl -s -X POST -H "Content-Type: application/json" -d "$payload" "$WEBHOOK_URL"
fi

When you receive a "not registered" alert, register the domain immediately at any registrar. Uncontested names often stay available for hours or days after the drop, but there is no reason to wait.

Finding Domains That Are About to Drop

If you are hunting for good names rather than tracking a specific one, you need lists of upcoming deletions. Common sources include:

• Drop-catch and auction platforms, which publish lists of domains in pending delete along with their own backorder counts.
• Zone files. Registries publish their zone files to approved users through ICANN's Centralized Zone Data Service (CZDS) for gTLDs, and Verisign offers zone file access for .com and .net. Comparing two days of zone files shows which domains disappeared, which is a rough signal that they are in redemption or pending delete.
• Your own watchlist, for names you have identified through research.

Before placing a bid on any name from a list, check its history for spam or penalties using the steps in how to check a domain's history, and make sure it does not infringe a trademark. Catching a name is not the same as having the right to use it.

Practical Strategy

1. Low-value, low-competition names: Monitor them yourself and register them by hand when they become available. A drop-catch service is unnecessary.
2. Medium-value names: Place a pay-on-success backorder with one reputable drop-catch service, and monitor in parallel.
3. High-value, contested names: Use multiple services, set a firm auction budget, and consider whether a direct offer to the current owner before expiry would be cheaper. See how to buy a domain name that's already taken.
4. After you win: Enable registrar lock, auto-renewal, and two-factor authentication on the account right away, and be aware that a newly registered domain usually cannot be transferred to another registrar for 60 days.

---

Drop-Catching FAQ

Conclusion

Drop-catching is a race that happens at the registry in a fraction of a second, but everything leading up to it is predictable. A domain that is not renewed moves through grace, a 30-day redemption period, and a 5-day pending delete stage before it drops, and the pending delete status is your most reliable clock. Contested names are won by services with many registrar connections, while plenty of uncontested names are available to anyone who is watching.

Combine the two approaches: use a reputable drop-catch service for names that matter and that others want, and run your own RDAP-based monitoring so you know exactly where each domain is in its lifecycle. Set your budget before any auction starts, and secure every domain the moment it lands in your account.

Here are some useful references for going deeper on expiring domains and drop-catching:

1. ICANN: gTLD Lifecycle — the official overview of grace, redemption, and pending delete phases.
2. RFC 3915: Domain Registry Grace Period Mapping for EPP — the protocol definition of the redemption and pending delete statuses.
3. RFC 9224: Finding the Authoritative RDAP Service — explains the IANA bootstrap file used to locate each TLD's RDAP server.
4. ICANN: Centralized Zone Data Service — where approved users request access to gTLD zone files.
5. Verisign: Zone File Access — information on accessing the .com and .net zone files.