Domain status codes, also called EPP status codes, are the flags a registry keeps on every domain name and shows in WHOIS and RDAP lookups. Codes that start with client are set by your registrar, codes that start with server by the registry, and the rest track pending actions and grace periods. clientTransferProhibited, for example, is a transfer lock: it stops moves to another registrar and nothing else, and your registrar removes it on request.
What a domain status code is
ICANN defines them in one sentence: "Extensible Provisioning Protocol (EPP) domain status codes, also called domain name status codes, indicate the status of a domain name registration." EPP itself is, in ICANN's glossary, "A protocol used for electronic communication between a registrar and a registry for provisioning (creating, amending, and removing) domain name registrations." The status values are part of RFC 5731, the EPP domain name mapping, which is Internet Standard 69. Its first rule: "A domain object MUST always have at least one associated status value." In ICANN's words, "Every domain has at least one status code, but they can also have more than one."
The first word of a code tells you who controls it. RFC 5731 says "Status values that can be added or removed by a client are prefixed with "client"." The client is your registrar and the server is the registry that runs the TLD, while "Status values that do not begin with either "client" or "server" are server-managed." ICANN adds that server codes "take precedence over client codes", and the RFC is plain about who can undo what: "A client MUST NOT alter status values set by the server." Your registrar can remove its own codes; a server code needs the registry.
ICANN's reference lists "the 17 standardized EPP (see std69) domain status codes plus the Registry Grace Period (RGP) status codes (see RFC3915)". RFC 3915 adds 7 grace period values, 6 of them new because pendingDelete appears in both documents, so the full list on this page has 23 codes.
RDAP writes them differently. RFC 8056 sets the rule: "The RDAP status value is derived from the EPP status value by converting the EPP "camelCase" representation to lowercase with a space character inserted between word boundaries." So clientTransferProhibited becomes client transfer prohibited, with one exception: "ok = active". gTLD RDAP answers must carry a notice reading "For more information on domain status codes, please visit https://icann.org/epp", hence that link next to the codes.
Domain status checker
Paste the Domain Status lines from a WHOIS lookup, the status list or the whole JSON of an RDAP answer, or type one or more codes. The checker explains each code, shows what the set blocks and flags combinations RFC 5731 does not allow. It runs in your browser and sends nothing.
Source: ICANN EPP status codes page, RFC 5731, RFC 3915 and RFC 8056, fetched September 27, 2026. The example.com codes are from Verisign's RDAP answer of that day. Machine-readable: epp-status-codes-20260927.json.
clientTransferProhibited: the transfer lock
ICANN describes the code this way: "This status code tells your domain's registry to reject requests to transfer the domain from your current registrar to another." The protocol rule is one line in RFC 5731: "Requests to transfer the object MUST be rejected." On its own it does not touch DNS, renewals or updates, which have codes of their own.
The lock is there to protect you. ICANN says it "will help prevent unauthorized transfers resulting from hijacking and/or fraud", and notes that "Some registrars automatically enact certain status codes when you register a domain name, while others do so when you request it." IANA's own example.com carries it: the RDAP answer Verisign returned on September 27, 2026 listed client delete prohibited, client transfer prohibited and client update prohibited.
To move a locked domain, ICANN's advice is direct: "If you do want to transfer your domain, you must first contact your registrar and request that they remove this status code." A transfer cannot even start while the lock is on, because RFC 5731 says a pendingTransfer "status MUST NOT be combined with either "clientTransferProhibited" or "serverTransferProhibited" status."
serverTransferProhibited is the registry's version. ICANN calls it "an uncommon status that is usually enacted during legal or other disputes, at your request, or when a redemptionPeriod status is in place"; some registries offer a Registry Lock Service that sets it as extra protection. Removing it takes longer, because your registrar "has to forward your request to your domain's registry and wait for them to lift the restriction."
serverHold, clientHold and inactive: when a domain stops resolving
Of the 23 codes, 6 keep a domain out of the DNS. For the two holds RFC 5731 says "DNS delegation information MUST NOT be published for the object." serverHold comes from the registry: "This status code is set by your domain's Registry Operator. Your domain is not activated in the DNS." clientHold comes from your registrar, and ICANN calls it "an uncommon status that is usually enacted during legal disputes, non-payment, or when your domain is subject to deletion."
inactive is not a penalty: "This status code indicates that delegation information (name servers) has not been associated with your domain." It is the normal state of a new name without name servers. The other three are the deletion states, redemptionPeriod, pendingRestore and pendingDelete. ICANN's recovery policy says "During the Redemption Grace Period, the registry must disable DNS resolution and prohibit attempted transfers of the registration." For every one of these codes, ICANN's advice starts with your registrar, even when the registry set the code.
Pending actions, grace periods and redemption
Five codes start with pending, and RFC 5731 defines them together: "A transform command has been processed for the object, but the action has not been completed by the server." Only one can be present at a time: "The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and pendingUpdate status values MUST NOT be combined with each other." An unexpected pendingTransfer deserves quick action: "If you did not request to transfer your domain, you should contact your registrar immediately to request that they deny the transfer request on your behalf."
The grace period codes from RFC 3915 are informational: addPeriod follows a new registration, renewPeriod a renewal, transferPeriod a transfer and autoRenewPeriod an automatic renewal at expiry, and in each window a registrar that deletes the name gets its fee back. Their length is up to each registry.
Deletion has its own pair. When a registrar deletes a domain, "The EPP status changes to "pendingDelete", and the RGP status is initialized to "redemptionPeriod"." ICANN puts numbers on the next steps: "Your domain will be held in this status for 30 days. After five calendar days following the end of the redemptionPeriod, your domain is purged from the registry database and becomes available for registration." pendingRestore means the registrar has asked to bring the name back. The domain lifecycle page turns these periods into dates.
Every EPP status code
All 23 codes, grouped by who sets them. The last column lists what a code stops on its own; select a code to open it in the checker.
| Code | RDAP | What it means | Stops on its own |
|---|---|---|---|
| Set by the registrar (client codes) | |||
| clientDeleteProhibited | client delete prohibited | Delete lock set by your registrar: the registry refuses requests to delete the domain. | Deletion |
| clientHold | client hold | Your registrar has told the registry not to publish the domain in the DNS, so it does not resolve. ICANN lists legal disputes, non-payment and pending deletion as the usual reasons. | DNS resolution |
| clientRenewProhibited | client renew prohibited | Your registrar has told the registry to refuse renewals. ICANN calls it uncommon, usually tied to legal disputes or a coming deletion. | Renewal |
| clientTransferProhibited | client transfer prohibited | Transfer lock set by your registrar: the registry refuses requests to move the domain to another registrar. It protects against hijacking, and on its own it does not stop the domain from resolving. | Transfers to another registrar |
| clientUpdateProhibited | client update prohibited | Update lock set by your registrar: the registry refuses changes to the domain, other than removing this status. | Updates |
| Set by the registry (server codes) | |||
| serverDeleteProhibited | server delete prohibited | Delete lock set by the registry. ICANN calls it uncommon: usually a legal dispute, your own request (some registries offer a Registry Lock Service), or a redemption period. | Deletion |
| serverHold | server hold | The registry has taken the domain out of the DNS, so it does not resolve. | DNS resolution |
| serverRenewProhibited | server renew prohibited | The registry will not let your registrar renew the domain. ICANN calls it uncommon, usually tied to legal disputes or a coming deletion. | Renewal |
| serverTransferProhibited | server transfer prohibited | Transfer lock set by the registry. ICANN names legal or other disputes, a registry lock service you asked for, and the redemption period as the usual reasons. | Transfers to another registrar |
| serverUpdateProhibited | server update prohibited | Update lock set by the registry: changes to the domain are refused. ICANN names legal disputes, a registry lock you asked for, or a redemption period. | Updates |
| Normal state and pending actions (managed by the registry) | |||
| ok | active | The normal state: no pending operation and no lock or hold. RDAP shows it as active. | Nothing |
| inactive | inactive | No name servers are linked to the domain, so it is not in the DNS and does not resolve. | DNS resolution |
| pendingCreate | pending create | A registration request has been received and is still being processed. In a launch phase such as sunrise, the name may be allocated when that phase ends. | Nothing; an action is pending |
| pendingDelete | pending delete | The domain is being deleted. Next to redemptionPeriod or pendingRestore it is part of the redemption process; on its own it means the 30-day redemption period is over and the name will be purged within days. | DNS resolution, transfers to another registrar |
| pendingRenew | pending renew | A renewal request has been received and is still being processed. | Nothing; an action is pending |
| pendingTransfer | pending transfer | A transfer to another registrar has been requested and is still being processed. | Nothing; an action is pending |
| pendingUpdate | pending update | An update request has been received and is still being processed. | Nothing; an action is pending |
| Grace periods and redemption (RFC 3915) | |||
| addPeriod | add period | The first days after a new registration. If the registrar deletes the name in this window, the registry may credit the registration fee. | Nothing |
| autoRenewPeriod | auto renew period | The registration period ended and the registry renewed the domain automatically. If the registrar deletes it in this window, the registry credits the renewal. | Nothing |
| renewPeriod | renew period | The registrar has just renewed the domain. If it deletes the name in this window, the registry credits the renewal. | Nothing |
| transferPeriod | transfer period | The domain has just moved to a new registrar. If the new registrar deletes it in this window, the registry credits the transfer. | Nothing |
| redemptionPeriod | redemption period | The registrar has asked the registry to delete the domain. For 30 days the registrar that deleted it can still restore it; meanwhile the domain does not resolve and cannot be transferred. | DNS resolution, transfers to another registrar |
| pendingRestore | pending restore | The registrar has asked the registry to restore the domain from the redemption period and must send the restore report in time; otherwise it falls back to redemptionPeriod. | DNS resolution, transfers to another registrar |
Source: ICANN EPP status codes page and RFC 5731, RFC 3915 and RFC 8056, fetched September 27, 2026. RDAP column: the RFC 8056 mapping, which matches ICANN's table for all 23 codes.
Combinations the standard does not allow
RFC 5731 lists 6 rules for mixing its codes. The first says an ok "status MUST NOT be combined with any other status." Each pending code excludes the matching lock, such as pendingDelete with clientDeleteProhibited, and no two pending codes may appear together. The checker flags each case. The grace period values are a separate layer: ICANN notes that pendingDelete "may be mixed with redemptionPeriod or pendingRestore."
Domain status codes: frequently asked questions
What are domain status codes?
What does clientTransferProhibited mean?
How do I remove clientTransferProhibited?
What does serverHold mean?
What is the difference between client and server status codes?
What does redemptionPeriod mean?
Sources and method
- ICANN: EPP Status Codes, What Do They Mean, and Why Should I Know? (both tables, all 23 rows), fetched September 27, 2026.
- RFC 5731 section 2.3 (status values and combination rules), RFC 3915 section 3.1 (grace period values) and RFC 8056 (EPP to RDAP mapping), fetched September 27, 2026.
- ICANN Expired Registration Recovery Policy, ICANN RDAP Response Profile and ICANN glossary (EPP), fetched September 27, 2026.
- The example.com statuses: Verisign RDAP answer for example.com, fetched September 27, 2026.
- Method: codes, RDAP names and definitions are parsed by script from the saved files, and ICANN's RDAP column matches the RFC 8056 mapping for every code. The summaries restate these texts.