Domain transfer lock and the 60-day rule: why a client's domain won't move (and what to do)
By the RenewRoster team · · 6 min read
You've agreed with a client to move their domain to a registrar you manage, you have the auth code, and the transfer is refused. Nine times out of ten it's one of three things: a lock switched on at the registrar, a domain that was registered or transferred recently, or a recent change to who owns it. This guide explains each one, how to check which applies, and how to plan handovers so a transfer never lands in the same week as a renewal.
This applies to generic domains like .com, .net and .org, which follow ICANN's Transfer Policy. Country domains (.uk, .in, .de and so on) set their own rules, so check the registry's page for those.
The three kinds of "locked"
1. The registrar lock (a setting you can switch off)
Most registrars switch on a transfer lock by default. In the domain's public record it shows as the status clientTransferProhibited. It's a security feature, not a penalty: it stops anyone transferring the domain without first logging in to the account.
Fix: the account holder logs in, turns off "transfer lock" or "domain lock", and requests the auth code (also called the EPP code). See how to get the auth code at GoDaddy, Namecheap, Cloudflare and Spaceship. Under the current policy the registrar has to provide the code within five calendar days, though most show it instantly.
If you see serverTransferProhibited instead, the lock is set by the registry, usually because of a dispute, a legal hold or a security service the client pays for. The registrar's support team has to help with that one.
2. The 60 days after registration or a previous transfer
Under ICANN's current Transfer Policy, a registrar may refuse a transfer within 60 days of the domain being registered or of its last transfer between registrars. It's a "may", not a "must", but most registrars apply it.
What it means for agencies: if a client bought a domain last month, you can't consolidate it into your registrar account yet. Write the earliest transfer date in your records and come back to it.
3. The 60-day lock after a change of registrant
This is the one that catches agencies out. When the registrant's name, organisation or email address changes in a material way, the registrar applies a 60-day lock on moving the domain to another registrar. Some registrars let the registrant opt out before the change is made; many don't.
It typically bites during a handover. You fix a domain registered in an ex-employee's name, update the email to the client's real address, and then can't move it for two months.
Fix: order the steps carefully.
- If the domain needs to change registrar, transfer it first.
- Then correct the registrant details at the new registrar.
- If you have to change the registrant first, ask the registrar whether it offers an opt-out from the 60-day lock and use it before making the change.
Moving a domain to another account at the same registrar (a "push" or internal transfer) usually isn't affected by these locks, which makes it a useful option when the client and agency both use the same registrar.
How to check whether a domain is locked
Look up the domain's registration record (RDAP, the modern replacement for WHOIS). Three fields tell you almost everything:
- Status:
clientTransferProhibitedmeans a registrar lock is on;serverTransferProhibitedmeans a registry lock. - Created date: less than 60 days ago means a refusal is likely.
- Last updated / last transferred: a recent transfer means the 60-day window may still apply.
Registrant changes don't always show publicly because of privacy redaction, so ask the client whether ownership details changed recently.
Our bulk domain expiry lookup shows the registrar and expiry date for a whole list of domains at once, and the guide to finding which registrar a client's domain is with covers the edge cases.
Don't leave a transfer until the week of the renewal
A transfer takes up to five days at the losing registrar, plus however long it takes the client to find their login. If the domain expires in the middle, you're dealing with an expired domain instead (see what happens when a client's domain expires).
A safer rule of thumb: start any transfer at least 30 days before the expiry date, and if a 60-day lock might apply, start planning 90 days ahead. Most generic-domain transfers also add a year of registration, so moving a domain early rarely wastes money.
Planning handovers around the locks
When you take on or hand back a client, the transfer lock is the step most likely to slip. Build it into your checklists:
- Onboarding: record each domain's created date, last transfer date and expiry date. Note which ones can't move yet. Our client onboarding checklist covers what else to collect.
- Offboarding: do the registrar transfer before any registrant change, and give the client the auth code well before the expiry date. See the client offboarding checklist.
The rules are changing (but not yet)
On 7 June 2026, ICANN's Board adopted recommendations from its Transfer Policy Review. They include replacing the 60-day windows with a mandatory 30-day lock after registration and after a transfer, a one-time transfer code that expires after 14 days, and removing the 60-day lock after a change of registrant. No effective date had been published at the time of writing, so today's 60-day rules still apply. We'll update this page when ICANN announces a date.
Keep the dates in one place
Let RenewRoster watch every renewal for you
RenewRoster tracks every client's domain and SSL expiry dates, sends reminders at 60, 30, 14 and 3 days (under your agency's brand if you like) and gives you a monthly renewals report. Free for 5 domains, no card needed.
Sources
- ICANN: Transfer Policy
- ICANN Board: Approved Resolutions, Regular Meeting 7 June 2026 (Transfer Policy Review)