Diagnostic Security / Takeover Risk
Transfer lock unexpectedly removed
You check your domain one day and the transfer lock is just gone. Nobody on your team asked for it. Nobody clicked "unlock." But the status that used to sit there, quietly stopping anyone from moving your domain to another registrar, is no longer in the record. This one is not a DNS record problem. It is a security problem, and it needs to be treated like one right away.
The clientTransferProhibited status is a lock your registrar sets that tells the registry "reject any request to move this domain to another registrar." It is the main thing standing between your domain and a hijack. If it disappears without you asking, that usually means someone got into your registrar account, talked support into removing it, or a registrar bug dropped it by accident. Once it is off, anyone with the domain's EPP auth code can start moving it away. Check RDAP or WHOIS right now, and if the lock is missing, log in to the registrar directly, check for other unauthorized changes, and turn the lock back on before you do anything else.
The problem in plain words
Think of the transfer lock as a padlock on the front door of your domain. When it is on, the registry will not even look at a transfer request from another registrar, no matter what code someone types in. When it is off, the door is unlocked, and all it takes to walk the domain out is one valid EPP auth code, sometimes called an authorization code or transfer code.
Normally you only remove this lock yourself, on purpose, right before you move a domain to a new registrar. The lock disappearing at any other time is a red flag. It can mean an attacker got into your registrar account and turned it off as the first step toward stealing the domain, or that a support agent was social-engineered into unlocking it, or that a bug in the registrar's own automation dropped the status by mistake. Because this status lives at the registrar and registry level, not in your DNS zone, most owners never look at it and would not notice it is gone until a transfer confirmation email shows up, or until the domain has already moved.
Why it happens
ICANN's EPP status code reference explains that clientTransferProhibited is set and cleared by the registrar, and it is the main protection against unwanted inter-registrar transfers. It normally goes off only when the owner asks for it. A few common ways it goes off without anyone meaning to:
- An attacker gets into the registrar account (a reused password, a phished login, a stolen session) and removes the lock as the first step before requesting a transfer.
- Someone calls or emails the registrar's support team, pretends to be the domain owner, and talks them into unlocking the domain "to help with a transfer."
- A bug or a misconfigured bulk-action tool in the registrar's own portal or API removes the lock from the wrong domain in an account that manages many domains.
- An account takeover changes the recovery email or phone number first, so the real owner cannot even get the alert emails that would normally flag the unlock.
Because the lock lives in the registrar/registry layer and not in your DNS zone, it is invisible unless you go looking at RDAP or WHOIS directly. Many owners never notice until a "your domain transfer has been initiated" email lands, or worse, until the domain has already moved and DNS starts answering from somewhere else entirely.
This status is not a DNS record and it is not something a DNS host's API can see or change. It lives on the domain's registration at the registrar and registry. If it disappears and you did not ask for it, assume the registrar account itself may be compromised, not just this one setting, and check the account before you check anything else.
The fix, as a flow
Do not just flip the lock back on and move on. Treat this like an account security incident first, and a settings fix second. Check what else changed on the account, re-lock the domain, rotate anything that could have been exposed, and if a transfer is already underway, contact the registrar immediately since there is a strict window to reject it.
How to fix it
Log in to the registrar directly and look for other changes
Go to the registrar's site by typing the address yourself, not by clicking a link in any email. Check the account email, the recovery email or phone, the two-factor method, and any API keys or account access grants. If any of these were changed and you did not change them, the account itself is compromised, not just this one lock.
Turn the registrar transfer lock back on
In the domain's management panel, find the lock toggle and switch it back on so the domain returns to clientTransferProhibited. The wording differs by registrar but the idea is the same everywhere.
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: ok https://icann.org/epp#ok
; Where to toggle it back on, by registrar:
; Namecheap: Domain List -> Manage -> "Registrar Lock" -> ON
; GoDaddy: Domain Settings -> "Lock" -> ON
; Cloudflare: Domain page -> "Locked" -> ONReset the password and rotate the EPP auth code
Even after the lock is back on, reset the account password and generate a new EPP authorization code (also called an auth code or transfer code). If the old code leaked, it needs to be invalidated, since a leaked code plus a future unlock would put you right back here.
Turn on two-factor authentication
Confirm 2FA is enabled on the registrar account, and set it up now if it was not. This is the single control that stops most of the account-takeover paths that lead to a lock being removed in the first place.
If a transfer is already pending, reject it now
If the status shows pendingTransfer or a transfer period, contact your current registrar's abuse or support team immediately and ask them to Nack (reject) the transfer. Under ICANN's Transfer Policy you have a standard five day Ack/Nack window before the transfer completes automatically. If it completes anyway, file a transfer dispute with the registry or ICANN right away.
Consider a registry-level lock for extra protection
Where the registrar and registry support it, add a server-side lock (serverTransferProhibited), sometimes sold as a Registry Lock service through Verisign-partnered registrars. Removing this kind of lock requires an out-of-band verification step, which is a stronger barrier than the registrar-side lock alone.
How to check it worked
Query RDAP or WHOIS again and confirm the lock is back and no transfer is in progress.
# 1. Check status through RDAP (structured, machine-parsable, preferred)
curl -s https://rdap.org/domain/example.com | jq '.status'
# Or hit the registry's RDAP base directly, e.g. for .com/.net
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.status'
# 2. Cross-check with legacy WHOIS
whois example.com | grep -i "domain status"
# 3. Make sure no transfer is already in progress
whois example.com | grep -i pending
# 4. Re-check from a second source a little later to confirm it is consistent
# https://lookup.icann.org/en/lookupA good result looks like this: the RDAP status array includes "client transfer prohibited" (and/or "server transfer prohibited"), for example ["client transfer prohibited","active"]. In classic WHOIS, you should see the line Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited. The pending-transfer check should return nothing at all. A bad result is a status list with only ["active"], or a WHOIS reply with only Domain Status: ok https://icann.org/epp#ok and no transfer-prohibited line anywhere, which means the domain is still exposed. Give it fifteen to thirty minutes if you just changed it, since some registries take a short time to publish the updated status, and check it again from a second lookup tool to confirm both sources agree.
Case studies
The lock that disappeared after a phished login
An owner's registrar password was reused from a leaked list. An attacker logged in, quietly removed the transfer lock, and changed the recovery email so alert messages would not reach the real owner. The domain sat unlocked for two days before a teammate happened to check RDAP for an unrelated reason and noticed the status was missing.
The team logged in through a fresh browser session, found the recovery email had been swapped, reset the password, restored the recovery contact, rotated the EPP code, and turned the lock back on before any transfer request was ever filed.
The unlock that came from a convincing phone call
A caller told a registrar's support desk they were locked out and needed the transfer lock removed "to move the domain for a rebrand." Support removed the lock. A pendingTransfer status appeared at the registry two days later, along with a transfer confirmation email the real owner almost missed in a spam folder.
The owner caught the email in time, called the losing registrar's support line directly, and got the transfer rejected inside the five day Ack/Nack window. They re-locked the domain immediately afterward and asked the registrar to add a verbal PIN requirement to the account.
A healthy domain always shows clientTransferProhibited in RDAP and WHOIS unless you are the one actively moving it to a new registrar. When that status is present, an attacker with a leaked EPP auth code still cannot move the domain, because the registry rejects the transfer request outright. Check this status the same way you would check an SSL certificate expiry, on a routine schedule, not just when something already feels wrong.
FAQ
Why did my domain's transfer lock disappear on its own?
You probably did not remove it yourself. A common cause is a compromised registrar account, a support request an attacker talked their way through, or a bug in registrar automation. Once the lock is off, the domain can move to another registrar with only the EPP auth code, so treat this as a security incident, not a settings glitch.
How do I check if my domain's transfer lock is actually on?
Query RDAP or WHOIS and look at the status list. A healthy domain shows clientTransferProhibited (and sometimes serverTransferProhibited too). If the status list only shows something like active or ok with no transfer prohibited entry, the lock is off and the domain is exposed.
Can I fix a removed transfer lock through my DNS provider's API?
No. The transfer lock is an EPP status set at the registrar account level, not a DNS zone record, so a DNS provider's API like Cloudflare's cannot touch it. You have to log in to the registrar directly and turn the lock back on there.
Related field notes
Citations
On the problem:
- RFC 8056: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping. rfc-editor.org/rfc/rfc8056.html
- ICANN: EPP Status Codes, what do they mean, and why should I know? icann.org/en/resources/registrars/transfers
- ICANN Transfer Policy. icann.org/en/contracted-parties/accredited-registrars
On the solution:
- NameSilo: What Does clientTransferProhibited Mean in WHOIS? namesilo.com/blog
- NameSilo: Domain Transfer EPP Codes, Locks, and Timing. namesilo.com/blog
- ICANN RDAP Lookup Tool. lookup.icann.org/en/lookup
Stuck on a tricky one?
If you have a DNS, delegation, or domain security problem you would rather hand off, this is the kind of work I do. Message me and we can work through it together.
Did this catch a takeover in time?
If this helped you re-lock a domain before it moved, you can buy me a coffee. It is the best way to keep these field notes free and growing.
Buy me a coffee on Ko-fi