# How does a domain transfer work? A domain transfer moves a name to a new registrar at the registry, on proof of an authorization code. Changing the owner is a separate, locked operation. --- A domain transfer works by having the registry, which keeps the master record of every name under an extension, replace the registrar listed as the sponsor of your name with a new one, after the new registrar presents an authorization code that only the current holder can obtain and the current registrar has had a short window to object. The transfer moves the management of the name from one registrar to another; it does not, by itself, change who owns the name, and it does not move your website or your mailboxes. Most of the trouble comes from using one word for three different operations. Moving a name between registrars, handing a name to a new owner, and pushing a name from one customer account to another inside the same registrar follow different rules, trigger different locks and fail for different reasons. For generic extensions such as .com, .net or .org, those rules are set by ICANN's Transfer Policy, which every accredited registrar must follow, and this article describes that policy as published. Country-code extensions answer to their own registries. All of it is general information, not legal advice.
5 calendar daysthe longest a registrar may take to hand over the authorization code and lift its lock when it offers no self-service tool
60 daysthe block on moving to another registrar after a change of registrant, unless the holder opted out beforehand
1 yearadded to the registration when a transfer between registrars completes, within a ten-year ceiling

Figures from ICANN's Transfer Policy for generic top-level domains, as published; country-code registries set their own.

## Who are the registry, the registrar and the registrant in a domain transfer? The registry is the operator of the extension and holds the single authoritative database of names under it; the registrar is the accredited company that manages registrations in that database for customers; the registrant is the person or organisation in whose name the domain is registered. A transfer is a change in the second of those three roles, recorded by the first, at the request of the third. Each role sees a different part of the record. The registry stores, for every name, which registrar sponsors it, when it was created and when it expires, which name servers it is delegated to, and a set of status codes. It deals with registrars only. The registrar holds the customer relationship: the account, the billing, the registrant's contact details and the control panel. The registrant, whom ICANN's policy calls the Registered Name Holder, holds the right to use the name for as long as it stays registered and paid. ## What are the three operations people call a domain transfer? The three operations are a transfer between registrars, which changes who manages the name; a change of registrant, which changes who holds it; and an account-to-account push inside one registrar, which changes which customer login controls it. Only the first is a transfer in the registry's vocabulary. | Operation | What changes | Who carries it out | Main policy effect | | --- | --- | --- | --- | | Transfer between registrars | The sponsoring registrar on the registry's record | Gaining registrar, registry, losing registrar | One year added; a further move can be refused for 60 days | | Change of registrant | The holder's name, organisation or email address | The current registrar alone | Both sides confirm; 60-day block on changing registrar unless opted out | | Account push inside one registrar | The customer account that controls the name | The current registrar alone | None of its own, but usually amounts to a change of registrant | The third row is where most misunderstandings sit. A push is a convenience offered by registrars, not an operation defined by ICANN: the registry sees nothing, no authorization code is used, and no year is added. Yet the receiving account normally belongs to a different person with a different name and email address, so the registrar treats the push as a change of registrant. A push that looks instant on screen can leave the name unable to leave that registrar for two months. ## How does a transfer between registrars work, step by step? A transfer between registrars runs in a fixed sequence: the holder unlocks the name and obtains the authorization code from the current registrar, gives that code to the new registrar, the new registrar sends a transfer request to the registry, the registry checks the code and notifies the current registrar, and the transfer completes when the current registrar approves it or when the objection window closes without a refusal.
The sequence of a transfer between registrarsGeneric top-level domains, under ICANN's Transfer Policy as published
  1. Check that the name can moveLook up the status codes of the name and its creation date, and confirm that the registrant email address on file is one you can read.
  2. Remove the registrar's transfer lockSwitch off the lock in the control panel of the current registrar, or ask the registrar to remove it.
  3. Obtain the authorization codeGenerate or request the code at the current registrar. Where no self-service tool exists, the registrar must provide the code and remove its lock within five calendar days of your first request.
  4. Open the transfer at the gaining registrarOrder the transfer in the account that will hold the name, enter the code and pay the transfer fee.
  5. The registry checks the codeThe gaining registrar submits the request. The registry verifies the code, marks the transfer as pending and notifies both registrars.
  6. The losing registrar notifies the holderThe current registrar must send its confirmation notice as soon as it can and no later than 24 hours after the registry's notification. The holder can approve, object, or do nothing.
  7. The registry completes the moveUnless the losing registrar refuses on a permitted ground within five calendar days, the registry records the gaining registrar as sponsor and notifies both registrars.
Silence does not stop a transfer. The policy states that a transfer is approved by default if the losing registrar does not respond within five calendar days, and that a registrar may not refuse because the holder failed to answer its notice. The confirmation message is a chance to object, not a requirement to approve. The policy as written also asks the gaining registrar to collect its own confirmation from the holder on a standard form before sending the request. ICANN notes on the policy page that enforcement of that requirement is deferred, and its guidance for name holders adds that a gaining registrar that cannot see the registration data of a name is not required to obtain the form. In practice, possession of the code together with the losing registrar's notice now carries the authorization. ## What is the authorization code, and who may see it? The authorization code, which ICANN's policy calls the AuthInfo code and registrars also call the transfer code or EPP code, is a secret string attached to one domain at the registry that the gaining registrar must present for the registry to accept a transfer request. Whoever holds the code and an account at any registrar can start moving the name. The code comes from the Extensible Provisioning Protocol, the IETF standard that registrars use to talk to registries: a transfer request carries the authorization information of the domain. ICANN's policy adds the rules around it. The code must be unique to each name. The way a holder obtains it may not be more restrictive than the way the same holder changes contact details or name servers. And a registrar may not withhold the code, or refuse to remove its lock, only because of a payment dispute. The policy also says that the code identifies the holder but does not replace authorization. That distinction matters in a sale. A seller who sends the code to a buyer has given away the practical means to move the name, whatever was agreed about timing. Release it at the agreed step of the handover and generate a fresh one if a deal falls through after the old one was shared. ## Which locks and statuses stop a domain from transferring? A domain cannot transfer while its record carries a transfer prohibition set by the registrar or by the registry, while a transfer is already pending, or during the 60-day windows the policy protects after registration, after a previous transfer and after a change of registrant. The status codes are public: they appear in the lookup result of any name. | Status code | Set by | Effect on a transfer | | --- | --- | --- | | ok | Registry, by default | No restriction and no operation pending | | clientTransferProhibited | Registrar | The registry rejects transfer requests until the registrar removes the code | | serverTransferProhibited | Registry | The registry rejects transfer requests; removal can take longer | | pendingTransfer | Registry | A request to move the name is being processed | | clientHold or serverHold | Registrar or registry | The name is not published in the DNS and does not resolve | | redemptionPeriod | Registry | The name was deleted and must be restored by the current registrar before it can move | According to ICANN's description of these codes, the ones that begin with "client" are set by registrars, the ones that begin with "server" are set by registries, and the server codes take precedence. The registrar's prohibition is the ordinary lock, a safeguard against an unauthorized move; under the policy it may be set only at registration or at the holder's request, on terms the holder accepted. The registry's prohibition is less common and, in ICANN's words, usually applied during disputes, at the registrant's request or during redemption. The time-based restrictions do not always show as a status code, because a registrar is not required to use a particular code for the lock that follows a change of registrant. A name registered 22 days ago can be refused for another 38 days whatever its status line says. Read the creation date and ask the registrar when the last change of registrant was recorded. ## When can a registrar refuse a transfer, and when is refusal not allowed? A registrar may refuse a transfer only on the grounds the policy lists, must refuse on a short list of others, and is expressly forbidden from refusing on several grounds that customers still encounter. A refusal outside those lists can be reported to ICANN. | Rule | Grounds listed in the policy | | --- | --- | | May refuse | Evidence of fraud; a reasonable dispute over the holder's identity; unpaid fees for a previous or current registration period; the holder's own express objection; a request within 60 days of creation or of a previous transfer | | Must refuse | A pending domain dispute proceeding the registrar has been told of; a court order; a pending dispute over an earlier transfer; the 60-day lock after a change of registrant when the holder did not opt out | | May not refuse | Non-payment for a pending or future registration period; no response from the holder; a lock the holder had no reasonable chance to remove; a payment dispute between the registrar and its own business partners | The payment rules are the ones most often misread. A registrar can refuse over money owed for a period already delivered, including a reversed card payment, and must put the name on hold first. It cannot hold a name because the customer declines to renew with it, and ICANN's guidance for name holders states that an expired name can still be transferred unless an earlier period is unpaid. The losing registrar must state its reason for a refusal to the holder and to the gaining registrar. If the reason is not on the permitted list, ICANN accepts a transfer complaint from the holder. Disputes between two registrars over a completed transfer go to a separate procedure, the Transfer Dispute Resolution Policy. ## How does a change of registrant work? A change of registrant is carried out entirely by the current registrar: it obtains confirmation from the new registrant and from the prior registrant through a secure mechanism, processes the change within one day of receiving both, notifies both, and then blocks any move to another registrar for 60 days unless the prior registrant opted out before the request. The registry's sponsor record does not change and no year is added. The policy defines the operation by its content, not by the registrar's menu. A change of registrant is any material change to the registrant's name, organisation or email address. Correcting a typing error in a name is not material; any change of email address is. An owner who merely updates an old email address, with no sale in view, can therefore find the name locked for two months. The confirmations must be real ones. The policy gives as examples an email that requires an affirmative response, or a unique code sent by text message or by telephone. Each side has a window set by the registrar, never longer than 60 days, after which the request lapses. Either side may appoint a designated agent to confirm on its behalf. The opt-out changes a timeline. The holder may waive the 60-day lock, but only before the change of registrant is requested, and ICANN's guidance notes that registrars are not required to offer the option. ## What does the order of the two operations cost in time on a sale? On a sale where the buyer wants the name under its own details at its own registrar, the order of the two operations can separate a handover of about five days from one of about 65. The difference comes entirely from the 60-day lock that follows a change of registrant. Take a worked example. A seller holds a one-word .com name at registrar A. The buyer wants the name registered to the buyer and sponsored by registrar B. Day 0 is the day the price has been paid and both sides are ready to act. Assume every confirmation is given the same day it is asked for, the name is free of other restrictions, and the five-day objection window runs in full.
Days until the name is at the buyer's registrar in the buyer's nameWorked example, calendar days from day 0, objection window run in full
Owner first, no opt-out then transfer 65 days Owner first, opt-out then transfer 5 days Transfer first then change the owner 5 days

Illustrative. 65 days is the 60-day lock plus the five-day objection window; 5 days is the objection window alone. Early approval by the losing registrar shortens each route.

The three routes do not carry the same exposure. On the first, the buyer is the registrant from day 0 and simply waits at registrar A. On the second, the seller must have given the opt-out before the change, so it has to be planned before day 0. On the third, the name sits in an account the seller opens at registrar B during the transfer, and the buyer becomes registrant only once it lands; registrar B may then refuse a further move until day 65, which does not trouble a buyer who wanted the name there. ## What happens to DNS, the website and email during a transfer? A transfer between registrars does not change the name servers recorded at the registry, so a website and mailboxes keep working throughout the move as long as the DNS zone itself is hosted somewhere that survives it. The risk is a DNS service that belonged to the losing registrar and stops when the name leaves. What makes a name resolve is the delegation held at the registry: the list of name servers published for the name. Under the IETF's provisioning protocol, a transfer is a request to change the sponsorship of the domain object, and nothing in the operation rewrites the delegation. If the name points to name servers run by a hosting company or an independent DNS provider, those servers go on answering as before. The exposure appears when the name servers are those of the losing registrar. Many registrars include DNS hosting, email forwarding or mailboxes with the registration, and may withdraw them once they no longer sponsor the name. The delegation then points to servers that no longer answer, and both the website and inbound email fail until it is changed. - Read the name servers in the lookup result of the name to see where the DNS zone is hosted. - If the zone is hosted by the losing registrar, copy every record, including mail and verification records, and rebuild the zone at the gaining registrar or an independent DNS provider. - Switch the delegation to the new name servers while the name is still at the losing registrar, and wait until traffic has moved. - If the zone is signed with DNSSEC, coordinate the change of keys with both providers before switching. - Move any mailbox or forwarding service the losing registrar provided, since it ends with the account. ## What does a transfer add to the registration, and how long does it take? A completed transfer between registrars extends the existing registration by one year, and under the policy it takes at most five calendar days from the registry's notification, often less when the losing registrar approves early. The added year is counted from the current expiry date, so no time already paid for is lost. On the term, a name that expires in 140 days expires in 505 days once the transfer completes. The policy caps the total unexpired term at ten years, so a name already registered for nine years and 200 days ahead has room for only 165 more days before the ceiling. The fee charged by the gaining registrar is in practice the price of that added year, and registrars set it freely. On duration, the pieces are the wait for the code, which is zero with a self-service tool and at most five calendar days otherwise, and the objection window of five calendar days. The outer limit under the policy is therefore ten calendar days for a name free of locks. ## Do country-code domains follow the same transfer rules? Country-code domains do not follow ICANN's Transfer Policy: each country-code registry writes its own rules for changing registrar and for changing the holder. ICANN's policy binds its accredited registrars and the registries of generic extensions only. The differences fall into a few families. A registry may use an authorization code much like the generic one, or no code at all. It may treat a change of holder as a formal operation carried out at the registry itself, with identity checks, forms or a fee. It may restrict who can hold a name, by residence or company registration, so a change of holder can be refused because the buyer is not eligible, whatever the two parties agreed. For any name outside the generic extensions, read the registry's own published policy before agreeing a handover date, and confirm that the receiving registrar is accredited for that extension. ## Why do domain transfers fail, and how do you recover? Domain transfers fail for a small number of repeatable reasons: a lock left on, a wrong or outdated authorization code, a protected 60-day window, an unreachable registrant email address, a name in redemption, or a dispute or court order attached to the name. Each has a specific remedy. - **The registry rejects the request at once.** The name carries a transfer prohibition or the code is wrong. Remove the lock, generate a new code and resubmit. - **The request is refused within the objection window.** Ask for the stated reason. Refusals for a recent registration, transfer or change of registrant are resolved only by waiting. - **The confirmation notice never arrives.** It went to an address nobody reads. The transfer still completes by default, but the chance to approve early or to object is lost. Correcting the address is itself a change of registrant, so check it before a sale, not during one. - **The name is in redemption.** The current registrar must restore it first, usually for a fee. - **The account is at a reseller.** A reseller sells registrations under its own brand through an accredited registrar. If the reseller cannot produce the code, the accredited registrar behind it is the party bound by the five-day deadline. When a transfer completes that the holder never authorized, time matters. The policy requires every registrar to maintain a transfer emergency contact for other registrars, with a response from a person due within four hours; a gaining registrar that fails to answer gives the registry a ground to undo the transfer. The registry also reverses a transfer when both registrars agree it was made in error, on a final decision under the dispute policy, or on a court order. The request goes through the registrar that lost the name, so contact it immediately and in writing. ## Is the ICANN Transfer Policy changing? The Transfer Policy has been under review, and the ICANN Board adopted the recommendations of that review at its meeting of 7 June 2026, directing the organisation to implement them; until a revised policy is published with an effective date, the rules described in this article are the ones registrars are held to. Anyone planning a handover should check which version is in force on the day. According to the final report of the GNSO working group that carried out the review, the 47 recommendations touch the mechanism directly. The authorization code would be renamed the Transfer Authorization Code, generated only on request and valid for a short period. The windows after registration and after a transfer would be set at 30 days in place of 60. The form the gaining registrar is supposed to collect would be dropped, while the losing registrar's notice would be kept. And a change of registrant data would lead to a notification to the holder, without confirmation by both sides and without the 60-day lock that follows it today. Those are recommendations awaiting implementation, and the final wording and dates may differ. For a sale agreed now, plan around the published policy and write the order of operations into the agreement. The payment, and the point at which the name is released against it, is a separate matter from the mechanism described here.