Domain status codes explained: clientHold, clientTransferProhibited, redemptionPeriod and pendingDelete
By the RenewRoster team · · 7 min read
When a client's site goes down, or a transfer stalls, the answer is often sitting in plain sight on a public RDAP or WHOIS lookup: the domain's status codes. Registrars and registries set them. They tell you whether the domain is locked, held out of DNS, mid-transfer, or heading for deletion. Here's what the ones agencies hit most often mean, using ICANN's own definitions, and what to do about each.
How to read a domain's status codes
Look the domain up with a public RDAP/WHOIS tool (or find its registrar and expiry). You'll see one or more codes such as clientTransferProhibited or ok.
Two families matter:
- Client codes (
client…) are set by the registrar. Most "lock my domain" toggles flip these. - Server codes (
server…) are set by the registry (the TLD operator). They override client codes and usually mean a dispute, a registry lock product, or a deletion path.
A domain can carry several codes at once. Treat the most restrictive one as the one that decides what you can do today.
The everyday "good" statuses
ok (RDAP: active). No pending operations and no prohibitions. Fine for a healthy domain, but ICANN notes that asking the registrar to add locks (transfer/delete/update prohibited) helps against hijacking.
clientTransferProhibited. The registrar has told the registry to reject transfer requests. This is the normal lock most registrars turn on by default. The site still resolves. To move the domain, unlock it first, then get the auth (EPP) code. See also the 60-day transfer lock.
clientDeleteProhibited / clientUpdateProhibited. Same idea for deletions and contact/nameserver updates. Common anti-hijack locks. Remove them at the registrar only when you intentionally need that change.
Grace-period codes (addPeriod, autoRenewPeriod, renewPeriod, transferPeriod). Informative windows after registration, renewal or transfer. Usually nothing to fix; just know a delete in that window can credit the registrar.
Emergencies: the site stops resolving
clientHold. The registrar told the registry not to put the domain in DNS. The site, email and everything else on that domain stop resolving. ICANN lists typical causes as legal disputes, non-payment, or the domain heading for deletion. Contact the registrar immediately, pay any outstanding renewal, and ask them to clear clientHold.
serverHold. Same DNS blackout, but set by the registry. Harder to clear: the registrar has to work with the registry. Treat it as urgent and escalate with the registrar's support, not a self-serve unlock toggle.
inactive. No nameservers are associated with the domain, so it won't resolve. Often a brand-new registration that never got DNS, or nameservers were wiped. Add the correct nameservers at the registrar.
Transfer and change in progress
pendingTransfer. A transfer to another registrar has been requested. If you didn't start it, call the current registrar and ask them to deny it. If you did, wait (often up to five days) or approve early at the losing registrar.
pendingUpdate / pendingRenew / pendingCreate. A create, renew or update is being processed. Unexpected? Contact the registrar.
serverTransferProhibited. Registry-level transfer block (dispute, registry lock, or redemption). Clearing it takes longer than unlocking clientTransferProhibited because the registrar must ask the registry.
The deletion path (act fast)
redemptionPeriod. The registrar asked the registry to delete the domain. ICANN: the domain stays here for 30 days. To keep it, contact the registrar immediately, fix whatever caused the delete (usually unpaid renewal), pay the restore fee, and have them restore it. After redemption ends, you have a short further window before it's gone.
pendingRestore. The registrar has asked to restore a domain that was in redemption. Watch the status for about seven days; if documentation fails, it can fall back to redemptionPeriod.
pendingDelete (alone, without redemption/restore). The domain finished redemption without being restored. It will be purged in a few days and then become available for anyone to register. Options are limited; contact the registrar today and ask what, if anything, they can still do. Once it drops, recovering an expired domain is a race against drop-catchers.
Quick triage for agencies
| What you see | Site up? | Urgency | First move |
|---|---|---|---|
ok or locks like clientTransferProhibited | Yes | Low | Leave locks on unless transferring |
clientHold / serverHold / inactive | No | High | Registrar support; clear hold or set nameservers |
pendingTransfer you didn't start | Maybe | High | Ask registrar to deny transfer |
redemptionPeriod | Usually no | Critical | Restore + pay fee this week |
pendingDelete (solo) | No | Critical | Call registrar immediately |
How this ties to renewals
Most clientHold and redemption cases start as a missed renewal: card failed, reminder went to an old email, or nobody owned the registrar login. Tracking expiry dates and registrar names across every client domain is how you catch that before status codes turn red. A quick expiry check is enough for one domain; for a portfolio, you want them in one list.
Keep status and expiry in one place
RenewRoster reads each client's domain from public RDAP/WHOIS (registrar, expiry and status), checks the certificate each host actually serves, and alerts your team at 60, 30, 14 and 3 days. Free for 5 domains or certificates.
Let RenewRoster watch every renewal for you
RenewRoster tracks every client's domain and SSL expiry dates, sends reminders at 60, 30, 14 and 3 days (under your agency's brand if you like) and gives you a monthly renewals report. Free for 5 domains, no card needed.