BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
ICANN’s 60-Day Transfer Rule: The Three Locks That Block a Domain Move, How to Plan Around Them, and the 2025 Reform
ICANN’s 60-day transfer rule is the policy that stops a generic top-level domain such as a .com, .net, or .org from being transferred to a different registrar for 60 days after one of three events: a fresh registration, a previous inter-registrar transfer, or a change to the registrant contact. It is the reason a domain you just acquired refuses to move when you try to bring it where you want it.
The rule is not one lock. It is three separate clocks, written into ICANN’s Transfer Policy, and they do not all behave the same way. One of them, the Change of Registrant lock, carries an opt-out that the others do not. Knowing which clock is running tells you whether you wait, whether you opt out, or whether you sequence the move differently.
This guide maps all three triggers, the avoidance sequence that keeps an acquisition moving, and the 2025 ICANN reform that is set to replace the registrant lock. For anyone buying aged and expired domains, the lock is a scheduling fact to plan around, and a clean handover from a curated source is where that planning starts. SEO Domains operates that marketplace.
What is ICANN’s 60-day transfer rule?
ICANN’s 60-day transfer rule is the part of ICANN’s Transfer Policy that lets a registrar deny an inter-registrar transfer when a gTLD domain is within 60 days of its initial registration, within 60 days of a previous transfer, or subject to a 60-Day Change of Registrant lock. It is an anti-hijacking control, and it applies to the registrar move, not to ownership.
The rule lives in ICANN’s published FAQs for Registrants and in the Transfer Policy itself. ICANN states that a registrar can deny a transfer request when the domain name is within 60 days of initial registration, that a transfer can be blocked when the name is within 60 days of a previous transfer, and that a name can be subject to a 60-day Change of Registrant lock. Three triggers, one shared 60-day length.
The plain-English read of the rule
A registrar transfer hands a domain from one registrar account to a different registrar entirely. The 60-day rule says that for a window after certain events, that hand-off is paused. The domain still works, the registration is still yours, and you can still build on it. What you cannot do during the window is move the name to another registrar.
What the rule does not touch
The lock controls the inter-registrar transfer only. It does not stop you pointing the domain’s DNS wherever you like, building or migrating a site on it, renewing it, parking it, or running a 301 redirect from it. An aged domain inside its 60-day window is fully usable. The single restricted action is the registrar-to-registrar move, which is the step that connects directly to the auth code described in EPP code (auth code) explained.
The three events that trigger a 60-day lock
Three events start a 60-day inter-registrar transfer lock: a new registration, an inter-registrar transfer that just completed, and a Change of Registrant. Each is a separate clock with its own start point, and a single domain can have run through more than one of them. Reading which event fired tells you the date the window clears.
The confusion around the rule comes from treating it as one lock. It is three. A domain registered yesterday and a domain transferred in last week are both locked, but for different reasons and with different opt-out options. The table below separates them.
| Trigger event | Lock length | Opt-out available? | What starts the clock |
|---|---|---|---|
| Initial registration of the domain | 60 days | No, mandatory | The date the name was first registered |
| A previous inter-registrar transfer | 60 days | No, mandatory | The date the prior transfer completed |
| Change of Registrant (registrant contact change) | 60 days | Yes, if the registrar offers it | The date the registrant data change was applied |
Trigger one: a fresh registration
When a name is newly registered, it cannot transfer to another registrar for 60 days. This is the trigger that catches buyers of newly hand-registered names and freshly dropped domains caught at the moment of deletion. The clock runs from the registration date, and no registrar can waive it.
Trigger two: a previous transfer
Once a domain completes an inter-registrar transfer, a new 60-day window opens before it can transfer again. This is the trigger that blindsides aged-domain buyers: the name arrives at your registrar through a transfer, and that same transfer arms a 60-day lock against your next move. The clock runs from the transfer completion date.
Trigger three: a Change of Registrant
Changing the registrant contact, the legal holder of record, starts a 60-day lock of its own. This is the trigger you have the greatest control over, because it is the one event you choose to perform and, in a large share of cases, the one you can opt out of. It gets its own section next.
The 60-day Change of Registrant lock, and its opt-out
A Change of Registrant is an update to the registrant contact, the legal owner of record, and it triggers a 60-day transfer lock under ICANN’s Transfer Policy. Unlike the registration and transfer locks, ICANN lets a registrar offer an opt-out of this one, taken before the change is made. Whether the opt-out exists depends on the registrar.
ICANN’s wording is precise on the discretion. The registrant FAQ explains that a registrar can provide an option to opt out of this 60-day lock period, and adds that the registrar does not have to offer that option. So the opt-out is a registrar feature, not a guarantee. DNSimple, for one, states plainly that “we do not support the ability to opt-out of the 60-day lock,” while Name.com surfaces the opt-out as a pop-up preference when you edit a contact.
What counts as a Change of Registrant
The lock keys off a material change to the registrant contact, the holder of record, not to any field on the account. ICANN’s About Change of Registrant guidance ties the trigger to changes in the registrant’s name, organization, or email address. Editing the registrant’s first name, last name, organization, or email is the action that arms this lock. A correction with no material change, by contrast, is treated differently by certain registrars.
Arms the lock (material registrant change)
Editing the registrant contact’s name, organization, or email address. This is a change to the legal holder of record, and it starts the 60-day Change of Registrant lock unless an opt-out is taken first.
Does not arm the lock
Toggling WHOIS Privacy, editing account-level or technical contacts, or updating fields that are not the registrant of record. Name.com confirms WHOIS Privacy modifications and account-level contact updates are exempt.
The opt-out has to come first
The opt-out is taken before the registrant change, not after. Once the change is applied without an opt-out, the lock is set for its 60 days. DNSimple states the same sequence the other way around: “Have the prior registrant opt-out the 60-day lock (if this option is offered by the registrar) before making any change to registrant information.” The order is the whole game.
What does not trigger the lock, and which domains it covers
The 60-day rule covers generic top-level domains under ICANN’s Transfer Policy. It does not cover country-code TLDs, which run their own registry rules. Within a gTLD, WHOIS Privacy toggles, account-level contact edits, and DNS or nameserver changes do not start the lock. Knowing the exemptions stops a wasted wait on a lock that was never armed.
Scope: gTLDs in, ccTLDs out
ICANN’s Transfer Policy governs gTLDs such as .com, .net, .org, and the newer generic extensions. Country-code TLDs such as .co.uk, .de, or .ca sit outside that policy and follow their own national registry rules, which set different windows or none at all. Name.com states the split directly: generic TLDs are affected, and country-code domains like .co.uk are not. Read the registry’s own rules for a ccTLD instead of assuming the 60-day window applies.
Edits that are exempt
Inside a gTLD, a set of edits people fear will lock the domain do not. The exempt actions sit alongside the registrant change so the difference is plain:
- Turning WHOIS Privacy on or off, which masks contact data without changing the registrant of record.
- Editing account-level or technical and administrative contacts that are not the registrant.
- Changing nameservers, DNS records, or hosting, which never touch the transfer lock at all.
- Renewing the domain, which extends registration without arming any of the three triggers.
The reassurance that closes this out comes from DNSimple: “Changing the registrant contact information after a transfer does not trigger a new lock period, so you can safely update contact details after the transfer is complete.” Sequence the registrant edit after the move, and the exemption works in your favor.
Why the rule exists, and the registrar’s duties around it
The 60-day rule exists as an anti-hijacking control. A thief who seizes a domain wants to move it to a registrar beyond the owner’s reach before the theft is noticed, and the lock buys time to catch that. ICANN also binds registrars to duties around the rule: they must state a reason for any transfer denial, and they cannot invent locks the policy does not authorize.
The anti-fraud logic
DomainIncite frames the original intent as “an anti-fraud measure, stopping domain thieves bouncing their stolen names.” The transfer and registrant locks both target the same attack: an intruder who gains access tries to register-and-flee or change-the-owner-and-flee. The 60-day pause turns a one-click escape into a window where the legitimate owner, the registrar, and ICANN’s dispute processes can intervene.
The registrar’s confirmation and denial duties
The rule does not give a registrar free rein to block transfers. ICANN’s registrant FAQ states that the registrant must confirm intent through the Form of Authorization, with the confirmation window set “not to exceed 60 days,” and that “your registrar is required to specify a reason when denying your transfer request.” If a registrar refuses a move, it owes you the specific reason, and “subject to a 60-Day Change of Registrant lock” is one of the named, legitimate reasons on ICANN’s list.
A trigger event fires: the name is registered, a transfer completes, or the registrant of record is changed. The 60-day clock starts on that date.
The domain is fully usable for DNS, hosting, content, and renewal. An inter-registrar transfer request can be denied, and the registrar must state the reason. Source: ICANN FAQs for Registrants.
The window clears. The domain becomes eligible for an inter-registrar transfer again, assuming no other lock or status code is in effect. The auth code and an unlocked status are the next requirements.
How to plan a domain acquisition around the 60-day lock
The lock is a scheduling fact, not a roadblock. The right sequence keeps an acquisition moving: confirm which trigger is running before you buy, take the move first and the registrant edit second, and use the opt-out only where the registrar offers it. The walkthrough below pairs each step with the mistake that strands a name under an avoidable lock.
This sequence assumes the common aged-domain case: you acquire a name and want it at your own registrar, under your own contact, ready to build. Run the steps in order, and the lock costs you nothing it did not have to.
-
Confirm which trigger is running before money changes hands
Read the domain’s registration date and last transfer date, and ask the seller whether the registrant was changed recently. Each of those is a potential 60-day clock. Sourcing from a curated marketplace shortens this step, because a screened aged or expired domain arrives with its history surfaced instead of guessed. Browse vetted inventory on the SEO Domains marketplace, then read the acquisition diligence in the expired domain fundamentals hub.
The mistake: buying blind, then discovering a fresh registration or a recent transfer has armed a 60-day lock you now have to wait out before the name can move where you planned.
-
Take the registrar move first, the registrant edit second
If the name is eligible to transfer, complete the inter-registrar transfer to your registrar before you touch the registrant contact. DNSimple confirms a registrant edit after a transfer “does not trigger a new lock period,” so this order lets you settle ownership without arming the Change of Registrant lock on top of the transfer lock.
The mistake: changing the registrant first, arming the Change of Registrant lock, and then being unable to transfer the name for 60 days because the edit blocked the move you wanted to make.
-
Use the opt-out only where the registrar offers it
If you must change the registrant before transferring, check whether the current registrar offers an opt-out of the Change of Registrant lock, and take it before the edit. Name.com surfaces it as a preference; others do not offer it at all. The opt-out has no effect once the change is already applied.
The mistake: assuming every registrar has an opt-out. ICANN states the registrar “does not have to offer this option,” so a registrant change at a registrar without one locks the name for the full 60 days.
-
Prepare the transfer instruments while the clock runs
A cleared lock is one of three requirements. Unlock the domain at the registrar, obtain the auth code, and confirm no status code blocks the move. Working through the lock window means the name is ready to go the day it clears. The full mechanics are in the inter-registrar domain transfer walkthrough and transfer locking and when to unlock.
The mistake: treating the 60-day lock as the only blocker, then hitting a registrar lock status or a missing auth code on day 60 and losing more time. The locks stack; clear them together.
-
Schedule the move for the day the window clears
Calculate day 60 from the trigger date, not from the day you bought the name, and initiate the transfer then. If a push within the same registrar is an option, it sidesteps an inter-registrar transfer entirely, which is the choice weighed in push vs transfer: when each makes sense.
The mistake: counting 60 days from the purchase date when the lock started earlier or later. The clock runs from the trigger event, so a wrong start date means a denied transfer and a fresh wait.
The 2025 reform: ICANN is replacing the registrant lock
ICANN’s 60-day rule is changing. On 13 March 2025 the GNSO Council accepted the final report of its Transfer Policy working group, a 163-page document carrying 47 recommendations. The plan removes the Change of Registrant 60-day lock, replaces it with a mandatory 720-hour lock on newly created or transferred domains, and spins registrant-change rules into a separate policy. The window to live status is long.
What the reform changes
DomainIncite reports the working group’s recommendations in detail. The Change of Registrant 60-day lock is set to be removed entirely. In its place, the policy introduces “mandatory 720-hour (30-day) locks on domains that have just been created or just transferred in,” and registrars currently imposing longer locks are told to reduce to 720 hours. The registrant-change procedures are being carved out into a new Change of Registrant Data Policy, separate from the Transfer Policy itself.
The timeline, and why today’s rule still governs
Acceptance by the GNSO Council is a milestone, not the finish line. DomainIncite notes the changes still need implementation time before they bind registries and registrars, putting the estimate at “at least 18 months before the changes go live.” Until that implementation completes, the current three-trigger 60-day rule is what your registrar enforces. Treat the reform as the direction of travel and the 60-day window as the rule you plan against today.
| Element | Current rule (today) | 2025 reform (proposed) |
|---|---|---|
| New-registration lock | 60 days, mandatory | 720 hours (30 days), mandatory |
| Post-transfer lock | 60 days, mandatory | 720 hours (30 days), mandatory |
| Change of Registrant lock | 60 days, opt-out at registrar discretion | Removed entirely |
| Where registrant rules live | Inside the Transfer Policy | A separate Change of Registrant Data Policy |
| Status | In force and enforced now | Accepted 13 March 2025, around 18 months to go live |
Common 60-day-lock mistakes and the fix
The errors that strand a domain under a 60-day lock are a short, repeatable list, and each has a clean fix. The fixes converge on one habit: read which trigger is running, then order the registrar move ahead of the registrant edit. Use this as the scannable reference when an acquisition stalls.
The table consolidates the traps from the sections above into one place. The left column is the mistake, the center is why it locks the name, and the right is the fix that keeps the move on schedule.
| The mistake | Why it locks the name | The fix |
|---|---|---|
| Changing the registrant before transferring | The Change of Registrant lock arms a 60-day window that then blocks the move | Transfer to your registrar first, edit the registrant after |
| Assuming every registrar offers an opt-out | ICANN says the registrar is not required to offer one, so the lock sets in full | Check for the opt-out and take it before the edit, or skip the edit until after the move |
| Counting 60 days from the purchase date | The clock runs from the trigger event, not the day you bought the name | Calculate day 60 from the registration, transfer, or registrant-change date |
| Treating the 60-day lock as the only blocker | A registrar lock status or missing auth code stalls the move independently | Unlock the domain and obtain the auth code while the window runs |
| Buying a name without checking its history | A fresh registration or recent transfer is an invisible armed lock at purchase | Source from a screened catalogue and confirm registration and transfer dates first |
| Expecting the ccTLD to follow the rule | Country-code domains run their own registry rules, not ICANN’s Transfer Policy | Read the ccTLD registry’s own transfer terms for any non-gTLD name |
| Fearing a WHOIS Privacy toggle locks the name | It does not, but the wait it causes wastes a usable window | Toggle privacy and account contacts freely, they are exempt from the lock |
| Editing the registrant to fix a typo, then transferring | A material registrant change arms the lock even when the intent was a correction | Confirm whether the edit is material, and sequence it after the transfer where possible |
ICANN 60-day transfer rule FAQ
The questions buyers and registrants raise when a domain refuses to transfer, answered against ICANN’s Transfer Policy and the registrar guidance cited throughout this guide.
Q1Can I get around the 60-day transfer lock?
For the registration and transfer triggers, no. ICANN makes those locks mandatory, and a registrar cannot lift them. For the Change of Registrant trigger, the only legitimate route is the opt-out, taken before the registrant edit, and only where the registrar offers it. The reliable approach is to sequence the work: transfer the name first, then change the registrant, since a registrant edit after a transfer starts no new lock.
Q2Why does it take 60 days to transfer a domain name?
The 60-day window is an anti-hijacking control, not a processing delay. DomainIncite describes the original intent as stopping domain thieves from bouncing stolen names to a registrar beyond the owner’s reach. The pause gives the legitimate owner, the registrar, and ICANN’s dispute processes time to intervene before a stolen name disappears.
Q3Does changing my contact details always lock the domain?
No. Only a material change to the registrant contact, the legal holder of record, arms the Change of Registrant lock. Name.com confirms that WHOIS Privacy modifications and account-level contact updates are exempt, and changing nameservers, DNS, or hosting never touches the transfer lock at all. The trigger is the registrant of record, not any field on the account.
Q4Does the 60-day rule apply to country-code domains like .co.uk?
No. ICANN’s Transfer Policy governs gTLDs such as .com, .net, and .org. Country-code TLDs run their own national registry rules, which set different windows or none. Name.com states the split directly. For any ccTLD, read that registry’s own transfer terms instead of assuming the 60-day window applies.
Q5Is the 60-day rule going away?
It is being reformed, not removed. On 13 March 2025 the GNSO Council accepted the Transfer Policy working group’s final report, which removes the Change of Registrant lock and shortens the registration and transfer locks to 720 hours, or 30 days. DomainIncite estimates around 18 months before the changes go live, so the current 60-day three-trigger rule is what registrars enforce today.
Acquiring aged domains without a lock surprise
The 60-day lock costs nothing when the domain’s history is known and the move is sequenced correctly. It costs a wasted month when a name is bought blind and the trigger only surfaces after purchase. Sourcing from a curated catalogue, where registration and transfer history is surfaced before the sale, removes the surprise. SEO Domains operates that marketplace.
Why history visibility decides the outcome
Every avoidable lock in this guide traces to the same root: a trigger the buyer did not see coming. A fresh registration, a recent transfer, or a pending registrant change is invisible to anyone who buys on a metric alone. A screened aged or expired domain arrives with that history read, so the 60-day window is a date on a calendar instead of a discovery after the fact.
The acquisition checklist around the lock
A clean acquisition runs a short check before and after the move:
- Confirm the registration date and last transfer date, so you know which 60-day clocks are running.
- Ask whether the registrant was changed recently, since that arms a third, separate lock.
- Plan the registrar move for the day the window clears, counting from the trigger event.
- Edit the registrant after the transfer completes, where the exemption keeps a new lock from arming.
A screened domain answers the first two checks at the point of purchase. That is the difference between a 60-day rule you planned around and a 60-day rule that caught you, and it is why sourcing aged and expired names from a vetted catalogue is the practical starting point.
