Domain status codes describe what is happening to a registration and which operations are currently allowed. They can explain why a transfer, update, or DNS delegation does not proceed. A single code rarely tells the whole story: a domain may show several statuses at once, and the code often describes an effect without identifying the business or technical cause.

Read the entire status set alongside your account details, relevant dates, and notices from the registrar. Registrars and registries use the Extensible Provisioning Protocol (EPP) to manage domain registrations. The Registration Data Access Protocol (RDAP) presents registration data in a different format: client transfer prohibited, for example, corresponds to clientTransferProhibited. The wording changes, but the client prefix still identifies a registrar-set restriction.

Read the Whole Status Set

Begin with a registration-data lookup or the registrar's domain page and note every status shown, not just the first alarming word. Record the exact domain, observation time, expiration date, and registrar identity. A result can include both a transfer restriction and an update restriction, or a pending action alongside a lifecycle state. The statuses should be interpreted together, and a later lookup can reflect a change after the registrar processes a request.

Do not treat ok or active as proof that a website loads. The EPP status ok describes a registration with no pending operations or prohibitions. RDAP's active value concerns the registered object's use and, for a domain, publication in DNS. Neither checks that the web server, TLS certificate, application, or mailbox works. Conversely, a broken page does not by itself tell you which registration status changed.

Look at the events and nameservers if the data source provides them. A registration event records the initial registration of the object, not when a website first appeared or who currently controls every related service. Read the event labels rather than treating every date as an ownership history.

Distinguish Client from Server Codes

In an EPP domain status, a client prefix identifies a restriction set by the registrar, while a server prefix identifies one set by the registry operator. The part after the prefix tells you which operation is blocked:

  • clientTransferProhibited and serverTransferProhibited prevent transfers to another registrar.
  • clientUpdateProhibited and serverUpdateProhibited prevent registration updates.
  • clientDeleteProhibited and serverDeleteProhibited prevent deletion requests.
  • clientRenewProhibited and serverRenewProhibited prevent renewal requests.

A registrar cannot directly remove a registry-set status. If both clientTransferProhibited and serverTransferProhibited are present, clearing the client restriction leaves the server restriction in place. Each restriction must be considered for the operation it controls.

The registrant usually contacts the registrar, even when the registry set the code, because the registrar manages the customer registration and can coordinate with the registry. Ask whether a status was applied for a requested security control, a policy process, an unpaid registration, or another reason. The code alone may not identify that reason.

Do not confuse transfer protection with a blanket lock on all functions. A domain can have clientTransferProhibited but still allow some updates, subject to other statuses and rules. Read the verb in the status name: transfer, update, delete, or renew. Then ask which operation you are trying to perform and whether another code also affects it.

Separate Lifecycle States from Restrictions

Some codes indicate an action is in progress. pendingCreate means the registry has not finished a registration request; pendingRenew, pendingTransfer, and pendingUpdate describe unfinished renewal, transfer, and update requests. These statuses call for confirmation of the final result, rather than an assumption that the request succeeded. If a status persists or the deadline is close, give the registrar the order reference and ask for the processing outcome.

Recovery and Final Deletion

redemptionPeriod means a deletion-related recovery stage is under way. For a domain registered under a generic top-level domain (gTLD), the current registrar can request restoration during this recovery window. Confirm the deadline and any restoration fee with that registrar; changing hosting or requesting an ordinary renewal is not a substitute for restoration.

pendingRestore means the registrar has requested restoration and the registry is waiting for the required restoration report. If the registrar does not submit it within the registry's deadline, the domain returns to redemptionPeriod. Ask whether the report has been accepted, rather than assuming that a restoration payment completed the process.

pendingDelete can accompany redemptionPeriod or pendingRestore, so it does not always mean that recovery has ended. Without either accompanying recovery status, it indicates the final deletion stage in this process, when ordinary restoration is no longer available. The extension's rules and current state determine the remaining options; the original expiration date alone does not establish a release date.

DNS Holds and Missing Delegation

clientHold or serverHold means the registry must withhold the domain's DNS delegation, which can stop the name from resolving. The inactive code indicates that delegation information has not been associated with the domain. A hold can have more than one cause, and inactive need not mean the registration has expired. Ask the registrar whether a missing nameserver setting, verification issue, policy action, or other condition is involved.

Interpret Grace-Period Codes Separately

Grace-period codes describe a period after a registration operation, rather than an operation still waiting to finish. The main values identify different events:

  • addPeriod follows the initial registration.
  • renewPeriod follows an explicit renewal submitted by the registrar.
  • autoRenewPeriod follows an automatic registry renewal after the registration period expires.
  • transferPeriod follows a completed transfer to another registrar.

These periods concern the registry's handling of registration charges and possible credits to the registrar if the domain is deleted under the applicable rules. They do not establish that you paid a renewal invoice or that you qualify for a customer refund. Check the registrar's account record and terms for those questions, and confirm the period's length for the exact extension.

Contact the Party That Can Change the Status

For a registrar-set transfer or update restriction, use the registrar's authorized account process or support desk to find out whether removal is permitted. Some registrar-set transfer restrictions enforce mandatory policy periods and cannot simply be switched off. If a server-level restriction is present, ask the registrar to identify the registry process and any additional authorization required. A requested registry-lock service can require an extra approval step, but a server status does not prove that such a service was purchased.

For a pending renewal, transfer, or restore action, ask the provider that submitted it for its transaction status. For a hold or missing delegation, ask why DNS activation is blocked and whether the registrar or registry must clear a condition. For a restoration stage, ask the current registrar about eligibility, fees, and next steps under the exact extension's rules. Avoid changing website hosting to solve a registration status restriction.

Never remove a protective restriction just to make a warning disappear. Confirm the intended change, who requested it, and how to restore protection afterward. If a status appears without an action you recognize, secure the registration account and contact the registrar promptly before authorizing another request.

Verify the Explanation with the Registrar

Send the registrar the full code list, exact domain, relevant dates, and the operation that failed. Ask who set each important status, what event or policy caused it, and what approved action will change it. Keep the response and check the registration data again after the provider reports a fix. If the expected status has not changed, return with the new lookup result and transaction reference so the registrar can check the remaining restriction.