Domain status codes: which ones take your site offline

A domain status code is a flag the registry keeps on your domain registration, and only a handful of them take a site offline: clientHold, serverHold, inactive, and the deletion states redemptionPeriod, pendingRestore and pendingDelete. The rest are locks or short processing flags. Several locks at once are normal: example.com carries three and google.com six, and none of them affect whether the site loads.

That split is what matters when you read a WHOIS or RDAP record, or when a monitoring tool reports that a status changed. ICANN’s own EPP status code reference explains what each code means. It does not tell you which ones break resolution, or which changes deserve a page at 3 a.m. This post does both.

Where you see these codes

The codes come from EPP, the protocol registrars use to talk to registries, and are defined in RFC 5731. ICANN counts 17 standardized EPP codes plus the grace-period codes from RFC 3915. WHOIS prints them in camelCase. RDAP, the protocol replacing WHOIS, prints the same codes in lowercase with spaces, using the mapping in RFC 8056, so clientTransferProhibited becomes client transfer prohibited and ok becomes active.

example.com is a typical healthy record. Its RDAP status on 20 October 2026:

"status": ["client delete prohibited", "client transfer prohibited", "client update prohibited"]

Three registrar locks, nothing else. That is a normal, healthy domain. If you want the rest of the RDAP response explained field by field, reading an RDAP response walks through it.

Every domain status code, and whether the site still resolves

The "set by" column follows RFC 5731: codes that start with client are set by the registrar, codes that start with server are set by the registry, and the rest are managed by the registry. The resolve column says whether the domain is still published in DNS while the code is present. The last column is our recommendation for monitoring.

Six rows in that table answer no or usually no, and those are the ones that take a site down. Everything else leaves DNS untouched. The redemption and pending-delete rows are part of what happens after a missed renewal; the timeline is covered in domain expiry monitoring, so it is not repeated here.

What a hold looks like from the outside

RFC 5731 defines both holds in one line: for clientHold and serverHold, "DNS delegation information MUST NOT be published for the object." The registration still exists. It still lists its nameservers. The registry stops telling the world where they are.

Here is a real .org domain on serverHold, checked on 20 October 2026. The name is replaced, the output is not. WHOIS shows the hold alongside a set of server locks:

Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
Domain Status: serverHold https://icann.org/epp#serverHold
Domain Status: serverRenewProhibited https://icann.org/epp#serverRenewProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited

RDAP for the same domain still lists three nameservers. Asking the .org registry’s own nameserver directly, with recursion turned off, gives an authoritative NXDOMAIN, as if the domain did not exist:

$ dig @a0.org.afilias-nst.info. held-domain.org NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37235
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

For comparison, a normal .org domain gets a referral to its nameservers from the same server:

$ dig @a0.org.afilias-nst.info. example.org NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34479
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

That pair of checks is the fastest way to tell a hold apart from the problems that look like it from a browser:

• RDAP lists nameservers, the TLD server says NXDOMAIN: the registry is not publishing the domain. Look for clientHold or serverHold and call the registrar.
• RDAP lists no nameservers and shows inactive: nothing was ever attached, or someone removed it. Fix the nameservers at the registrar.
• The TLD server returns a referral, but the site still fails: the registration is fine. The problem is at your DNS provider or your server.

One limit: the code never says why. ICANN lists the usual reasons for clientHold as "legal disputes, non-payment, or when your domain is subject to deletion". For server codes, an IETF draft on RDAP status reasons notes there can be "many overlapping reasons", such as "complying with a court order, or addressing domain abuse". The registrar is the only place that will tell you which one applies to your domain.

The combination rules that tell you what happens next

RFC 5731 also says which codes cannot appear together, and those rules are more useful to a monitor than any single code:

• pendingTransfer cannot coexist with a transfer lock. The spec says "pendingTransfer" status "MUST NOT be combined with either clientTransferProhibited or serverTransferProhibited". So in any transfer, the lock disappears first. Removal of clientTransferProhibited is the earliest visible step, before the transfer itself shows up. The full hijack sequence is in how to detect domain hijacking.
• pendingDelete changes meaning depending on what is next to it. ICANN’s reference says pendingDelete "may be mixed with redemptionPeriod or pendingRestore", and that on its own it means the domain has already spent 30 days in redemption without being restored. With redemptionPeriod next to it, you can still restore the name. Without it, you are in the last few days before the name is released.
• ok stands alone. The spec says "ok" status "MUST NOT be combined with any other status". If a record shows ok, nothing else is set.
• You cannot remove a server code yourself. "A client MUST NOT alter status values set by the server." A registrar can ask the registry; you can only ask the registrar.

Why "uncommon" codes are not alarms

ICANN’s reference calls serverDeleteProhibited "an uncommon status that is usually enacted during legal disputes, at your request, or when a redemptionPeriod status is in place". Read literally, that makes it sound like trouble. google.com, checked the same day, shows why it usually is not:

"status": ["client delete prohibited", "client transfer prohibited", "client update prohibited", "server delete prohibited", "server transfer prohibited", "server update prohibited"]

All three server locks. That is what a registry lock looks like from outside: a server-side lock, such as Verisign Registry Lock for .com, that needs out-of-band verification before any change. How it works and when it is worth paying for is covered in how to detect domain hijacking.

Our position: alert on changes, not on presence. A server lock that has been there for two years is protection. The same lock appearing overnight on a domain that never had one is worth a look. And a lock that disappears is worth more attention than one that appears.

What to alert on

• Alert: clientHold, serverHold, inactive on an established domain, redemptionPeriod, pendingDelete, a pendingTransfer you did not start, and the removal of a transfer lock.
• Review: a server lock that was not there before, clientRenewProhibited or serverRenewProhibited, autoRenewPeriod, pendingRestore, and any pending code that stays for more than a few days.
• Ignore: ok or active, locks that have always been there, and the add, renew and transfer grace periods.

WebPixie’s domain monitoring runs a daily WHOIS or RDAP check that reads these status flags along with transfer locks and expiry. Expiration and suspended-domain states trigger alerts, and a domain entering a suspended state such as a registrar hold opens an incident automatically. Other registrar, nameserver and status changes are shown with the previous and current value side by side for review.