BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Inter-Registrar Domain Transfer Walkthrough: How to Move a Domain to a New Registrar, Step by Step, in 2026
An inter-registrar transfer moves a domain from one ICANN-accredited registrar to another while the registered owner stays the same. The domain keeps its name, its registration history, and its inherited authority. Only the company that manages it changes.
This is the hands-on walkthrough. It takes a single domain from the moment a transfer is decided to the moment the gaining registrar confirms control, one step at a time, and it pairs each step with the specific mistake that stalls or kills a transfer. The procedure is governed by ICANN’s Transfer Policy, the rulebook every accredited registrar follows, and the policy was amended through 2024 in ways that changed the terminology and the timing.
It also covers the case other transfer guides skip: taking custody of a freshly acquired aged or expired domain. A name bought at auction or through a marketplace usually needs to move to the buyer’s own registrar account, and a recently registered or recently transferred domain carries a 60-day eligibility lock that decides when that move can happen. SEO Domains operates the curated marketplace where transfer-ready aged and expired domains are screened before they are listed, so the acquisition starts on a name whose transfer status is known, not guessed.
What an inter-registrar domain transfer is, and what it is not
An inter-registrar transfer moves a domain’s management from one ICANN-accredited registrar to another, with the registered owner unchanged. It is a different operation from a change of registrant, which alters ownership, from an account push, which moves a domain between accounts at the same registrar, and from a nameserver change, which only redirects where the domain points.
The word transfer gets used loosely, and the four operations it can mean carry different rules, different timelines, and different risks. Drawing the line first prevents the single biggest confusion, where an owner starts the wrong process and waits for a result that was never coming.
The four operations the word transfer can mean
An inter-registrar transfer is the subject of this guide: the domain leaves the losing registrar and arrives at the gaining registrar, governed by ICANN’s Transfer Policy. A change of registrant is a separate action that updates who owns the domain, and it can happen without the domain ever leaving its current registrar. An intra-registrar account push moves a domain between two accounts inside the same registrar, and because no registrar boundary is crossed it is faster and skips the authorization code entirely, frequently completing the same day. A nameserver or DNS change moves only where the domain resolves, and it transfers nothing about who manages or owns the name.
Inter-registrar transfer (this guide)
The domain moves from the losing registrar to the gaining registrar. Owner unchanged. Governed by ICANN’s Transfer Policy, requires the authorization code, subject to the 60-day lock and the 5-day window.
Change of registrant
Ownership changes hands. The registrant contact is updated. Can occur without a registrar transfer, and the gaining and losing parties are people or companies, not registrars.
Intra-registrar account push
The domain moves between two accounts at the same registrar. No registrar boundary crossed, no authorization code, frequently same-day. The fast path when buyer and seller share a registrar.
Nameserver or DNS change
Only where the domain points changes. Management and ownership stay put. Confusing this with a transfer leaves the domain at its old registrar with nothing genuinely moved.
Why an owner moves a domain at all
The reasons are practical. A registrar transfer consolidates a portfolio under one account, captures lower renewal pricing, reaches better DNS or security features, or takes custody of a newly bought domain that sits in a seller’s account. None of these alters the domain itself. The name, its age, and its link profile are unaffected, which is why a transfer is a routine administrative move instead of a risk to the asset. The pricing differences that commonly motivate a move are documented in the wider Registrar transfer policies compared guide.
Before you start: the four preconditions that decide eligibility
A transfer can only begin when four conditions are met: the domain is outside its 60-day eligibility lock, the registrar lock is removed, the administrative contact email is current and reachable, and a valid transfer authorization code is in hand. A request that fails any one of these is denied before it starts, and the leading cause of a stalled transfer is skipping the eligibility check.
Precondition one: the 60-day eligibility lock
ICANN’s Transfer Policy prohibits an inter-registrar transfer within 60 days of a domain’s initial registration, and within 60 days of a prior inter-registrar transfer. A domain registered last week cannot be transferred this week, and a domain that just moved registrars cannot move again for two months. The rule applies the same way to a freshly registered name and a freshly transferred one, which is the precondition acquired-domain buyers overlook first. The full mechanics sit in the dedicated ICANN’s 60-day transfer rule guide.
Precondition two: the registrar lock is off
Nearly every domain carries a registrar lock, shown in registration data as clientTransferProhibited, which blocks transfers as a security measure against hijacking. The lock is removed from the losing registrar’s control panel before a transfer can proceed. Removing it is a deliberate step, and it is reversed automatically once the transfer completes at the gaining registrar. The reasons to keep the lock on at all other times are covered in Transfer locking and when to unlock.
Preconditions three and four: a reachable contact and a valid code
The administrative contact email on record must be current, because the gaining registrar sends its confirmation request there. An outdated email is a silent failure point, since the confirmation never reaches anyone. The fourth precondition is the transfer authorization code, the secret string that proves the requester controls the domain. Obtaining it is the action the next section covers, because the code and its 2024 policy treatment are where the process changed the deepest.
The transfer authorization code and the 2024 policy shift
The transfer authorization code, also called the auth code, EPP code, or Transfer Authorization Code, is a unique secret tied to a single domain that the gaining registrar requires to prove the requester controls it. ICANN amended its Transfer Policy through 2024 to standardize how this code is issued and secured, tightening the rules registrars follow when they generate and deliver it.
What the code is and where it comes from
The authorization code is generated by the losing registrar and shown in its control panel, or sent to the registrant on request. It is specific to one domain, it is not the account password, and it functions as the proof of control that authorizes the move. The gaining registrar asks for it during the transfer request, validates it against the registry, and proceeds only if it matches. The code and the ways registrars deliver it are detailed in EPP code (auth code) explained.
The 2024 Transfer Policy amendments
ICANN’s Transfer Policy underwent a review that produced amendments adopted in 2024, standardizing the Transfer Authorization Code across registrars and setting requirements for how it is created, secured, and time-limited. The change matters in practice because it reduced the inconsistency that used to define this step, where each registrar handled auth codes differently. The policy work was tracked through ICANN’s GNSO process and reported across the registrar trade press, including Namecheap and eNom, as the inter-registrar transfer rules that govern every accredited registrar today.
The step-by-step transfer walkthrough
An inter-registrar transfer runs in eight steps: confirm eligibility, unlock the domain, disable privacy if the registrar requires it, retrieve the authorization code, initiate the request at the gaining registrar, pay the transfer fee, approve the confirmation, then wait out the losing-registrar window to completion. Each step has a done-right move and a specific mistake that stalls or denies the transfer.
The sequence below is the order every accredited registrar follows, because all of them implement the same ICANN Transfer Policy. The registrar control panels differ in wording and layout, but the underlying actions and the order they happen in do not. Read each step with its paired mistake, because the failure modes are where transfers genuinely go wrong.
-
Confirm the domain is eligible to transfer
Check that 60 days have passed since registration and since any prior inter-registrar transfer, and that the registration is not inside the final week before expiry. Confirm the domain is in active status with no registry hold or pending dispute.
The mistake: requesting a transfer inside the 60-day lock, or in the final days before expiry. The first is denied outright by policy, and the second risks the transfer failing as the domain lapses.
-
Unlock the domain at the losing registrar
In the current registrar’s control panel, remove the registrar lock, the clientTransferProhibited status. This is the deliberate action that signals you authorize a move, and it stays off only for the duration of the transfer.
The mistake: leaving the lock on. The gaining registrar cannot pull a locked domain, and the request sits unprocessed until the lock is cleared at the source.
-
Disable WHOIS or RDAP privacy if the registrar requires it
Certain registrars require contact privacy to be lifted so the administrative email is visible and reachable for the confirmation. Turn it off temporarily where required, and confirm the contact email is one you can access.
The mistake: a privacy service masking an email you no longer control. The confirmation request goes to an unreachable address and the transfer silently never starts.
-
Retrieve the transfer authorization code
Request the auth code from the losing registrar, copy it exactly, and treat it as a secret. Note any validity window the registrar attaches to it, since a code can expire if left unused.
The mistake: a mistyped or expired code, or one shared over an insecure channel. An invalid code is rejected at validation, and a leaked code is a hijacking risk.
-
Initiate the transfer at the gaining registrar
Start the request at the new registrar, enter the domain and the authorization code, and let it validate the code against the registry. This is where the gaining registrar formally requests the domain from the losing one.
The mistake: starting the request at the wrong registrar, or before the code validates. A transfer is always initiated at the gaining registrar, never the losing one.
-
Pay the transfer fee, which usually renews the domain a year
Pay the gaining registrar’s transfer charge. For the generic top-level domains people transfer day to day, this fee adds one year to the registration, so the year is not lost, it carries over and extends. Complete payment to release the request to the registry.
The mistake: assuming the fee buys nothing. For the common gTLDs the transfer includes a one-year renewal, so timing a transfer near renewal avoids paying twice.
-
Approve the confirmation request
The gaining registrar sends a confirmation to the administrative contact email. Approve it promptly to authorize the move. Approving it accelerates the process past the default waiting period.
The mistake: ignoring the confirmation email, or letting it land in spam. An unconfirmed request still completes eventually, but only after the full waiting window, slowing the move by days.
-
Wait out the losing-registrar window to completion
The losing registrar has up to five calendar days to acknowledge or deny the request. If it neither approves nor denies, the registry auto-completes the transfer after the window. The domain then appears in the gaining registrar’s account.
The mistake: cancelling early in a panic. The wait is normal, by design. Cancelling mid-window can reset the process and, at certain registrars, trigger a new lock period.
The transfer timeline: payment to completion
A typical inter-registrar transfer completes in five to seven days. The losing registrar has up to five calendar days to acknowledge or deny the request, the registry auto-completes it if the window passes without a denial, and explicit approval at both ends can finish it in a day or two. A fresh 60-day lock then applies to the domain at its new registrar.
The standard sequence of events
The clock starts when the gaining registrar submits a valid request with a matching authorization code. The administrative-contact confirmation can be approved within minutes. The losing registrar’s five-day window is the longest fixed stage, and it can be shortened by an explicit approval instead of a passive wait. Once the registry records the transfer, the domain is live in the new account, with its DNS and renewal date intact.
The gaining registrar submits the request with the validated authorization code, and sends the confirmation to the administrative contact email. Source: ICANN Transfer Policy.
The registrant approves the confirmation request. Prompt approval here is what separates a two-day transfer from a five-day one.
The losing registrar’s window. It can approve the transfer to release it early, deny it for a policy-permitted reason, or take no action. Source: ICANN Transfer Policy, the five-day acknowledgement period.
If the losing registrar took no action, the registry auto-completes the transfer. The domain now sits in the gaining registrar’s account, owner unchanged.
A fresh 60-day inter-registrar transfer lock applies at the new registrar, so the domain cannot be moved again immediately. Source: ICANN Transfer Policy, the 60-day post-transfer lock.
Actual timing varies by registrar and registry, and the registrar-by-registrar differences are documented in Transfer time expectations by registrar.
Transferring a freshly acquired aged or expired domain
A domain bought at auction or through a marketplace usually needs to move to the buyer’s own registrar account, and the path depends on where the seller holds it. If the seller is at the same registrar, an account push is the fast option. If not, a full inter-registrar transfer applies, and the 60-day eligibility lock decides whether it can happen now or has to wait.
The two paths for an acquired domain
When the purchase closes, the domain sits in the seller’s account at the seller’s registrar. If the buyer happens to use that same registrar, an intra-registrar account push moves the name account to account, frequently the same day, with no authorization code and no transfer fee. If the buyer uses a different registrar, the full eight-step inter-registrar transfer applies. The decision between the two is covered in Push vs transfer: when each makes sense, and the push procedure in Intra-registrar account push walkthrough.
Why the 60-day lock matters most on an acquired name
An aged domain that recently changed registrars, or was recently re-registered after expiry, can be inside its 60-day inter-registrar transfer lock at the moment of purchase. The name is yours, the ownership can change, but the inter-registrar move has to wait out the window. Reading the domain’s registration status before purchase, through RDAP, which replaced WHOIS as the standard ICANN lookup on 28 January 2025, tells you whether an immediate transfer is even possible. This is the diligence that separates a clean acquisition from a stalled one.
Sourcing a domain whose transfer status is already known removes the guesswork at the costliest moment, the moment of purchase. Browse transfer-ready aged and expired domains, with registration and authority status screened before listing, on the SEO Domains marketplace, where the inherited authority and the registration record are both read before the name is priced. The asset that survives a transfer untouched is the domain’s earned authority. The transfer is administrative; the value is in the name.
When a transfer is denied or fails, and how to fix it
ICANN’s Transfer Policy lists the specific reasons a losing registrar is permitted to deny a transfer, and every other failure traces back to an unmet precondition. The fix is almost always at the source: clear the lock, correct the contact email, supply a valid code, or wait out the eligibility window. A denial for a policy-permitted reason is not a hijacking, and it is rarely permanent.
The permitted denial reasons and the unmet preconditions
A losing registrar is allowed to deny a transfer for reasons the Transfer Policy permits, such as evidence of fraud, a pending dispute, a court order, the domain being within 60 days of registration or a prior transfer, or non-payment for a previous registration term. Outside those, a failed transfer is a precondition problem, an unmet step from the walkthrough that the request ran into. The denial reasons and the recovery steps are documented in full in Transfer failures: common causes and fixes.
| What went wrong | Why it failed | The fix |
|---|---|---|
| Request denied immediately | Domain inside the 60-day registration or post-transfer lock | Wait out the window, then resubmit. Confirm eligibility via the registration record first |
| Transfer stuck, never started | Registrar lock still on at the losing registrar | Remove clientTransferProhibited in the losing registrar’s panel, then reinitiate |
| No confirmation email arrives | Administrative contact email outdated or masked by privacy | Update the contact email and lift privacy temporarily before requesting |
| Authorization code rejected | Code mistyped, expired, or for the wrong domain | Regenerate the code at the losing registrar and enter it exactly |
| Denied for non-payment or dispute | An open balance, a UDRP dispute, or a court order on the name | Resolve the underlying issue first; these are valid policy denials, not errors |
| Transfer fails near expiry | Domain lapsed mid-transfer or entered a redemption phase | Renew before transferring; never start a transfer in the final days of a term |
When a denial is a genuine dispute
A small share of transfer problems are real disputes, where a transfer was attempted without authority or is contested between parties. ICANN’s Transfer Dispute Resolution Policy exists for exactly these cases, and it is a separate track from a routine denial. The escalation path is set out in Handling a transfer dispute.
The post-transfer checklist
Once the domain lands at the gaining registrar, four checks confirm the move is clean: verify the registration record now shows the new registrar, confirm the DNS and nameservers carried over so nothing went dark, note the new renewal date, and re-enable the registrar lock. Skipping the DNS check is the mistake that turns a successful transfer into an unexpected outage.
The four confirmations after a transfer completes
The first check reads the registration record through RDAP to confirm the gaining registrar is now listed and the owner is unchanged. The second confirms the nameservers and DNS records survived the move, because a transfer carries DNS over only if the records were in place, and a gap here is what causes a site or email to drop. The third notes the renewal date, which for the common gTLDs extended by one year through the transfer fee. The fourth re-enables the registrar lock that step two of the walkthrough removed, restoring the security the transfer required to be off.
The full post-move routine, including the renewal and authority checks specific to a newly acquired name, is in Post-transfer checklist for aged domains.
Inter-registrar transfer frequently asked questions
The five questions that recur when someone moves a domain to a new registrar, answered against ICANN’s Transfer Policy and the operations this guide separates.
Q1Can I move my domain from one registrar to another?
Yes, for almost every domain, through an inter-registrar transfer governed by ICANN’s Transfer Policy. The domain must be outside its 60-day eligibility lock, unlocked at the current registrar, and you need the transfer authorization code. The owner stays the same, and the domain keeps its name, age, and link profile. The only domains you cannot move are those inside the lock window, under a dispute, or in a redemption or expired state.
Q2Will I lose my email or website if I transfer my domain?
Not if the DNS records are already saved on the domain before the transfer. An inter-registrar transfer moves only the managing registrar, and the nameservers and DNS records carry over intact when they are in place. The risk comes from a domain whose email or hosting was configured at the old registrar without those records being preserved. Confirming the nameservers before and after the move is the check that prevents any downtime.
Q3How much does it cost to transfer a domain?
The gaining registrar charges a transfer fee, and for the common generic top-level domains that fee includes a one-year renewal, so the registration term extends instead of being lost. The exact figure tracks the registrar’s standard one-year renewal price for that extension. Country-code and registry-specific names price transfers differently. Timing a transfer close to renewal means the fee does double duty as the renewal, in place of paying for both separately.
Q4How long does an inter-registrar transfer take?
A typical transfer completes in five to seven days. The losing registrar has up to five calendar days to acknowledge or deny the request under ICANN’s Transfer Policy, and the registry auto-completes the move if the window passes without a denial. Approving the confirmation at both ends can finish it in a day or two. A fresh 60-day inter-registrar transfer lock then applies at the new registrar.
Q5Is transferring a domain the same as changing its owner?
No. An inter-registrar transfer changes only the managing registrar, with the registered owner unchanged. Changing the owner is a separate operation, a change of registrant, which updates the registrant contact and can happen without the domain leaving its current registrar. Buying a domain frequently involves both, the ownership change to put it in your name and the registrar transfer to move it to your account, but they are distinct steps with different rules.
Start with a transfer-ready domain: source it screened
An inter-registrar transfer is administrative. The value it moves, the domain’s age, history, and inherited authority, is unaffected by the process, which is why a transfer is a routine step instead of a risk to the asset. The decision that does affect the outcome is made earlier, at acquisition: sourcing a domain whose registration status and authority are read before purchase. SEO Domains operates that curated marketplace.
Why the acquisition decides the transfer
The transfer itself follows fixed rules and a fixed timeline, the same for every accredited registrar. What varies is the domain that enters the process. A name with a clean registration record, outside its 60-day lock, with a reachable contact and a known history, transfers without friction. A name bought blind, inside a lock window or with a clouded record, stalls the move at the costliest moment. The diligence belongs at purchase, not after.
The domain is the asset, not the registrar
A registrar is a service provider, interchangeable by design, which is the entire reason ICANN’s Transfer Policy exists. The domain is the durable asset. Its inherited authority is what an aged or expired domain carries from one registrar to the next, untouched by the move. That authority is what gets read and screened before a name is listed on the SEO Domains marketplace, so the acquisition starts from a domain that is known, not assumed.
