
What Is the 60-Day Domain Transfer Lock?
You found a cheaper registrar, unlocked your domain, copied the authorization code, and started the transfer, only to be told the domain "is not eligible for transfer for 60 days." It is one of the most common surprises in domain management, and it is not a bug or a registrar trying to hold you hostage. The 60-day domain transfer lock is a set of restrictions that come from ICANN's Transfer Policy and from how registrars apply it. This article explains the three situations that trigger it, which ones are mandatory and which are registrar discretion, how to work out exactly when your domain becomes eligible, and what your options are in the meantime. If you are planning a move, pair this with the step-by-step guide on how to transfer a domain to another registrar without downtime.
What Is the 60-Day Transfer Lock?
The 60-day transfer lock is a period during which a domain cannot be moved from one registrar to another (an inter-registrar transfer). It is not a single EPP status code you can see in WHOIS. Instead, it is a policy rule: the current registrar refuses, or is required to refuse, the transfer for 60 days after certain events.
It matters to understand what it does and does not block:
- It blocks moving the domain to a different registrar.
- It does not stop your website or email from working.
- It does not stop you from changing name servers or DNS records.
- It does not stop you from renewing the domain.
- It usually does not stop an internal move to another account at the same registrar.
So the lock is about which company manages your registration, not about whether your domain functions.
Why Does the 60-Day Lock Exist?
The rule exists mainly to fight domain theft and fraud. If a hijacker gets into a registrar account, the classic play is to change the owner details and then immediately move the domain to a different registrar, ideally one in another jurisdiction, where it is harder for the real owner to recover it. A waiting period gives the legitimate owner time to notice and reverse unauthorized changes while the domain is still at the original registrar. For a fuller picture of these attacks, see what domain hijacking is and how to prevent it.
It also limits payment fraud. Someone who registers a domain with a stolen credit card cannot instantly hop it to another registrar before the chargeback arrives.
The Three Situations That Trigger It
Under the long-standing ICANN Transfer Policy for generic TLDs such as .com, .net, .org, and the new gTLDs, there are three separate 60-day windows.
1. Within 60 Days of Initial Registration
When a domain is first registered, the registrar of record may deny a transfer request made within 60 days of the creation date shown in the registry record. This is one of the listed reasons a registrar is permitted to deny a transfer, so technically it is discretionary. In practice, almost every retail registrar enforces it automatically.
2. Within 60 Days of a Previous Inter-Registrar Transfer
After a domain moves to a new registrar, the new registrar may deny another transfer for 60 days. This stops "registrar hopping," where a stolen domain is bounced through several registrars to make tracing and recovery harder. Again, this is permitted rather than required, but it is applied almost universally.
3. After a Change of Registrant
This is the one that catches people off guard. Since the Transfer Policy was updated in December 2016, a Change of Registrant (often abbreviated COR) triggers a mandatory 60-day inter-registrar transfer lock unless the previous registrant opted out before the change.
A Change of Registrant is a material change to any of these:
- The registrant's name
- The registrant's organization
- The registrant's email address
- In some cases, the administrative contact's email address, if no registrant email was on file
Changing a postal address or phone number is not a material change. Fixing a typo in your name may or may not count, depending on how the registrar classifies it. Before making the change, the registrar must get confirmation from both the prior and new registrant (registrars often use a Designated Agent arrangement so this happens with one click), and it must offer the prior registrant the option to opt out of the 60-day lock.
That opt-out is important. If you are updating your own email address and you know you might move registrars soon, look for a checkbox along the lines of "Do not apply the 60-day transfer lock" before you save.
Summary Table
| Trigger | Mandatory or discretionary | Can you avoid it? |
|---|---|---|
| Initial registration | Registrar may deny | Rarely. A few registrars will release early on request. |
| Previous inter-registrar transfer | Registrar may deny | Rarely. Same as above. |
| Change of Registrant | Mandatory unless opted out | Yes, by opting out before the change is made. |
ICANN Has Been Revising These Rules
The rules above are the ones most people have dealt with for close to a decade, but they are not frozen. ICANN's GNSO ran a multi-year Transfer Policy Review policy development process, and its recommendations include changes to the post-registration and post-transfer restrictions and a rework of the Change of Registrant process, which many registrants found confusing. The ICANN Board has adopted recommendations from that review, and implementation is being phased in by registries and registrars.
Because effective dates and the exact durations depend on ICANN's implementation timeline and on how each registrar rolls out the changes, do not assume your registrar is on the old or the new rules. The practical advice is the same either way:
- Check your registrar's current transfer help page before you plan a time-sensitive move.
- Look at the actual dates on your domain (shown below) rather than guessing.
- If the registrar tells you the domain is locked, ask which rule applies and when it ends.
How the 60-Day Lock Differs From Registrar Lock
These two are often confused because both block transfers:
| Feature | Registrar lock | 60-day transfer lock |
|---|---|---|
| What it is | EPP status clientTransferProhibited | A policy restriction tied to an event and date |
| Visible in WHOIS? | Yes, as a domain status | Not directly; inferred from dates |
| Who controls it | You, via a toggle in your registrar account | Policy, enforced by the registrar |
| Can you remove it? | Yes, any time | Generally no, until the period ends |
| Purpose | Ongoing theft protection | Short-term protection after risky events |
Registrar lock is something you should keep on permanently, as explained in what registrar lock is and why you should enable it. The 60-day lock is temporary and automatic. Some registrars do set clientTransferProhibited during the 60-day window and refuse to let you toggle it off, which is why it can look like a regular lock in WHOIS.
How to Check When Your Domain Becomes Eligible
You need two dates: when the domain was created, and when it last changed registrar or registrant. The creation date is public. The last transfer date sometimes appears in RDAP, and the change-of-registrant date only lives in your registrar's records.
With WHOIS
whois example.com | grep -iE "creation date|updated date|registrar:"
Sample output for a .com domain:
Registrar: Example Registrar, LLC
Updated Date: 2026-09-14T10:22:31Z
Creation Date: 2026-09-01T08:15:02Z
Add 60 days to the creation date to get the earliest likely transfer date. The Updated Date is less useful because it changes for many reasons, such as name server edits or renewals, not just transfers.
With RDAP
RDAP returns structured JSON with an events array. Each event has an eventAction and an eventDate:
curl -sL https://rdap.org/domain/example.com \
| jq -r '.events[] | "\(.eventAction)\t\(.eventDate)"'
Typical output:
registration 1995-08-14T04:00:00Z
expiration 2027-08-13T04:00:00Z
last changed 2026-08-14T07:01:44Z
last update of RDAP database 2026-10-26T00:00:00Z
Some registries also include a transfer event, which tells you the date of the most recent inter-registrar transfer. If you want to understand these fields in more depth, see what RDAP is and how it is replacing WHOIS.
With a Script
This Python script, using only the standard library, works out the earliest date a domain is past the creation and transfer windows:
import json
import sys
import urllib.request
from datetime import datetime, timedelta, timezone
LOCK_DAYS = 60
def parse(ts: str) -> datetime:
return datetime.fromisoformat(ts.replace("Z", "+00:00"))
def check(domain: str) -> None:
req = urllib.request.Request(
f"https://rdap.org/domain/{domain}",
headers={"Accept": "application/rdap+json"},
)
with urllib.request.urlopen(req, timeout=15) as resp:
data = json.load(resp)
events = {e["eventAction"]: parse(e["eventDate"]) for e in data.get("events", [])}
now = datetime.now(timezone.utc)
candidates = []
if "registration" in events:
candidates.append(("registration", events["registration"]))
if "transfer" in events:
candidates.append(("last transfer", events["transfer"]))
if not candidates:
print(f"{domain}: no registration or transfer events returned")
return
label, latest = max(candidates, key=lambda c: c[1])
eligible = latest + timedelta(days=LOCK_DAYS)
if eligible <= now:
print(f"{domain}: past the 60-day window (latest event: {label} {latest:%Y-%m-%d})")
else:
days_left = (eligible - now).days + 1
print(f"{domain}: likely locked until {eligible:%Y-%m-%d} ({days_left} days, from {label})")
print(f" statuses: {', '.join(data.get('status', []))}")
if __name__ == "__main__":
for name in sys.argv[1:] or ["example.com"]:
check(name)
Run it with one or more domains:
python3 check_transfer_window.py example.com example.org
The script cannot see a Change of Registrant lock, because that date is not published in RDAP. If the script says the domain is clear but the registrar still refuses, ask the registrar whether a COR lock is in place and when it was applied.
What Can You Do While the Lock Is Active?
You are not stuck. Almost everything except a registrar move is still available.
Point the Domain Wherever You Want
If the reason you wanted to transfer was to use a different DNS provider or host, you do not need a registrar transfer at all. Change the name servers at your current registrar and you can run DNS anywhere. The registrar and the DNS host are separate roles, as explained in domain registrar vs. DNS host, and the steps are covered in how to update nameservers for a domain.
Prepare the Transfer in Advance
Use the waiting time to get everything ready so the move is smooth when the window ends:
- Confirm the registrant email address is current and you can receive mail there.
- Export or screenshot your DNS records in case the new registrar's DNS is needed.
- Make sure the domain is not close to expiry. Transferring during the last days before expiry or after expiry adds risk.
- Set a calendar reminder for the day after eligibility.
Ask the Registrar
Because two of the three windows are discretionary, some registrars will release a domain early on request, particularly when the account holder can verify identity and the domain was paid for with a verified payment method. Many will not. It never hurts to ask politely, but do not count on it.
Move Within the Same Registrar
If you are selling or handing over the domain, the buyer can often take it via an internal account-to-account push at the same registrar. This is not an inter-registrar transfer, so the 60-day rules do not apply, although changing the registrant data during the push may trigger a COR lock. The ownership side of this is covered in how to transfer domain ownership to another person or company.
Special Cases
Expired Domains
If you renew a domain after it expires, that is not a registration or a transfer, so it does not restart the 60-day clock. However, a domain restored from the redemption period sometimes has transfer restrictions applied by the registrar for a while, and a domain that has fully dropped and been re-registered by someone new is a brand-new registration with a fresh creation date. The stages are covered in what a domain grace period and redemption period are.
Country-Code TLDs
ccTLDs are not bound by ICANN's Transfer Policy. Each registry sets its own rules. Some have no post-registration lock at all, some have their own waiting periods, and some (such as .uk) use a different transfer mechanism entirely. Always check the registry's rules or ask your registrar for ccTLD domains.
Domain Purchases
If you buy an existing domain and it is pushed to your account at the seller's registrar, plan for the possibility that you cannot move it to your preferred registrar for 60 days. Factor that into timelines when buying through marketplaces or escrow.
Transfers Add a Year
For most gTLDs, a successful inter-registrar transfer adds one year to the registration. That means waiting out the lock does not cost you anything extra; you were going to pay for a year either way.
Common Error Messages
Registrars word this differently. These messages usually mean you have hit one of the 60-day windows:
- "Domain is not eligible for transfer. It was registered less than 60 days ago."
- "This domain was recently transferred and cannot be transferred again yet."
- "A change of registrant was recently made. The domain is locked for 60 days."
- "Object status prohibits operation" (an EPP-level error, which can also mean an ordinary registrar lock is still on)
If you see a different block, such as an invalid auth code or a pending update, see why you can't transfer your domain for the full list.
60-Day Transfer Lock FAQ
Usually not. It is a policy restriction enforced by the registrar, not a toggle like registrar lock. The only lock you can avoid yourself is the change of registrant lock, and only by opting out before you make the change.
No. The domain resolves normally, and you can change name servers and DNS records during the lock. Only moving the domain to a different registrar is blocked.
No. A renewal is not a registration, a transfer, or a change of registrant, so it does not trigger a new lock.
Generally no. Under the Transfer Policy, only material changes to the registrant name, organization, or email address count as a change of registrant. Address and phone changes do not.
For new registrations and recent transfers, the policy permits registrars to deny transfers rather than requiring it. Almost all registrars choose to enforce it as a fraud and theft safeguard, so in practice it behaves like a fixed rule.
Not automatically. ICANN's Transfer Policy covers generic TLDs. Country-code registries set their own transfer rules, which may have shorter, longer, or no waiting periods.
Yes. You can hand it to a buyer with an internal account push at the same registrar. The buyer just cannot move it to another registrar until the relevant period ends.
ICANN has been revising the Transfer Policy following a GNSO policy review, including changes to the post-registration, post-transfer, and change of registrant restrictions. Check your registrar's current transfer documentation, because implementation is being phased in.
Conclusion
The 60-day domain transfer lock is really three rules: a window after initial registration, a window after a previous registrar transfer, and a mandatory lock after a change of registrant unless you opt out. The first two are discretionary under ICANN policy but enforced by nearly every registrar, and none of them affect whether your domain resolves, only which registrar manages it.
The practical approach is simple. Check the creation and transfer dates with WHOIS or RDAP, use the opt-out when you change your own contact details, and if you only need different DNS, change name servers instead of registrars. Keep an eye on your registrar's transfer documentation as ICANN's revised Transfer Policy rolls out, since the durations and the change of registrant process are being updated.
Here are some useful references for going deeper on domain transfer restrictions:
- ICANN: Transfer Policy — the policy text, including permitted denial reasons and the Change of Registrant rules.
- ICANN GNSO: Transfer Policy Review PDP — the policy development process that has been revising transfer rules.
- ICANN: EPP Status Codes: What Do They Mean, and Why Should I Know? — explains the status codes you will see while a transfer is blocked or pending.
- RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP) — defines the RDAP events array used in the script above.


