WHOIS expiry monitoring: how it works, why RDAP is replacing it, and how to set it up

Of every monitoring failure that ends in real downtime, "the domain expired" is the most preventable and the most embarrassing. WHOIS expiry monitoring polls the registry's record for the renewal date and alerts you with enough lead time to fix payment, contact, or ownership issues. This article covers what's actually available now (post-GDPR), how WHOIS and RDAP differ, and the thresholds that catch problems early.

Why this matters more than it looks

A domain that expires at the registry takes everything down with it. Your website goes offline. Mail stops being delivered to your domain — receivers see NXDOMAIN on the MX lookup and bounce. SSO that uses your domain as the issuer breaks. Any service your customers integrated against your subdomains breaks.

Recovery is sequenced and slow:

• Auto-renew grace (0–45 days post-expiry, depending on TLD): standard renewal price, recovery in minutes-to-hours.
• Redemption period (next ~30 days): registry fees of $80–$200 on top of renewal, recovery in business days.
• Pending delete (~5 days): no recovery from your registrar.
• Public drop: anyone can register the domain.

The cost difference between catching the renewal at 90 days out vs. 0 days out is the difference between a 30-second click and a multi-week incident.

WHOIS and RDAP: what's the difference

Domain registration data has historically been published via the WHOIS protocol — a 1980s-era plain-text query against port 43 of the registry server. WHOIS is being replaced by RDAP (Registration Data Access Protocol), a JSON-over-HTTPS API standardized in 2015. As of 2026, ICANN has mandated RDAP for all gTLDs, and the major ccTLD registries are following.

What changed in practice:

• Format. WHOIS returns free-text formatted differently per registry. RDAP returns structured JSON with consistent fields (events, entities, status).
• Authentication. WHOIS is anonymous and unauthenticated. RDAP supports authenticated queries — useful for the registrant getting back fields that public RDAP redacts.
• Rate limits. WHOIS is loosely rate-limited at the connection level. RDAP has documented per-query limits and 429 responses.
• Data published. Both have been thinned by GDPR. Contact information is mostly redacted in public WHOIS / RDAP for both EU and non-EU registrants. Registration dates are still public — and that's what expiry monitoring depends on.

For monitoring purposes, RDAP is the better target: structured output, predictable response shape, and ICANN-mandated availability. WHOIS-style port-43 fallback is still useful for ccTLDs that haven't moved yet.

What you can rely on after GDPR

The fields that monitoring depends on are still public:

• Registration date (registrar registration date in WHOIS, registration event in RDAP).
• Expiration date (registry expiry date in WHOIS, expiration event in RDAP).
• Last update date (updated event in RDAP).
• Registrar name (the company managing the registration).
• Domain status flags (clientHold, serverHold, clientTransferProhibited, redemptionPeriod, pendingDelete).
• Nameservers.

What's not reliably public anymore:

• Registrant contact details — name, email, address, phone. EU: GDPR-redacted by default. Non-EU: increasingly redacted by registrars to apply one consistent policy.
• Admin and tech contacts — same redaction trend.
• Registrar abuse contact — usually still public, but spotty.

Don't build monitoring that depends on contact details being available. Build it on dates and status.

What to monitor

Five signals matter:

1. Days-to-expiry, computed as notAfter - now.
2. Status flag changes, especially the appearance of clientHold, serverHold, redemptionPeriod, or pendingDelete.
3. Registrar change, indicating a transfer (could be legitimate, could be hostile).
4. Nameserver change, indicating either a planned migration or a takeover.
5. Lookup failure, distinct from "the domain doesn't exist" — query timeouts and registry errors should be surfaced as a separate signal, not silenced.

Alert thresholds that work

The 90-day threshold is the most valuable. It is far enough out to fix the underlying causes — payment method, contact email, registrar account ownership — without operational pressure.

The "after 3 consecutive failures" rule on lookup-failure prevents alerting on momentary registry hiccups. Three checks at the default cadence is roughly an hour of consistent failure.

How to query an RDAP record yourself

The IANA bootstrap registry tells you which RDAP server handles which TLD:

curl -s https://data.iana.org/rdap/dns.json | jq '.services[] | select(.[0][] | contains("com"))'

Then query that server:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.events, .status'

Sample response:

[
  { "eventAction": "registration", "eventDate": "1995-08-14T04:00:00Z" },
  { "eventAction": "expiration",   "eventDate": "2027-08-13T04:00:00Z" },
  { "eventAction": "last changed", "eventDate": "2024-08-09T07:39:30Z" }
]
[ "client transfer prohibited", "server delete prohibited", "server transfer prohibited", "server update prohibited" ]

The expiration field is the date you compute days-to-expiry from.

ccTLD quirks

Some country-code TLDs don't expose RDAP yet. Workarounds:

• .uk / .co.uk (Nominet) — RDAP available, decent JSON.
• .de (DENIC) — WHOIS only. Data is sparser; you may not even get an expiry date depending on registrar policy.
• .eu (EURid) — RDAP available.
• .io — RDAP via the IANA bootstrap; treat as gTLD.
• .fr (AFNIC) — RDAP available.
• .ru — WHOIS only, and not all data is reliably published.
• .cn — restricted; expiry is published but querying from outside China can be unreliable.

For monitoring across many TLDs, you need both an RDAP path and a WHOIS port-43 fallback, with TLD-specific parsers for the worst-formatted WHOIS responses.

Set up DomainCare's WHOIS / RDAP monitoring

DomainCare runs the registry check every 12 hours on every domain. The check uses RDAP first via the IANA bootstrap, falls back to WHOIS port-43 for TLDs without RDAP, and surfaces these alerts:

• domain_expiry_warning — fires when the domain expires within 30 days.
• domain_expired — fires once after expiry.
• domain_hold_detected — fires when clientHold or serverHold appears.
• rdap_recovered — fires when registry holds are cleared.

Override thresholds per domain if you have non-standard renewal cadences (some long-term registrations skip 90- and 60-day notices entirely).

Related

• Domain expiry explained — the full lifecycle and grace periods.
• Domain expired: what to do — recovery flow if you missed every alert.
• Registry check reference — what the check actually verifies on every run.

Common questions

Why is the expiry date in WHOIS different from what my registrar's dashboard shows? The registrar may show a renewal-billing date that includes auto-renew, while WHOIS / RDAP shows the registry's hard expiry. The registry is authoritative for what the public-internet consequences will be — alert on that, not the dashboard.

My registrar lets me set auto-renew. Why monitor? Because auto-renew silently fails — expired credit cards, charged-back transactions, registrar account suspensions, billing-email filtering. The monitoring is the canary that catches the renewal pipeline breaking before it becomes an outage.

Is RDAP rate-limited enough that I can't poll every 12 hours? No. Polling twice a day on a small number of domains is well under any reasonable RDAP rate limit. Concerns about rate limiting come up at thousands-of-queries-per-minute scale, which is unusual for monitoring use cases.

Do I need to monitor all my domains or just the production ones? All. The cheapest domains to lose are also the easiest to forget — the staging domain you registered three years ago that points at the prod load balancer, the alternate-spelling defensive registration, the country-code mirror nobody uses. These are the ones that disappear without anyone noticing until they get squatted.