How to Transfer a Domain Between Registrars

What a transfer actually changes

An inter-registrar transfer changes one thing at the registry: which accredited registrar sponsors the registration. The domain does not move, the registration is not recreated, and the name is untouched. Only the registry's record of who is responsible changes.

Most of what people fear will break is unaffected. Nameserver delegation carries across unchanged, so if your DNS is hosted elsewhere, nothing about your website or email changes. The risk is the opposite case: if your DNS zone lives at the losing registrar, the transfer moves your registration but not your zone, and that registrar has no obligation to keep answering for a name it no longer sponsors. Export the zone first.

For generic extensions the process is set by ICANN's Transfer Policy, a consensus policy binding on all accredited registrars. The version in force was updated on 21 February 2024 and mandatory no later than 21 August 2025. It does not bind country-code extensions at all.

The authorization code, and your right to have it

An EPP authorization code — auth code, EPP code, transfer key, all the same thing — is a per-domain secret held at the registry proving that whoever requests a transfer controls the registration. The Transfer Policy requires these codes to be unique per domain; no registrar may issue one shared code for a portfolio.

Your entitlement is specific. The registrar must provide the code within five calendar days of your request. Most satisfy that instantly through a control panel; the five-day rule is the backstop for those that do not, and it also covers removing a transfer prohibition status where no self-service facility exists.

Two provisions matter if you meet resistance. The anti-obstruction rule: a registrar may not use any mechanism for removing clientTransferProhibited or issuing the auth code that is more restrictive than the one it uses for changing contact or nameserver information. If you can change nameservers in two clicks, nobody can demand a notarized letter for your auth code. And no registrar may refuse to remove the lock or release the code over a payment dispute.

Practically, codes are case-sensitive, easy to mistranscribe, and frequently rotated. Copy and paste, never retype.

Registrar lock is not the problem people assume

clientTransferProhibited is a status your registrar sets at the registry on your behalf. It is not a penalty, not a sign of trouble, and not something to be alarmed by. Most registrars apply it by default, and leaving it on is the most effective defense against hijacking available to an ordinary registrant.

The Transfer Policy is explicit that a registrar cannot deny a transfer merely because the domain is locked. It must provide a readily accessible means to remove it, no harder than changing contact details.

Distinguish it from two similar-looking things. serverTransferProhibited is set by the registry and your registrar cannot remove it — something outside the registrar's control is holding the domain, usually a dispute, an enforcement action or the lifecycle position. Premium registry lock services apply server-side statuses and require an out-of-band, manual authentication process to lift. That friction is the product.

Note also that a domain showing only clientTransferProhibited will not show ok, since ok cannot be combined with any other status.

The three 60-day locks, and which one you can escape

There are three separate 60-day restrictions with three separate triggers. Conflating them is the most common source of registrant confusion, and only one is mandatory.

• Sixty days after initial registration. The registrar of record may deny a transfer requested within 60 days of the creation date. The policy permits denial rather than requiring it, but virtually every registrar enforces it, and registry-level restrictions make it effectively absolute in many extensions.
• Sixty days after a prior transfer. The registrar of record may deny a transfer within 60 days, or a lesser period, after the domain was transferred. Note the phrasing — a registrar is free to allow it sooner.
• Sixty days after a Change of Registrant. This one is mandatory, sitting in the policy's must-deny list rather than its may-deny list.

The third ambushes people, because of what counts as a Change of Registrant: a material change to the registrant name, organization or email. Typographical corrections are excluded, but updating the registrant email — done for mundane reasons such as an employee leaving or a mailbox migration — triggers the lock.

The only escape is prospective. Registrars may allow a registrant to opt out in advance, and must inform the prior registrant about the lock and about the option of transferring elsewhere first. Nothing lifts it retrospectively. The rule that follows saves two months: transfer first, then change the registrant details.

The Form of Authorization and the five-day clock

Authorization is given through a standardized Form of Authorization. Two exist: an Initial Authorization for Registrar Transfer, used by the gaining registrar, and a Confirmation of Registrar Transfer Request, used by the losing one. An FOA expires on the earliest of 60 days, the domain's expiration, a completed Change of Registrant, or the transfer completing.

In practice you will see only one. On 26 January 2020 the ICANN Board deferred contractual compliance enforcement of the gaining registrar's FOA requirement, which is why most modern transfers involve no confirmation email from the registrar you are moving to.

The sequence: you remove clientTransferProhibited, obtain the auth code, then place an order at the gaining registrar and supply it. That registrar submits the request, the registry validates the code, sets pendingTransfer and notifies the registrar of record. Here is the clock everyone has heard of: failure by that registrar to respond within five calendar days results in a default approval. Silence completes a transfer, it does not block one.

So the familiar five days is a ceiling created by the losing registrar's response window, not a processing time. Where that registrar approves explicitly, a transfer completes in minutes.

What happens to your expiry date

A completed, holder-authorized transfer extends the registration by one year, subject to the rule that total unexpired term may never exceed ten years.

The detail that matters is where the year lands: on the existing expiry date, not measured from the transfer date. Transfer a domain with eight months left and you get twenty months, not twelve. You forfeit nothing, which is why renewing before a transfer is not the trap people assume.

The gaining registrar charges for that year, which is why a transfer and a renewal cost about the same. You are buying a year of registration, not paying an administrative fee. Where a domain is already near the ten-year ceiling the extension cannot be applied in full, and behavior in that edge case is implementation-specific.

Why transfers fail

Almost every failed transfer traces to one of these.

• The domain is inside a 60-day lock — after a recent registration, a recent transfer, or, most surprising to the registrant, a recent change to the registrant name, organization or email.
• The registrar lock was never removed.
• The auth code is wrong, stale or expired. Codes are case-sensitive, often rotated, and frequently truncated by a careless copy and paste.
• The registrant cannot receive the confirmation. If the account email is dead, abandoned or filtered, the FOA is never confirmed. Far more common now than before 2018.
• The domain is expired or in redemption. A name in redemptionPeriod must be restored before it can move.
• A dispute or enforcement status is present — UDRP, URS, a court order, or serverTransferProhibited.
• A privacy or proxy service is in the way. Some must be disabled first, and disabling one can change the registrant email triggering a Change of Registrant lock.
• Non-payment or a billing dispute where the registrar has invoked a permitted ground, though that never entitles it to withhold the auth code.
• The request was made too close to expiry. Not a policy bar, but a practical one: the transfer may not complete before the expiry date arrives.

Knowing what a registrar must not do helps. It may not deny a transfer for non-payment relating to a future registration period, for a registrant's silence, or because the domain is locked without giving you a chance to unlock it. A wrongful denial goes to ICANN Contractual Compliance as a Transfer Complaint.

Country-code extensions do not work this way

ICANN's Transfer Policy does not bind country-code registries, and several use mechanisms sharing no vocabulary with the generic process.

• .uk currently transfers by changing the IPS tag, a registry-level identifier for the registrar holding the domain. There is no auth code, no five-day approval clock and no confirmation email chain. The change is instant and one-directional: the losing registrar moves the tag, then the registrant tells the gaining registrar to pick the domain up. The request must come from the registrant contact of record at Nominet, not from whoever holds the registrar login, and the transfer adds nothing to the expiry date. Nominet has published a replacement policy moving .uk to a transfer authorisation code model; its policy page gives 9 February 2027 while the registrar-facing page says the date will be announced, so treat it as announced rather than live.
• .nl uses a transfer token. The current registrar must supply it within five days on request and cannot refuse, and the transfer executes immediately on submission, with no pending window and no 60-day locks. Only the registrant recorded at the registry may request one, and a change of registrant there is a novation, so sequencing decides who must obtain the token.
• .ca uses an auth code supplied within five business days, applies its own roughly 60-day restrictions, and does add a year. .com.au uses an auth code with its own format rules plus a registrant confirmation. .co.za has no auth code at all: the registry emails the contacts and runs a five-day approval window.

Read the registry's own transfer policy first. Even where a mechanism looks familiar, the timings, entitlements and effect on your expiry date are set by that registry alone.

The reform that has been approved but is not in force

There is a live effort to change much of this. It has not landed.

The Transfer Policy Review working group completed its Final Report on 5 February 2025 and the GNSO Council adopted it on 12 March 2025. ICANN opened a public comment proceeding for Board consideration on 28 April 2025, with the summary report dated 2 July 2025. Among 47 recommendations, the group proposed cutting the 60-day post-creation and post-transfer restrictions to 30 days and eliminating the Change of Registrant restriction.

No ICANN primary source shows the Board adopting the recommendations, no replacement policy text has been published, and no implementation date has been set — the project page still lists the Board paper, Board resolution and notice of policy actions as to be determined. The 21 February 2024 Transfer Policy remains operative.

Two consequences follow. The three 60-day locks are live, and any plan assuming the Change of Registrant lock has gone will cost its author two months. And the changes discussed in trade coverage — renaming the auth code, imposing a short expiry on it, retiring the Form of Authorization — are proposals, not rules.