--- id: "domain-transfer" kind: "glossary-term" title: "domain transfer" language: "en" category: "Transfers and EPP" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/glossary/domain-transfer/" translations: es: "https://tldlog.com/es/glosario/transferencia-dominio/" de: "https://tldlog.com/de/glossar/domaintransfer/" fr: "https://tldlog.com/fr/glossaire/transfert-nom-domaine/" it: "https://tldlog.com/it/glossario/trasferimento-dominio/" pt-BR: "https://tldlog.com/pt/glossario/transferencia-dominio/" ru: "https://tldlog.com/ru/glossariy/perenos-domena/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-zhuanyi/" --- # domain transfer Moving a domain name from one registrar to another, often for better service or price. The owner unlocks the name, gets the auth code and asks the new registrar to start. In gTLDs, a transfer usually adds one year to the term. Changing the owner is a separate process. A domain transfer moves a domain name from one registrar, the company that manages it for the holder, to another. The holder stays the same; only the company changes. For gTLDs such as .com, ICANN's rules set who does what and by when. ## What a domain transfer is, and what it is not The losing registrar hands the name to the gaining registrar. For gTLDs, ICANN's Transfer Policy, in force since 12 November 2004, gives holders the right to transfer, and only the holder can approve or deny one. As of October 2026, the version in force is the one updated on 21 February 2024, mandatory since 21 August 2025. A transfer is not a change of owner (change of registrant), which has its own rules, nor a change of web hosting, which needs no transfer. Country-code TLDs set their own rules. In .eu, one code serves for a new registrar, a new holder or both, and a registrar lock does not block it. For .es, Red.es sets the procedure. ## Before you start: locks, the auth code and the 60-day rule The current registrar must provide two things: - **An unlocked name.** The registrar lock, clientTransferProhibited, makes the registry reject transfers. A registrar may set it only at registration or at the holder's request, under terms in the registration agreement. - **The auth code.** A secret code, unique to each domain, that the holder gives to the new registrar. Without a self-service tool, the registrar must provide both within five calendar days of the request. It may not make this harder than changing contact or name server details, nor hold back because of a payment dispute. As of October 2026, two 60-day periods apply. A registrar may refuse a transfer within 60 days of the name's creation or of a previous transfer. After a change of registrant (a material change to the holder's name, organization or email address), it must apply a 60-day transfer lock unless the holder opted out beforehand. The policy advises transferring first and changing the owner afterwards. Expired names can be transferred unless a previous period is unpaid, but a name in redemption must first be restored, which may cost a fee. ## Step by step: from request to completion 1. The holder unlocks the name and gets the auth code. 2. The holder orders the transfer at the new registrar and gives it the code. 3. The registry checks the code and notifies both registrars. The domain shows pendingTransfer. 4. Within 24 hours, the losing registrar asks the holder to confirm, using the FOA. 5. The losing registrar approves or rejects. With no answer within five calendar days, the registry completes the transfer. 6. One year is added to the registration, up to a total of ten years. These are maximums, not typical times. As of October 2026, ICANN has not enforced the gaining registrar's own FOA since 26 January 2020. For example, the new registrar files a request for example.com on a Monday. If the old registrar stays silent, the move completes five calendar days later and the expiry date moves one year. Had the holder changed the registrant email the week before without opting out, the transfer would be refused. ## What it costs Registrars set their own transfer prices, but a transfer cannot be refused because that fee is unpaid. Registry rules can differ: under the 2005 .net agreement, a transfer during the auto-renew grace period cancels the auto-renew year and adds one instead. ## Why a transfer can be refused The losing registrar must give its reason. As of October 2026, it **may** refuse for evidence of fraud, a reasonable dispute over the holder's identity, unpaid previous periods (or, before expiry, the current one), the holder's express objection, or the 60-day period after creation or a previous transfer. It **must** refuse during a UDRP or URS case it knows of, under a court order, during a pending dispute over an earlier transfer, or during the 60-day lock after a change of registrant. It **may not** refuse because a future period is unpaid, because the holder did not respond, or because of a lock the holder could not remove. ## Problems and disputes: what to do if a transfer goes wrong - **Unexpected pendingTransfer.** ICANN advises asking the registrar at once to deny the request. - **Disputed refusal or lock.** The holder can file a Transfer Complaint with ICANN. - **Emergencies between registrars.** Each registrar keeps a TEAC. As of October 2026, a person must answer within 4 hours; silence can lead to the transfer being undone. - **TDRP.** Only registrars can file, within 12 months, with an approved provider (as of October 2026, the ADNDRC or Forum, formerly the National Arbitration Forum). An invalid transfer is returned to the previous registrar. Courts remain open. When a registrar is bought or loses its accreditation, ICANN can approve a bulk transfer of all its names: free up to 50,000 names, a flat US$50,000 above that (as of October 2026). Some registries offer BTAPPA for part of a portfolio. ## Upcoming changes to the transfer rules On 7 June 2026, the ICANN Board adopted the 47 recommendations of the Transfer Policy Review (resolution 2026.06.07.04). As of October 2026, they are **not in force**: ICANN lists the project as queued, with no effective date. Once implemented, the main changes will be: - The auth code will become the Transfer Authorization Code (TAC): at least 128 bits strong, valid for 336 hours (14 days) and usable once. The holder will be notified within 10 minutes of its issue. - The gaining FOA will disappear; the losing registrar's form will become a Transfer Confirmation, with no one-click approval. - A mandatory 720-hour (30-day) lock will follow registration and every transfer; only the lock after a transfer may be lifted early, on a reasoned request such as a documented sale. - A change of registrant will bring no lock, only a notice within 24 hours, under a separate Change of Registrant Data Policy. - Registrars will be able to refuse for DNS abuse and will have to refuse if the holder objects. - A TEAC will have 24 hours to answer. - BTAPPA will join the policy and extend to customers moving their own portfolio. ## Sources - [Transfer Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - [Registrar Transfer Dispute Resolution Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/registrar-transfer-dispute-resolution-policy-21-02-2024-en) - [Final Report on the Transfer Policy Review Policy Development Process](https://gnso.icann.org/sites/default/files/policy/2025/correspondence/tpr-team-to-gnso-council-04feb25-en.pdf) ## related terms - [auth code](https://tldlog.com/glossary/auth-code/) - [transfer lock](https://tldlog.com/glossary/transfer-lock/) - [change of registrant](https://tldlog.com/glossary/change-of-registrant/) - [EPP](https://tldlog.com/glossary/epp/)