EPP status codes: All domain name status codes explained

EPP status codes are the read-only control plane of your domain portfolio. They are the one public surface where anyone can read a domain’s real security and lifecycle state: you, an auditor, a customer, or an attacker probing your names for a soft target.

This is the complete, current reference. All 23 codes, what each one means, how urgent it is, and how to enforce a status baseline across 50 or 5,000 domains rather than one name at a time. By the end you should be able to answer a single question: is my domain portfolio in the state I think it is in?

What EPP status codes are and who sets them

EPP status codes are standardized labels attached to a domain that report its current state. Registrars and registries set them through the Extensible Provisioning Protocol, defined in STD 69 (RFC 5730 to 5734), the machine-to-machine protocol they use to create, transfer, update and delete domain names. RFC 3915 adds the Registry Grace Period statuses that track a domain through expiry and deletion.

There are 23 codes in total: the 17 standardized EPP statuses plus 6 Registry Grace Period statuses. ICANN publishes the canonical list, arranged as 18 server and RGP codes and 5 client codes. These are not per-registrar inventions. serverHold means the same thing whichever registry sets it.

When a registrar applies a Transfer Lock, or a registry drops a domain into its deletion pipeline, that action surfaces as a status code anyone can read. That is what makes the set a control plane rather than documentation. The levers themselves, whether a domain can be transferred, updated, deleted or resolved, live in EPP. The status codes are the public readout of where every lever currently sits.

The prefix tells you who holds the lever, and reading it is the fastest triage available:

• The registrar sets client-prefixed codes at your request, and can add or remove them in minutes.
• The registry sets server-prefixed codes. Your registrar cannot lift them. Only the registry can, and normally only after a defined out-of-band verification process.
• Some codes appear automatically. addPeriod, autoRenewPeriod, redemptionPeriod and pendingDelete arrive on their own as the domain moves through its lifecycle. Nobody types them in.

All 23 EPP status codes: the reference table

Urgency here is deliberately blunt. Urgent means act now. Protective means keep it. Verify means read it and check whether it is intentional. Informational means note it and move on.

Client codes, set by your registrar

Server and Registry Grace Period codes, set by the registry

How EPP status codes combine

A domain usually carries several codes at once, and it should. A healthy critical name typically shows clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited together, with the server-side equivalents on top if it carries a Registry Lock. Prohibited codes are additive: each blocks its own operation and they never conflict. Three rules govern the rest. A hold overrides resolution, so a fully locked domain with serverHold is still offline. pendingDelete overrides protective codes, because the deletion pipeline proceeds regardless. And ok is mutually exclusive with everything else, so if you can see ok, there are no locks.

The practical read: a healthy business-critical domain shows a stack of prohibited codes, never shows ok, never shows a hold, and never shows a pending code you did not initiate. Anything else on a critical name is a finding.

Where to read EPP status codes: RDAP, not WHOIS

If your instinct is still to run a WHOIS lookup, update it. On 28 January 2025 ICANN removed the contractual obligation for gTLD registries and registrars to run WHOIS on port 43. RDAP, the Registration Data Access Protocol, is now the mandatory protocol and the authoritative source for gTLD registration data, status codes included. In January 2026 ICANN revoked a registrar’s accreditation for failing to implement RDAP, which settled any remaining question about whether compliance was optional.

WHOIS has not vanished. Operators may keep running it, and Verisign committed to maintaining WHOIS for .com in parallel with RDAP. But it is no longer canonical, and building domain portfolio monitoring on WHOIS scraping now means depending on a service any registry can switch off without notice.

RDAP returns structured JSON over HTTPS, which is what you want at scale. Its status values are the EPP codes with spaces inserted, so clientTransferProhibited reads as client transfer prohibited and no translation table is needed. There is one exception worth knowing before you parse anything: EPP’s ok surfaces in RDAP as active. The authoritative list lives in the IANA RDAP JSON Values registry.

Where to look, in order of usefulness: RDAP queries against the responsible registry or registrar for a single authoritative read; your registrar or platform control panel for the domain portfolio you sponsor; and API responses for anything at scale, because manual per-domain lookups do not survive contact with a 500-domain portfolio.

The RGP clock: how little time you actually have

If you manage a domain portfolio, the Registry Grace Period lifecycle is where money is won and lost, and the status codes are your only warning. Here is the sequence a domain follows after expiry:

1. Expiry. The registration term ends.
2. autoRenewPeriod. A grace window, often around 45 days depending on the registry, during which the domain may auto-renew or be renewed at normal cost. Still fully recoverable.
3. redemptionPeriod. The domain has been deleted from the zone, but the original registrant can still restore it through the sponsoring registrar. This window runs 30 days, and restoration carries a registry-set restore fee well above a normal renewal.
4. pendingDelete. The final stage, typically around five days. It cannot be interrupted or reversed. Once this appears, the domain is effectively gone.
5. Drop. The domain returns to the available pool and anyone can register it.

The 30-day redemption window is not a registry courtesy. ICANN’s Expired Registration Recovery Policy requires all gTLD registries, sponsored gTLDs aside, to offer it. Restore fees, by contrast, are set per registry and vary widely, so confirm the figure for the specific extension rather than assuming one number.

Two caveats. Exact windows differ by registry and by TLD, and many ccTLDs run a different lifecycle entirely. And the RGP clock is public, which means an expired domain in redemptionPeriod is visible to competitors and drop-catchers watching for precisely that signal.

The only reliable defense is not reacting once redemptionPeriod appears. It is auto-renew plus expiry monitoring, so a critical domain never reaches expiry unnoticed. By the time you are reading redemptionPeriod off a status query, you are paying a restore fee at best and losing the name at worst.

Transfer Lock and hijack signals

Transfer-related EPP status codes are where status reading crosses fully into security.

clientTransferProhibited blocks outbound transfers, and it belongs on every business-critical domain. It is one of the cheapest and most effective controls available. Remove it only deliberately, at the start of a planned transfer, and re-apply it the moment the transfer completes. The answer to “should I remove it?” is no, unless you are actively moving the domain right now.

pendingTransfer means a transfer is in progress. If you initiated it, fine. If you did not, treat it as a live hijack attempt. The likely cause is a compromised registrar account: someone got in, removed the Transfer Lock, pulled the auth code and started moving the name. Act in this order:

1. Contact your registrar and have them deny the transfer request on your behalf. This is the step that stops the transfer, and it is time-limited: an unanswered request auto-approves after five days.
2. Re-apply clientTransferProhibited, the Transfer Lock, and confirm it is visible in RDAP.
3. Rotate the auth code, which prevents a repeat attempt but does nothing about the request already in flight.
4. Lock down the account: credentials, MFA, and a full review of who has access.
5. For a high-value name, escalate to the registry in parallel.

Speed matters, because once a transfer completes to a different registrar, recovery stops being a support ticket and becomes a formal dispute. Our guide to domain hijacking and what to do if it happens walks through how difficult reclaiming a stolen domain actually is.

This is what makes EPP status codes a security surface rather than a reference. The moment an attacker changes your domain’s state, the status codes change with it. An unexpected pendingTransfer or pendingUpdate is the earliest external signal of a compromised registrar account, usually visible before any downstream damage.

Why can I not transfer a domain I just registered?

Today, ICANN’s Transfer Policy imposes a 60-day inter-registrar lock after three events: a new registration, a completed transfer, and a change of registrant. The change-of-registrant trigger is the one that blocks portfolio consolidations and post-acquisition cleanups, because editing a registrant name or email starts the clock again.

As of Q3 2026 that regime is mid-reform. ICANN has approved changes that remove the change-of-registrant lock entirely and replace the other two triggers with a mandatory 720-hour, or 30-day, lock, standardizing what was previously left to registrar discretion. Rollout happens registrar by registrar over roughly 18 months, so plan time-sensitive migrations around 60 days until your registrar confirms the shorter window is live.

Reading the prefix: Transfer Lock or Registry Lock

The same three prohibited operations exist at both layers, which means the prefix is the only thing in a status query that tells you which control you are actually looking at.

clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited are a Transfer Lock and its siblings: applied inside your account, removable in minutes, and removable by anyone who compromises that account. The server-side equivalents are a Registry Lock: only the registry can lift them, and only after manual out-of-band verification, which is what defeats an attacker who already holds your credentials.

So the prefix answers a question the codes alone do not. Three server-side prohibited codes mean the domain is genuinely hardened. Three client-side codes mean it is protected against accident and opportunism, not against someone who is already inside your account. Our Registry Lock deep dive covers eligible TLDs, the verification process, and the lead time that friction costs you.

Setting an EPP status baseline across a domain portfolio

A code reference only earns its keep when it becomes an enforced policy. Here is how to turn the control plane into a defensible baseline.

Step 1: classify domains into tiers.

Write this down. It is the standard you audit against.

Step 2: audit current state across every registrar. Query status via RDAP or your platform API for every domain, wherever it is sponsored. Flag any critical or brand domain showing ok, any hold, or any pending code you did not initiate. This is where fragmented, acquisition-inherited domain portfolios reveal their gaps, usually as forgotten names sitting wide open at a legacy registrar.

Step 3: remediate and document. Close every gap against the baseline, then record who can change what and keep the change history. The documentation is what makes the state defensible later, in an audit or a dispute.

Step 4: plan around lock windows before any consolidation. Domains under a Registry Lock need their verified unlock scheduled in advance. The inter-registrar lock, currently 60 days, dictates when a moved domain can move again. Map these windows before you commit to a migration date, not after.

At 50 domains you can do parts of this by hand. At several hundred across multiple registrars you cannot, and applying or auditing EPP status baselines in bulk is precisely what a platform is for. Our overview of domain management tools covers the bulk and API features that make this manageable, and AutoDNS lets you enforce and verify a baseline across an entire domain portfolio through one interface rather than logging into each registrar in turn.

Monitoring EPP status code changes at scale

An audit is a snapshot. The control plane only works if you keep watching it, because the value of a read-only surface is catching the moment the state changes.

What to alert on:

• A critical or brand domain dropping a prohibited code it should carry. A lock disappearing is a signal whether or not the change was authorized.
• clientHold or serverHold appearing on a live name.
• pendingTransfer, pendingUpdate or pendingDelete that you did not initiate.
• A critical domain reverting to ok.

How to do it: scheduled RDAP or API polling feeding a system that compares each domain’s current status against its expected baseline and alerts on drift. Manual checks do not scale past a handful of names and will always lag the event that matters. Our domain monitoring guide covers the wider discipline, including watching the names you do not own, and defensive registration covers the long tail you hold purely to keep others from having it.

Continuous monitoring turns the read-only control plane into an early-warning system. The same surface that reports normal state also flags the first move of an attack, usually before any service is affected.

That is the reframe in one line. Your EPP status codes are the auditable proof that your domain policy is in force rather than merely written down. Read them, enforce them and monitor them, and you can answer the question this article started with: yes, my domain portfolio is in the state I think it is in.

Read your portfolio, do not guess at it

EPP status codes turn domain security from an assumption into something you can verify. If you want to see what enforcing a status baseline looks like across a whole domain portfolio, explore how AutoDNS applies locks, monitoring and audit trails on EU-based, API-first infrastructure, or talk to an InterNetX partner manager about consolidating your domains onto one platform.

Frequently asked questions