BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Registrar Transfer Policies Compared: The ICANN Floor, Where Registrars Differ, and the Domain Quality It All Protects in 2026
A registrar transfer policy is the set of rules a registrar applies when a domain moves into it or out of it: the locks that must clear, the authorization code that must be issued, the fees that apply, and the timeline the move runs on. Compared side by side, registrars look strikingly different. Much of that difference is an illusion.
The honest read is that a transfer policy has two halves. One half is fixed by ICANN and is identical at every accredited registrar, from the sixty-day locks to the five-day auth-code rule. The other half is registrar discretion, and that is where the real comparison lives: how fast an auth code is released, whether the registrar locks a domain on registration, whether it lets an owner opt out of a contact-change lock, and how its support handles a stuck transfer.
This guide separates the two halves so a buyer can read any registrar’s policy and know instantly what is negotiable and what is law. It matters above all when an aged or expired domain changes hands, because the move is the moment a clean acquisition is exposed to friction. SEO Domains operates the curated marketplace where that raw material is screened before it is priced, so the asset arriving through the transfer is sound before the policy comparison ever begins.
What a registrar transfer policy actually covers
A registrar transfer policy governs four things: the locks that must be cleared before a domain can move, the authorization code that proves the move is authorized, the fees that apply on the way in or out, and the timeline the transfer follows. Those four span three distinct layers, and only one of the three is where registrars genuinely differ.
Domain comparison guides line registrars up in a single table and present every cell as a point of difference. That framing is the reason buyers misread transfer policies. A sixty-day lock is not a registrar feature; it is an ICANN rule the registrar has no power to waive. An auth-code release speed, by contrast, is a real registrar choice. Reading the two as the same kind of thing is the core mistake this guide corrects.
The four moving parts of any transfer
Every inter-registrar transfer turns on the same four mechanics, whatever the registrar’s brand. The locks decide whether the domain is eligible to move at all. The authorization code, sometimes written auth code, EPP code, authinfo code, or transfer code, is the single-use secret that authorizes the move. The fee covers the mandatory renewal that ICANN attaches to a gTLD transfer. The timeline runs from the auth-code entry to the moment the gaining registrar takes control.
The three layers a policy splits into
Sort those mechanics by who controls them and a clean three-layer model appears. The ICANN layer is the fixed floor, identical at every accredited registrar. The discretion layer is the band of choices ICANN leaves open, where a real comparison lives. The cost layer is the pricing each registrar sets on top. The rest of this guide walks the three in order.
Layer 1: the ICANN floor (identical everywhere)
The sixty-day locks, the five-calendar-day auth-code rule, the Form of Authorization, and the denial grounds. No registrar can waive these, so comparing them across registrars finds no difference.
Layer 2: registrar discretion (the real comparison)
Auth-code release speed, whether the registrar locks on registration, whether it offers a contact-change-lock opt-out, support quality, transfer-in promotions, and bulk-transfer tooling. This is the only layer worth comparing.
Layer 3: cost (set per registrar)
The transfer fee with its mandatory one-year renewal, and the redemption fee if a domain lapses. Real numbers, but narrow bands. The cheapest transfer rarely decides an acquisition worth keeping.
The reading rule
When two registrar policies look different on a sixty-day lock, they are not. When they differ on auth-code speed or a lock-on-register default, they genuinely do. Layer the policy before you compare it.
The ICANN layer: the rules every registrar applies the same way
ICANN’s Transfer Policy, effective 1 June 2016, sets the rules every accredited registrar must follow identically. Three sixty-day locks restrict when a domain can move, the authorization code must be released within five calendar days, the gaining registrar must confirm intent with a Form of Authorization, and the losing registrar can deny a transfer only on defined grounds. None of this varies by registrar.
The three sixty-day locks
ICANN imposes three separate sixty-day inter-registrar transfer locks, and confusing them is the single likeliest reason a planned transfer stalls. NameSilo frames them as a global rule, not a registrar policy, and that framing is correct: every accredited registrar enforces all three.
- After registration. A newly registered domain cannot transfer to another registrar for sixty days.
- After a prior transfer. A domain that has just transferred in cannot transfer out again for sixty days.
- After a change of registrant. Editing the registrant contact triggers a sixty-day lock, effective since 1 December 2016. ICANN permits registrars to offer an opt-out before the change, which is itself a discretion-layer difference covered below.
The authorization code and the five-calendar-day rule
The authorization code is the single-use secret that proves a transfer is authorized by the real owner. ICANN’s Transfer Policy requires the registrar to provide that code within five calendar days of the registrant’s request. A registrar can choose to release it instantly, and the named ones do, but five calendar days is the legal ceiling, not a registrar feature. The same five-day window applies to removing an objection lock once the authorized contact asks.
The Form of Authorization and denial grounds
The gaining registrar, the one a domain moves to, must confirm the registrant’s intent using the standardized Form of Authorization. Since 25 May 2018, when the gaining registrar cannot access the registration data for a name being transferred, it is not required to obtain that form from the transfer contact, a change driven by the move to redacted registration data. The losing registrar, the one a domain moves from, can deny a transfer only on defined grounds such as evidence of fraud, a pending dispute, or an unexpired lock. A losing registrar cannot deny a transfer merely to keep the business.
ICANN’s consolidated Transfer Policy takes effect, standardizing the auth-code process, the Form of Authorization, and the denial grounds across all accredited registrars. Source: ICANN Transfer Policy.
The sixty-day inter-registrar lock following a change of registrant becomes effective. It is triggered by the registrant contact field and applies to transfers only, not DNS or renewals. Source: ICANN, DNSimple policy summary.
A Form-of-Authorization exception takes effect: when the gaining registrar cannot access registration data, it need not obtain the form, an accommodation for redacted records. Source: ICANN Transfer Policy.
RDAP, the Registration Data Access Protocol, replaces WHOIS as the standard ICANN lookup, changing how ownership data is read during and after a transfer. Source: ICANN.
The discretion layer: where transfer policies genuinely differ
Inside the band ICANN leaves open, registrars make real choices, and this is where a comparison earns its keep. Auth-code release speed, whether a domain is locked on registration, whether a contact-change-lock opt-out is offered, support responsiveness on a stuck transfer, transfer-in promotions, and bulk-transfer tooling all vary registrar to registrar. These are the cells worth reading.
Auth-code release speed
The five-calendar-day ceiling is law; how fast a registrar moves within it is choice. The registrar-features comparison published by DomainDetails records immediate auth-code access at six named registrars, Cloudflare, Porkbun, Namecheap, Dynadot, NameSilo, and Squarespace, while flagging GoDaddy auth-code access as potentially requiring a wait. For a single domain the difference is minor. For a portfolio moving on a deadline, instant release versus a multi-day wait is the difference between a clean migration and a stalled one.
Lock-on-registration and the contact-change opt-out
Two locks sit in the discretion band even though they look like law. A number of registrars apply a registrar transfer lock automatically on registration, which the owner must manually clear before any move; others leave the domain unlocked by default. Separately, ICANN permits a registrar to offer an opt-out of the sixty-day change-of-registrant lock before the change is made, and registrars split on this. DNSimple, for example, documents that it does not support opting out of that lock, while others do. Neither is a rule violation; both are policy choices a buyer reads before committing a portfolio.
Support, promotions, and bulk tooling
The softer differences decide the experience when a transfer goes wrong. Support quality is the variable that matters when an auth code fails or a lock will not clear, and it is the hardest to read from a policy page. Transfer-in promotions vary, since a transfer renews the domain for a year and registrars price that renewal competitively. Bulk capability is the divider for portfolio holders: NameSilo documents moving up to 500 domains at once with a CSV or TXT file, while other registrars handle transfers one at a time.
Cloudflare illustrates how prerequisites themselves become a discretion-layer signal. Its registrar requires the domain to be registered at least sixty days ago and not transferred in the last sixty days, both the ICANN floor, but it adds at-cost pricing with no markup, refuses domains with non-Latin characters, and requires post-transfer registrant verification for certain country-code TLDs such as .ca, .mx, and .nz. Those are registrar choices layered on top of the fixed rules, and reading them as one undifferentiated block is the comparison error to avoid. The deeper registrar-selection criteria live in Choosing a registrar for aged domain parking.
| Discretion-layer signal | The range registrars choose within | Why it matters for a portfolio |
|---|---|---|
| Auth-code release speed | Immediate at most, up to a five-calendar-day legal ceiling | A multi-day wait per domain stalls a deadline-bound migration |
| Lock on registration | Auto-locked by some, unlocked by default at others | An extra manual unlock step before every transfer out |
| Contact-change-lock opt-out | Offered by some registrars, not supported by others | Decides whether editing registrant data forces a sixty-day wait |
| Support on a stuck transfer | From 24/7 live chat to email-only ticketing | The variable that resolves a failed auth code or unclear lock |
| Transfer-in promotion | The mandatory one-year renewal priced competitively or at list | The only place the transfer fee is genuinely negotiable |
| Bulk transfer tooling | CSV or TXT bulk moves at some, one-by-one at others | The divider for moving an aged-domain portfolio at once |
The cost layer: transfer fees, renewals, and redemption compared
A gTLD transfer is not a free move; ICANN attaches a mandatory one-year renewal to it, so the transfer fee is really a renewal in disguise. Published .com transfer fees cluster in a narrow band, transfer-out is free across major registrars, and the wide cost variance sits in redemption fees for a lapsed domain, not in the transfer itself.
The transfer fee is a renewal
When a gTLD such as .com, .net, or .org transfers between registrars, ICANN requires the transfer to add one year to the registration, extending the expiry from its current date. The headline transfer fee is that renewal. The DomainDetails comparison records .com transfer fees in a band from 10.46 US dollars at Cloudflare to roughly 12 dollars at Namecheap, NameSilo, and GoDaddy, with Squarespace at 20 dollars, each including the year. Hostinger notes transfers similarly add a year to the term. The practical takeaway is that the cheapest transfer fee saves a dollar or two, which rarely decides which registrar holds a domain worth keeping.
Transfer-out is free, redemption is where cost varies
No major registrar charges to transfer a domain out; the DomainDetails table records free transfer-out across the board, consistent with ICANN’s expectation that a losing registrar release a domain without an exit toll. The genuine cost variance sits elsewhere. If a domain lapses and falls into redemption, recovery fees and grace periods diverge sharply: the same comparison records grace periods from 18 days at GoDaddy to 35 days at Porkbun, with redemption fees clustering around 80 to 100 US dollars or higher. For anyone holding an aged domain through a transfer, the redemption schedule is the cost line that truly bites, because a transfer that overlaps an expiry can drop a name into that window.
| Registrar | .com transfer fee (includes 1-year renewal) | Redemption grace period |
|---|---|---|
| Cloudflare | 10.46 USD (at-cost, no markup) | Varies by TLD, at-cost |
| Dynadot | 10.88 USD | 25 to 30 days |
| Porkbun | 11.08 USD | 35 days |
| Namecheap | 11.68 USD | 30 days |
| NameSilo | 11.95 USD | 30 days |
| GoDaddy | 11.99 USD | 18 days |
| Squarespace | 20.00 USD | Varies |
Transfer policy as a portfolio reliability and footprint surface
For anyone moving more than one aged or expired domain, a transfer policy stops being a comparison table and becomes a reliability and footprint surface. Done well, the transfer is read in advance, locks are cleared on schedule, and registration data is handled deliberately. Done badly, an unread policy strands a domain in a lock, leaks ownership data into a footprint, or drops a lapsing name into redemption. The reality is honest on both sides.
The reliability surface: friction is the risk
A transfer policy’s reliability shows when something has to move fast. A registrar that releases auth codes instantly, leaves domains unlocked by default, and answers a stuck transfer the same day is a reliable custodian for a portfolio in motion. A registrar that waits the full five days, auto-locks on registration, and routes a failed transfer through slow email tickets is a single point of friction at the worst moment. This is the same reliability axis the sibling guide applies to networks, where registrar choice is a continuity decision; the depth is in Registrar reliability for PBN.
The footprint surface: ownership data travels with the move
A transfer is a moment when ownership data is created, edited, and exposed. Done right, registration data is handled with intent, with privacy and registrant fields set deliberately instead of left to a default. Done badly, a careless transfer leaves a registrar default that publishes matching registrant data across a set of domains, a correlation an RDAP lookup reads as a shared fingerprint. RDAP replaced WHOIS as the standard lookup on 28 January 2025, which makes that ownership data cleaner and easier for any system to parse. For portfolio holders this cuts both ways, and it is why a transfer is handled as a footprint event, not a clerical one.
The honest reality, neither sold nor steered
Transfer policy literacy is not a tactic to push or warn against; it is the difference between a move that protects an asset and one that exposes it. Done well, a transfer carries a clean domain into a reliable registrar with its ownership handled on purpose. Done badly, it strands the same domain in friction or footprints. The variable that decides which outcome arrives is partly the policy and mostly the domain underneath it, which the closing section returns to. For buyers sourcing that domain in the first place, screened aged and expired inventory is available on the SEO Domains marketplace, so the asset entering the transfer is sound before any policy is read.
How to read a registrar’s transfer policy before you commit
Reading a transfer policy well is a six-step pass: confirm the ICANN floor applies, isolate the discretion-layer choices, check the lock status against the domain’s history, time the move against any expiry, set the registration data deliberately, and request the auth code before you need it. Each step has a done-right move and a specific mistake that exposes it.
The pass below works for a single acquisition or a portfolio. The pattern in every step is the same: separate what ICANN fixes from what the registrar chooses, then act on the choices. Run it before money changes hands, not after a transfer stalls.
-
Confirm the ICANN floor applies, then ignore it as a comparison point
The done-right move is to verify the registrar applies the sixty-day locks, the five-calendar-day auth-code rule, and the Form of Authorization, then set them aside, because every accredited registrar applies them identically. Use the floor to spot a non-compliant outlier, not to choose between compliant registrars.
The mistake: treating a sixty-day lock as a registrar difference and picking a registrar to avoid it. The lock is ICANN law and follows the domain to every registrar.
-
Isolate the discretion-layer choices
The done-right move is to read only the cells that vary: auth-code release speed, lock-on-registration default, contact-change-lock opt-out, support channel, and bulk tooling. These are the registrar’s actual policy. The framework for weighing them sits in Choosing a registrar for aged domain parking.
The mistake: comparing registrars on the fixed floor and missing the discretion layer, where the only real differences live.
-
Check lock status against the domain’s history
The done-right move is to read the domain’s recent history before committing: a registration, a prior transfer, or a registrant change inside sixty days each blocks a move. Confirm none of the three locks is active, or plan around the wait.
The mistake: buying or initiating a transfer on a domain that registered, transferred, or changed registrant within the last sixty days, then discovering the lock only when the move fails.
-
Time the move against any expiry
The done-right move is to confirm the registration has comfortable runway before transferring, since a transfer adds a year but a move that overlaps an expiry can drop a name into redemption. Redemption fees and grace periods, from 18 to 35 days, are the expensive cost line.
The mistake: initiating a transfer on a near-expiry domain, letting it lapse mid-move, and paying an 80-to-100-dollar redemption fee to recover it.
-
Set the registration data deliberately
The done-right move is to decide registrant and privacy settings on purpose at the transfer, treating the move as the moment ownership data is written. For a portfolio, vary the data instead of accepting one default across every name. The ownership read is detailed in the expired domain fundamentals hub.
The mistake: accepting a registrar default that publishes identical registrant data across a set of domains, an RDAP-readable shared fingerprint created at the moment of transfer.
-
Request the auth code before you need it
The done-right move is to unlock the domain and request the auth code early, allowing for the full five-calendar-day legal window even at a fast registrar. Enter it at the gaining registrar and confirm by email to speed the release.
The mistake: requesting the auth code at the last minute, then losing days to a registrar that uses its full five-day allowance on a deadline-bound move.
Common transfer-policy mistakes: the checklist
The mistakes that strand a transfer are a short, repeatable list. Each one is a misread of which layer a rule sits in, and each has a documented fix that points back to the same move: separate the ICANN floor from the registrar’s discretion, then plan the move before committing. Use this as the scannable reference.
The table consolidates the errors scattered through the layers above into one place. The left column is the mistake, the centre column is why it happens, and the right column is the done-right fix. Read top to bottom, the fixes describe a transfer planned in advance on a clean domain.
| The mistake | Why it happens | The fix (done-right move) |
|---|---|---|
| Switching registrars to dodge a sixty-day lock | Reading an ICANN-floor rule as a registrar difference | Treat the three sixty-day locks as fixed law; plan around them, do not registrar-shop them |
| Transferring a domain locked within sixty days | Not checking registration, prior-transfer, or registrant-change history | Confirm none of the three locks is active before initiating the move |
| Editing registrant data before a planned transfer | Not knowing a contact change triggers its own sixty-day lock | Complete the transfer first, then change registrant data, or use a registrar opt-out |
| Requesting the auth code at the last minute | Assuming instant release instead of the five-calendar-day ceiling | Unlock and request the auth code early, allowing the full legal window |
| Transferring a near-expiry domain | Not timing the move against the registration date | Confirm comfortable runway so the move never overlaps an expiry into redemption |
| Accepting a default registrant across a portfolio | Treating the transfer as clerical, not as a footprint event | Set registration data deliberately and varied at the moment of transfer |
| Optimizing the transfer fee, ignoring redemption | Comparing the visible number, not the buried one | Weigh the redemption grace period and fee, the cost line that actually bites |
| Choosing a registrar on price alone | Ignoring the support and reliability discretion layer | Weigh auth-code speed, lock defaults, and support, not just the headline fee |
One pattern runs down the whole fix column. Every error is a confusion between what ICANN fixes and what the registrar chooses, and every fix is the same discipline: layer the policy, plan the move, and protect the domain through it. A clean domain handled this way arrives sound; a clean domain handled carelessly can still be stranded, which is why the read is the work and the domain is the asset.
Registrar transfer policy frequently asked questions
The five questions buyers raise when they compare registrar transfer policies, answered against the ICANN policy record and the three-layer model this guide draws.
Q1Do registrar transfer policies genuinely differ, or are they all the same?
Both. Half of every transfer policy is fixed by ICANN and identical at every accredited registrar: the three sixty-day locks, the five-calendar-day auth-code rule, the Form of Authorization, and the denial grounds. The other half is registrar discretion, and there the policies genuinely differ on auth-code release speed, lock-on-registration defaults, contact-change-lock opt-outs, support quality, and bulk tooling.
Compare the discretion layer; the ICANN layer finds no difference because there is none to find.
Q2How long does a domain transfer take?
A standard inter-registrar transfer commonly completes within a day and rarely runs beyond about eight days. The losing registrar must release the auth code within five calendar days, and the DomainDetails comparison records typical completion of one to two days at Cloudflare and Dynadot, two to three at Namecheap, and three to five at GoDaddy. Confirming the transfer by email at the gaining registrar speeds the process.
Q3Why can a domain not be transferred?
The likeliest reason is one of the three ICANN sixty-day locks: the domain registered, transferred in, or had its registrant contact changed within the last sixty days. A separate registrar transfer lock, which the owner can clear manually, must also be off. Beyond those, a losing registrar can deny a transfer on defined grounds such as evidence of fraud or a pending dispute, but not merely to retain the business.
Q4Does it cost money to transfer a domain, and does it renew the domain?
For a gTLD such as .com, the transfer carries a mandatory one-year renewal that ICANN attaches to the move, so the fee is really a renewal. Published .com transfer fees cluster from about 10.46 to 12 US dollars, with transfer-out free across major registrars. The expensive variance is not the transfer fee but the redemption fee, 80 to 100 dollars or more, if a domain lapses during the move.
Q5Does the registrar I transfer an aged domain to affect its SEO value?
The registrar does not change a domain’s earned authority; that authority lives in the backlink profile and history, which travel with the domain. What a transfer policy affects is whether the move is clean: a reliable registrar with fast auth-code release and deliberate data handling carries the asset across without friction or a shared-ownership footprint. The domain’s quality is the variable that holds; the policy only protects it through the move.
What a transfer policy cannot fix: the domain itself
A transfer policy moves a domain; it cannot improve one. The clean, real, earned-authority domain is the asset, and the policy is only the road it travels. Reading the policy well protects that asset through the move, but it cannot rescue a junk domain. Sourcing from a screened catalogue is what puts a sound asset on the road in the first place. SEO Domains operates that curated marketplace.
Why the domain outranks the policy
Everything in this guide converges on one variable. The three-layer model, the discretion-layer comparison, the cost lines, and the six-step read all serve a single purpose: to carry a domain from one registrar to another without losing value to friction or footprints. None of that work changes what the domain is. A clean aged domain with editorially earned authority is an asset whatever registrar holds it; a junk domain bought for an inflated metric is a liability that the smoothest transfer policy cannot redeem.
The asset and the road it travels
The transfer policy is the road; the domain is what you put on it. A reliable registrar and a well-read policy keep the asset intact in transit, which is real value when an aged or expired domain changes hands. But the value being protected was created before the transfer, in the domain’s prior real use and the links it earned. Treating registrar choice as the whole decision, instead of the domain underneath, is the error the comparison guides make.
How to source a domain worth transferring
A domain worth the care of a planned transfer survives a profile check before money changes hands. The signals that matter are documented across the authority-metrics hub:
- Referring domains, and the quality, not just the count, of the links pointing in.
- DR and DA, the Ahrefs and Moz authority scores, read together rather than singly.
- Trust Flow and the TF:CF ratio from Majestic, which surface link-spam patterns a single metric hides.
- Link age, organic-traffic history, and a clean spam screen with no toxic inheritance.
A junk domain passes none of these, and no transfer policy makes it worth moving. A vetted domain passes them, and a well-read transfer policy is what keeps that value intact across the move.
| What a transfer policy does | A junk domain (liability) | A vetted domain (asset) |
|---|---|---|
| Carries the domain between registrars | Moves a toxic profile intact | Moves earned authority intact |
| Sets ownership data at the move | Footprints a name nobody wants | Protects a name worth holding |
| Times the move against expiry | Saves a domain not worth saving | Preserves a real asset through transit |
| Outcome of a clean transfer | A liability, smoothly delivered | An asset, intact and uncorrelated |
Browse screened aged and expired domains worth the move
The legitimate demand behind a transfer-policy comparison is moving a domain worth holding into a registrar worth trusting. The asset in that sentence is the domain, not the registrar’s transfer page. SEO Domains operates the curated marketplace where aged and expired domains are screened across their backlink profiles and authority metrics before they are listed and priced, so the name entering any transfer is sound before the policy is ever read.
