Note: This document provides a summary of registrar requirements related to the Transfer Policy as stated in the link below. The summarization of terms within this document do not override or replace the terms set forth within the stated policy. Please refer to the full text of the policy to review and understand the requirements for registrars.

Full Policy at:

This section covers the following:

Change of Registrant (Section II)



  • Change of Registrant - Material Change to:
    1. Prior Registrant Name; OR
    2. Prior Registrant Organization; OR
    3. Prior Registrant email address; OR
    4. Administrative Contact email address, if there is no Prior Registrant email address.
  • Prior Registrant –registered name holder (RNH) when change is initiated
  • New Registrant – entity or person to whom the Prior Registrant proposes to transfer its domain name registration
  • Material Change - means a non-typographical correction:
    1. A change to the Registered Name Holder’s name or organization that does not appear to be merely a typographical correction;
    2. Any change to the Registered Name Holder’s name or organization that is accompanied by a change of address or phone number;
    3. Any change to the Registered Name Holder’s email address.


Availability of Change of Registrant:

- In general, registrants must be permitted to update their registration/Whois data and transfer to other registrants freely.

- Registrar must deny request for change of registrant if:

    1. Registration agreement has expired, and registrant no longer has the right to renew or transfer the domain name to another registrar, per  Expired Registration Recovery Policy (ERRP)
    2. Change of Registrant was not properly authorized by the Prior Registrant and the New Registrant
    3. Domain name in dispute (e.g., URS, UDRP, TDRP, court order)


Change of Registrant Process

(1)  Confirm domain name is eligible for Change of Registrant

(2)  Confirm, via secure mechanism, that New Registrant (or Designated Agent) has explicitly consented to Change of Registrant

(3)  Inform the Prior Registrant (or Designated Agent) that if its final goal is to transfer the domain name to a different registrar, advised to request the inter-registrar transfer before the Change of Registrant to avoid triggering the 60-day lock described in II.C.1.2 (unless registrar gave Prior Registrant option to opt out, and Prior Registrant opted out of the 60-day lock)

(4)  Confirm, via secure mechanism, that Prior Registrant (or Designated Agent) has explicitly consented to Change of Registrant

(5)  Process Change of Registrant within one (1) day of obtaining the confirmations

(6)  Notify the Prior and New Registrant per II.C.1.1.6

(7)  Lock name (if applicable) per II.C.2


Change of Registrant process (section II.C.1.1) does not apply to following situation:

    1. Registration agreement expires
    2. Registration agreement is terminated by the registrar
    3. Registrar or registry updates the prior registrant’s information pursuant to a court order
    4. Update per UDRP decision implementation
    5. Update per Expired Domain Deletion Policy
    6. Updates in response to an abuse complaint


Registrar Notification to Registered Name Holder (Section II.C)

  • 1.1.2  and 1.1.4 –
    • inform the New Registrant that it must enter into a registration agreement with the Registrar;
    • include instructions on how to approve or cancel the Change of and inform the Prior Registrant and New Registrant that the request will not proceed if it is not confirmed in a number of days set by the Registrar, not to exceed sixty (60) days;      
  • 1.1.6 -
    • – always be sent to both the New Registrant and Prior Registrant before or within one day of the Change of Registrant;
    • - explain the request that was received and list the domain(s) in question;
    • - include contact information for questions.
    • – inform the New and Prior Registrant of 60-day lock (if applicable); or advise the Prior Registrant that it previously opted out of the 60 day lock


60-day Inter-Registrar Transfer Lock (II.C.2)

  • Registrar must impose 60-day inter-registrar transfer lock following Change of Registrant;
  • Registrar may offer “opt-out” option of the lock to the Prior Registrant, prior to the change of registrant request;
  • Registrar may not need to impose the Registrar Lock, if it offers an “opt-out” option, and the Prior Registrant has opted-out of the lock.


Inter-Registrar Transfer  (Section I.A.1-4) 


Transfer Authorities (Transfer Contact)

Both Administrative Contact and the Registered Name Holder (RNH) can approve or deny an inter registrar transfer request.  However, In the event of a dispute, the Registered Name Holder's authority supersedes that of the Administrative Contact.


As a Gaining Registrar

    • Registrars may communicate in additional languages in the FOA. However, Registrars are responsible for the accuracy and completeness of the translation.
  • Registrar must receive confirmation from the Transfer Contact before moving forward.
  • The Gaining FOA shall expire until either one of the following conditions (Section I.A):

a. a period of sixty (60) days has passed since the FOA was issued by the Gaining Registrar, unless the Gaining Registrar allows automatic renewal of the FOA and the Registered Name Holder has expressly opted in to the automatic renewal;

b. the domain name expires before the inter-registrar transfer is completed;

c. a Change of Registrant is completed further to Section II.C.

d. the inter-registrar transfer is completed.

  • If the FOA expires pursuant to any one of the above, prior to submitting the "transfer" request to the registry, in order to proceed with the transfer, the Gaining Registrar must re-authorize the transfer request via a new FOA.


As a Losing Registrar

    • Registrars may communicate in additional languages in the FOA. However, Registrars are responsible for the accuracy and completeness of the translation.
  • In the event the RNH preapproves a transfer, the Registrar has the option of sending a modified version of the FOA, which informs the RNH that the preapproved transfer has been initiated.
  • If the losing registrar does not receive a confirmation from the Transfer Contact, and the registrar has not explicitly denied the transfer request, after five (5) calendar days, the default action will be that the registrar must allow the transfer to proceed. It’s a default "approval" of the transfer.
  • The Losing Registrar MAY deny (NACK) a transfer request based on any of the following reasons: (Section I.A.3.7)

a. 3.7.1 Evidence of fraud.

b. 3.7.2 Reasonable dispute over the identity of the RNH or Administrative Contact.

c. 3.7.3 No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer.

d. 3.7.4 Express objection to the transfer by the authorized Transfer Contact.

e. 3.7.5 The transfer was requested within 60 days of the creation date as shown in the registry WHOIS record for the domain name.

f. 3.7.6 A domain name is within 60 days after being transferred into that Losing Registrar.

  • The Losing Registrar MUST deny (NACK) a transfer request in any of the following circumstances: (Section I.A.3.8)

a. 3.8.1 A pending UDRP proceeding that the Registrar has been informed of.

b. 3.8.2 Court order by a court of competent jurisdiction.

c. 3.8.3 Pending dispute related to a previous transfer pursuant to the Transfer Dispute Resolution Policy.

d. 3.8.4 URS proceeding or URS suspension that the Registrar has been informed of.

e. 3.8.5 The Registrar imposed a 60-day inter-registrar transfer lock following a Change of Registrant, and the RNH did not opt out of the 60-day inter-registrar transfer lock prior to the Change of Registrant request.


Transfer Emergency Action Contact

  • Registrars will establish a Transfer Emergency Action Contact ("TEAC") for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars (in a language that both parties can understand) in an emergency. Further actions can then be taken towards a resolution, including initiating existing (or future) transfer dispute or undo processes.
  • Communications to TEACs will be reserved for use by ICANN-Accredited Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact may be designated as a telephone number or some other real-time communication channel. Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain.
  • Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the Gaining Registrar. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer.
  • Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section I.A.6.4 of this policy and may also result in further action by ICANN.
  • Both parties will retain correspondence in written or electronic form of any TEAC communication and responses, and share copies of this documentation with ICANN and the registry operator upon request.


Requirements for the "ClientTransferProhibited" Status and "AuthInfo" Codes (Section I.A.5)


  • Registrars may only impose a "ClientTransferProhibited" status for a domain name upon registration or subsequent request by the RNH, if it includes in its registration agreement the terms and conditions for imposing such status and obtains consent from the Registered Name Holder
  • Registrars must remove the "ClientTransferProhibited" status within five (5) calendar days of the Registered Name Holder’s initial request and provide the Registered Name Holder with the unique "AuthInfo" code. (if the registrar does not provide facilities for the Registered Name Holder to generate their own “Authinfo” code and to remove the “ClientTransferProhibited” status).
  • Registrars may not employ any mechanism for RNH’s request to remove the "ClientTransferProhibited" status or obtain the applicable "AuthInfo Code" that is more restrictive than the mechanisms used for changing any aspect of the RNH's contact or name server information.
  • Registrar-generated "AuthInfo" codes must be unique on a per-domain basis.
  • “Authinfo” codes must be used solely to identify a RNH.
  • The registrar may not refuse to remove “ClientTransferProhibited” status or release an “Authinfo Code” solely because there is a dispute over payment.


ICANN Approved Transfer (Section I.B)


  • Registrar can transfer all its sponsored registrations to another registrar as the result of:

(i)    Acquisition of that Registrar or its assets by another Registrar, or

(ii)   Registrar’s RAA with ICANN or RRA with the Registry are terminated

  • Registrar shall utilize the following procedure:

    • The gaining Registrar must be accredited by ICANN for the Registry TLD and must have in effect a Registry-Registrar Agreement with Registry Operator for the Registry TLD.

    • ICANN must certify in writing to Registry Operator that the transfer would promote the community interest, such as the interest in stability that may be threatened by the actual or imminent business failure of a Registrar.

  • Upon satisfaction of these two conditions:

a. Registry Operator will make the necessary one-time changes in the Registry database for no charge for transfers involving 50,000 name registrations or fewer.

b. If the transfer involves registrations of more than 50,000 names, Registry Operator will charge the gaining Registrar a one-time flat fee of US$ 50,000.

  • No labels