clientHold is set by the registrar; serverHold comes from the registry. Either can keep a domain out of DNS. Read pendingDelete alongside redemptionPeriod and pendingRestore, then ask the registrar about the exact combination shown in RDAP.
A domain status is about the registration lifecycle, not a web server health check. A single domain may carry several statuses at once. ICANN lists 23 EPP and Registry Grace Period codes. This guide starts with the decisions a registrant actually faces and then provides a linked reference for every code.
First, distinguish a suspension from a DNS configuration error
If both your site and mail disappear, inspect the registration record for clientHold, serverHold, or inactive. The first is applied by the registrar, the second by the registry. Both stop DNS activation. inactive means no nameservers have been assigned for delegation. Changing an A record at your DNS provider will not lift a registry hold.
Take the complete RDAP status list to your registrar. Ask what triggered the hold and what evidence or action is needed to clear it. Do not infer non-payment from the code alone: ICANN describes several possible circumstances. If no hold or inactive status appears, trace the delegation and authoritative answer using the dig command guide and the DNS failure workflow.
Next, read pendingDelete as a combination
ICANN explicitly allows pendingDelete to appear with redemptionPeriod or pendingRestore. Those combinations do not mean the same thing as a standalone pendingDelete. During redemption, ask your registrar immediately about the restore process and applicable fee. During pending restore, confirm that the registrar sent the required documentation to the registry.
A standalone pendingDelete means the domain has left the redemption period and is approaching deletion under the applicable registry policy. Contact the registrar urgently to ask what options remain. A WHOIS date alone is not a promise that a restore or re-registration will succeed. For the broader timeline, read domain expiration monitoring; for migration constraints, use the transfer checklist.
How much time remains in the deletion path
For the ICANN gTLD process described in its EPP guide, redemptionPeriod lasts 30 days after the registrar requests deletion. If the name is not restored, the subsequent pendingDelete stage leads to removal from the registry after another 5 calendar days. Those numbers are specific to this process. They are not a universal timetable for country-code domains, nor do they start automatically on the expiration date shown in WHOIS. Registrars may have their own steps before a deletion request.
For an affected registration, save the current RDAP response, identify the registrar and expiry date, and check whether redemptionPeriod accompanies pendingDelete. Ask the registrar which action is still possible and request confirmation. Do not wait until a calculated deadline: statuses can change as operations are processed, and restoration depends on the registry policy and current stage. If you see pendingRestore, ask whether the registry received the required restoration documents.
Protection locks do not cancel deletion urgency. A serverTransferProhibited code only speaks to transfer; it does not make redemptionPeriod a normal active state. Conversely, three protection locks on an otherwise active domain do not mean it is about to be deleted. The combination and the operation history matter more than the number of codes.
How a status reaches DNS
The registrant acts through a registrar. The registrar sends EPP operations to the registry, which holds the domain object and its delegation. The registry publishes delegation in the top-level zone. Your own authoritative nameservers answer only after that step. A correct A record on your DNS provider therefore does not prove that the top-level zone delegates the name. A registrar-side clientHold or registry-side serverHold interrupts that earlier stage.
registrant → registrar → registry → TLD zone → domain NS → A/MX/other records
client* server* hold/inactive DNS answerRDAP and WHOIS describe registration state; dig describes a DNS answer at a particular time. Use both. A hold in RDAP points to the registrar or registry process. Normal registration statuses with failed DNS queries point to delegation or authoritative DNS instead. After a hold is removed, compare more than one resolver because cached answers can lag; one successful lookup is not proof that every user sees the restored delegation.
Choose the next action from the whole status set
Prioritize availability and ownership. Hold or missing nameservers can explain failed resolution. Transfer and update locks generally do not. A renewal prohibition deserves attention before an expiry date, even if the site currently loads. Read all statuses together and retain a timestamp; selecting the first line of an RDAP response can hide a more urgent second code.
| Status set | First check | Contact |
|---|---|---|
| clientHold | Reason for suspended delegation | Registrar |
| serverHold | Registry decision and release conditions | Registrar for escalation |
| inactive | Nameserver assignment | Registrar |
| clientTransferProhibited | Whether you intended a transfer | Registrar only if transfer is needed |
| RenewProhibited | Expiry date and reason | Registrar urgently |
| pendingDelete + redemptionPeriod | Restore eligibility and cost | Registrar urgently |
| pendingDelete without redemptionPeriod | Any remaining option | Registrar immediately |
The client and server prefixes identify who applied a restriction, but the registrant normally starts with the registrar in either case. The status does not expose the underlying reason or the full operation history. If a pending transfer or update was not yours, treat it as an account security question and tell the registrar that the request was unauthorized.
All 23 EPP codes, with the next action
client restrictions are set by registrars; server restrictions are set by registries. Transfer, update, and delete locks often protect an active registration and do not themselves disable DNS. A renewal prohibition is more urgent as expiry approaches. The descriptions follow the ICANN gTLD model; a country-code registry can have its own lifecycle rules. Open the linked ICANN definition for the exact scope of a code.
| EPP | What it means | Next action |
|---|---|---|
ok | No EPP restrictions or pending actions; DNS is separate | Check DNS separately if the site fails |
inactive | No name servers assigned for delegation | Set name servers with the registrar |
clientHold | Registrar has suspended DNS activation | Ask registrar why and how to lift it |
serverHold | Registry has suspended DNS activation | Ask registrar to escalate to the registry |
clientTransferProhibited | Registrar blocks transfer | Remove only for an intended transfer |
serverTransferProhibited | Registry blocks transfer | Ask registrar about registry unlock |
clientUpdateProhibited | Registrar blocks updates | Ask registrar if an update is needed |
serverUpdateProhibited | Registry blocks updates | Ask registrar about the registry restriction |
clientDeleteProhibited | Registrar blocks deletion | Keep the lock unless deletion was intended |
serverDeleteProhibited | Registry blocks deletion | Ask registrar about registry unlock |
clientRenewProhibited | Registrar blocks renewal | Resolve with registrar before expiry |
serverRenewProhibited | Registry blocks renewal | Urgently ask registrar to escalate |
pendingCreate | Create request is being processed | Check the request and registrant |
pendingUpdate | Update request is being processed | Contact registrar if unexpected |
pendingRenew | Renewal request is being processed | Confirm the renewal request |
pendingTransfer | Transfer request is being processed | Contact registrar at once if unauthorized |
redemptionPeriod | Restore window after a deletion request | Urgently request restore and fee details |
pendingRestore | Restore request awaits registry processing | Track confirmation with registrar |
pendingDelete | Deletion pending; read accompanying statuses | If alone, urgently ask about remaining options |
addPeriod | Grace period after initial registration | Usually informational |
autoRenewPeriod | Grace period after registry auto-renewal | Confirm renewal and payment |
renewPeriod | Grace period after explicit renewal | Confirm it was your renewal |
transferPeriod | Grace period after transfer | Contact prior registrar if unexpected |
A live cross-check: locks can coexist with working delegation
We queried public RDAP for example.com and icann.org. The first reported registrar-level protection; the second included registry-level locks. Both returned nameservers in a direct DNS query. This does not test website availability, but it shows why a transfer lock must not be read as a DNS suspension. Recheck live records before making a decision.
RDAP example.com status: client delete prohibited, client transfer prohibited, client update prohibited
$ dig +short example.com NS
elliott.ns.cloudflare.com.
hera.ns.cloudflare.com.
RDAP icann.org status: server delete prohibited, client transfer prohibited, server transfer prohibited, server update prohibited
$ dig +short icann.org NS
c.icann-servers.net.
b.icann-servers.net.
At capture time, example.com had 3 protective statuses and returned 2 nameservers. icann.org had 4 protective statuses and returned 4 nameservers. Neither RDAP response included a hold. This is a useful control pair: a monitoring tool that treats every Prohibited status as a DNS outage needs a closer look. Nameserver output also does not prove that HTTPS works or that mail is accepted. Registration, delegation, and application health require separate checks.
RDAP displays labels with spaces, such as client transfer prohibited, while the EPP code is clientTransferProhibited. ICANN maps the two forms. You can start with the enterno WHOIS check, then compare the entire status list against the reference above. The domain owner lookup guide explains registration data; the DNS record guide covers the next layer.
What to send to your registrar
Include the domain, every reported status, the time of the lookup in UTC, the expiration date, and the affected operation: delegation, renewal, transfer, or update. Ask who applied the restriction, what clears it, and what status should follow. For a registry-level code, the registrar is the usual point of contact for escalation. Keep account passwords and transfer authorization codes out of public tickets.
How we made this
On 13 November 2026 we checked all 23 status links in ICANN’s EPP reference. method.py fetched public RDAP for example.com and icann.org and ran dig +short NS for each; timestamps, arguments, statuses, and DNS output are in data.json. Two domains illustrate one distinction; they cannot establish the prevalence of locks or holds. This AI-assisted article was checked against ICANN and the recorded outputs.
FAQ
Who can remove clientHold?
The registrar sets it. Contact the registrar for the cause and removal process.
Does serverTransferProhibited take a website offline?
No. It blocks transfer between registrars; a separate hold or delegation issue would explain DNS failure.
Can pendingDelete be reversed?
Check whether redemptionPeriod or pendingRestore accompanies it. For a standalone pendingDelete, ask the registrar immediately what options remain; do not assume restoration is available.
Why are RDAP statuses spaced differently?
RDAP uses readable labels such as client transfer prohibited. EPP uses compact forms such as clientTransferProhibited.
