Translate EPP domain status codes into specific operational consequences for updates, transfers, renewal, and deletion.
What matters first
- A status code controls or describes an operation on the registration object.
- Client codes generally come from the registrar; server codes generally come from the registry.
- Several codes can be valid at the same time.
- A status is not a website safety rating.
Client and server prefixes
A client-prefixed status is generally set by the sponsoring registrar; a server-prefixed status is set by the registry. transferProhibited blocks transfers, updateProhibited blocks changes, and deleteProhibited blocks deletion. Multiple statuses can apply simultaneously.
Check the current status array in the RDAP lookup before acting on a copied or undated status label.
Lifecycle statuses
addPeriod follows initial registration. autoRenewPeriod can follow registry auto-renewal. redemptionPeriod usually offers a limited restore path after deletion, often with an extra fee. pendingDelete normally means restoration is no longer available and deletion is approaching.
A safe response checklist
Confirm the same code in the authoritative RDAP or registry result, record its prefix, check the registrar account for customer-facing deadlines, and contact the sponsoring registrar before acting. Never infer the exact drop time from a single timestamp.
Status changes make more sense when placed beside the domain events and dates reference.
Before removing a transfer lock or requesting an authorization code, work through the pre-transfer verification checklist.
Evidence-to-decision table
| Evidence | What it means | Responsible next step |
|---|---|---|
| clientTransferProhibited | Registrar blocks transfer | Check account lock and contact registrar |
| serverHold | Registry keeps domain out of DNS | Investigate registry or policy cause |
| redemptionPeriod | Post-deletion restoration window | Act through sponsoring registrar promptly |
| pendingDelete | Deletion processing stage | Do not assume an exact drop second |
Illustrative triage: website stops resolving
This is an illustrative example, not a claimed real-world test.
Confirm whether DNS fails because the parent delegation is absent or because authoritative servers fail.
Read the current registration statuses from the authoritative RDAP result.
If serverHold or clientHold appears, contact the responsible registrar with the exact code; do not repair unrelated A records first.
Defensible outcome: The workflow connects the code to its operational consequence while avoiding the false claim that every DNS outage is a registration hold.
Action checklist
- Copy the exact code
- Note client or server prefix
- Record the authoritative source
- Check every simultaneous status
- Compare current DNS
- Use registrar account deadlines
- Escalate through the responsible party
Edge cases that change the answer
ok plus another code
The EPP definitions constrain valid combinations; verify that a display has not merged stale or differently sourced records.
Inactive domain
A registration can exist without delegated nameservers and still not be in a deletion lifecycle.
Rapid transitions
Pending states can change between observations. Timestamp screenshots and refresh authoritative data before action.
Questions this guide should settle
Does transferProhibited mean a dispute?
Not necessarily. It is commonly an ordinary registrar lock used to reduce unauthorized transfers.
Can I remove serverHold myself?
Usually no. The registry applied it; work through the registrar and the reason associated with the hold.
Does pendingDelete guarantee availability?
No. Exact timing, registry policy, competing registrations and reserved-name rules still apply.