--- id: "epp-status-codes" kind: "glossary-term" title: "EPP status codes" language: "en" category: "Transfers and EPP" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/epp-status-codes/" translations: es: "https://tldlog.com/es/glosario/codigos-estado-epp/" de: "https://tldlog.com/de/glossar/epp-statuscodes/" fr: "https://tldlog.com/fr/glossaire/codes-statut-epp/" it: "https://tldlog.com/it/glossario/codici-stato-epp/" pt-BR: "https://tldlog.com/pt/glossario/codigos-status-epp/" ru: "https://tldlog.com/ru/glossariy/kody-statusov-epp/" zh-Hans: "https://tldlog.com/zh/cihui/epp-zhuangtaima/" --- # EPP status codes The standard labels on a domain that show its state and which actions are allowed, such as transfer, update, renewal or deletion. Codes starting with client are set by the registrar, and codes starting with server by the registry. They appear in RDAP results. Every domain name carries at least one status code: a short label, such as ok or clientTransferProhibited, that says what state the registration is in and which actions are blocked. The codes come from EPP, the standard language registrars use to talk to registries. Reading them explains why a domain has stopped working, whether it is protected against theft, and whether it is close to deletion. ## What domain status codes are and where to see them The codes are defined in the EPP standard for domain names, RFC 5731, and in its grace period extension, RFC 3915, which adds the Redemption Grace Period (RGP) codes. For gTLDs, the place to check is an RDAP lookup, such as ICANN Lookup or a registrar's own lookup tool. Since 28 January 2025, RDAP has replaced WHOIS as the definitive source of gTLD registration data (as of October 2026). RDAP writes the codes as lowercase words with spaces, so clientTransferProhibited appears as "client transfer prohibited", and ok appears as "active". Registrars must display every status that applies to a domain. ccTLDs set their own rules and may show status differently. This explainer follows EPP and the policies for gTLDs. ## Client versus server codes: who set them The first word of a code tells who set it. - Codes starting with client are set by the registrar that manages the domain, sometimes automatically at registration, sometimes on the registrant's request. - Codes starting with server are set by the registry. They take precedence: a registrar cannot change a server code, while a registry may override a client code under its own policies. - Codes with neither prefix, such as ok, inactive and the pending codes, are managed by the registry. In both cases, the registrant asks the registrar. For a server code, the registrar passes the request to the registry, so removal usually takes longer. ## Lock codes: what is blocked and why Four pairs of codes each block one action. While one is set, the registry rejects the matching request: - clientTransferProhibited and serverTransferProhibited: a transfer to another registrar. - clientUpdateProhibited and serverUpdateProhibited: changes to the domain, such as contacts or name servers, other than removing the lock itself. - clientDeleteProhibited and serverDeleteProhibited: deletion. - clientRenewProhibited and serverRenewProhibited: renewal. The client transfer, update and delete locks help protect against hijacking and fraud. The renew locks are rare: they usually appear during legal disputes or before a deletion. For gTLDs, ICANN's Transfer Policy, in the version published on 21 February 2024 and in force as of October 2026, limits clientTransferProhibited. If the registrar offers no self-service way to remove it, it must remove it within five calendar days of the registrant's request, and it may not refuse only because of a payment dispute. As of October 2026, changes to the Transfer Policy have been adopted but are not in force. The ICANN Board adopted them on 7 June 2026 (resolution 2026.06.07.04), and no effective date has been announced. They include a mandatory restriction on transfers in the first 720 hours (30 days) after registration. The registrar can confirm which rules apply. Server locks are uncommon. ICANN names legal disputes, the registrant's own request and a domain in redemptionPeriod as the usual reasons. Some registries offer a registry lock service, requested through the registrar, that uses server codes as extra protection. ## Hold codes: why a domain stops working clientHold and serverHold tell the registry not to publish the domain's delegation in the DNS. The website and email stop working, but the domain stays registered. clientHold is uncommon. ICANN documents link it to non-payment, legal disputes, pending deletion, unverified contact details and stopping DNS abuse. serverHold is set by the registry; ICANN's compliance advice says registries should usually refer abuse cases to the registrar first. Two other situations look similar: - inactive: no name servers are linked, so the domain does not resolve, but the registration is fine. If it lasts several days, ICANN suggests contacting the registrar; some TLDs require documents first. - Expiry: after expiry, the registrar must stop the domain resolving for part of the time in which the registrant can still renew, where the registry allows it. The domain may show no hold code. ## Pending and grace period codes The pending codes (pendingCreate, pendingUpdate, pendingRenew, pendingTransfer and pendingDelete) mean a request has been received but not completed. During a sunrise period, pendingCreate may mean the name will be allocated when that period ends. The grace period codes (addPeriod, renewPeriod, autoRenewPeriod and transferPeriod) are informative. If the registrar deletes the domain during one of them, the registry gives the registrar a credit for the cost of the registration, renewal or transfer. The credit goes to the registrar, not to the registrant. Each registry sets the length of each grace period. Deletion follows these steps in gTLDs (as of October 2026): 1. The registrar deletes the domain. The EPP status becomes pendingDelete and the RGP status becomes redemptionPeriod, which lasts 30 days, except in sponsored gTLDs. The domain does not resolve and cannot be transferred. 2. If the registrar requests a restore, the status becomes pendingRestore while the registry waits for a restore report, a window ICANN describes as frequently seven days. If the report arrives, the domain returns to ok or to its earlier status. If not, it goes back to redemptionPeriod. 3. If the domain is not restored, it stays in pendingDelete for five calendar days after redemptionPeriod ends, then is removed from the registry database and becomes available to register. ## What to do about an unexpected status - Look the domain up in ICANN Lookup, note whether the code is a client or a server code, and contact the registrar. For server codes, the registrar deals with the registry. - pendingTransfer or pendingUpdate that the registrant did not request: contact the registrar immediately and, for a transfer, ask it to deny the request. - redemptionPeriod: contact the registrar at once to discuss the options. For a specific case, the registrant should check with the registrar, the registry or a lawyer. A worked example: ICANN Lookup shows example.com as "client transfer prohibited", and the registrant wants to change registrar. They remove the lock in their account or ask the registrar to remove it. Once the transfer is requested, the domain shows pendingTransfer; if the current registrar does not respond within five calendar days, the registry completes it. Afterwards the domain may show transferPeriod, which needs no action. ## Sources - [EPP Status Codes | What Do They Mean, and Why Should I Know?](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) - [Transfer Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - [Approved Resolutions | Regular Meeting of the ICANN Board | 7 June 2026](https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-06-2026-en) - [Expired Registration Recovery Policy](https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-28-02-2013-en) ## related terms - [EPP](https://tldlog.com/glossary/epp/) - [clientHold](https://tldlog.com/glossary/clienthold/) - [serverHold](https://tldlog.com/glossary/serverhold/) - [clientTransferProhibited](https://tldlog.com/glossary/clienttransferprohibited/) - [RDAP](https://tldlog.com/glossary/rdap/)