This version of the Transfer Policy was superseded by the Transfer Policy found here as a result of additional feedback from the ICANN Community.
Registered Name Holders must be able to transfer their domain name registrations between Registrars provided that the Gaining Registrar's transfer process meets the minimum standards of this policy and that such transfer is not prohibited by ICANN or Registry policies. Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusion. Further, Registrars should make reasonable efforts to inform Registered Name Holders of, and provide access to, the published documentation of the specific transfer process employed by the Registrars.
The Administrative Contact and the Registered Name Holder, as listed in the Losing Registrar's or applicable Registry's (where available) publicly accessible Whois service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the Registered Name Holder's authority supersedes that of the Administrative Contact.
Registrars may use Whois data from either the Registrar of Record or the relevant Registry for the purpose of verifying the authenticity of a transfer request; or from another data source as determined by a consensus policy.
Gaining Registrar Requirements
For each instance where a Registered Name Holder requests to transfer a domain name registration to a different Registrar, the Gaining Registrar shall:
2.1 Obtain express authorization from either the Registered Name Holder or the Administrative Contact (hereafter, "Transfer Contact"). Hence, a transfer may only proceed if confirmation of the transfer is received by the Gaining Registrar from the Transfer Contact.
2.1.1 The authorization must be made via a valid Standardized Form of Authorization (FOA). There are two different FOA's available at the ICANN website. The FOA labeled "Initial Authorization for Registrar Transfer" must be used by the Gaining Registrar to request an authorization for a registrar transfer from the Transfer Contact. The FOA labeled "Confirmation of Registrar Transfer Request" must be used by the Registrar of Record to request confirmation of the transfer from the Transfer Contact.
The FOA shall be communicated in English, and any dispute arising out of a transfer request shall be conducted in the English language. Registrars may choose to communicate with the Transfer Contact in additional languages. However, Registrars choosing to exercise such option are responsible for the accuracy and completeness of the translation into such additional non-English version of the FOA.
2.1.2 In the event that the Gaining Registrar relies on a physical process to obtain this authorization, a paper copy of the FOA will suffice insofar as it has been signed by the Transfer Contact and further that it is accompanied by a physical copy of the Registrar of Record's Whois output for the domain name in question.
18.104.22.168 If the Gaining Registrar relies on a physical authorization process, then the Gaining Registrar assumes the burden of obtaining reliable evidence of the identity of the Transfer Contact and maintaining appropriate records proving that such evidence was obtained. Further the Gaining Registrar also assumes the burden for ensuring that the entity making the request is indeed authorized to do so. The acceptable forms of physical identity are:
22.214.171.124 A transfer must not be allowed to proceed if no confirmation is received by the Gaining Registrar. The presumption in all cases will be that the Gaining Registrar has received and authenticated the transfer request made by a Transfer Contact.
2.2.1 Transmission of a "transfer" command constitutes a representation on the part of the Gaining Registrar that the requisite authorization has been obtained from the Transfer Contact listed in the authoritative Whois database.
2.2.2 The Gaining Registrar is responsible for validating the Registered Name Holder requests to transfer domain names between Registrars. However, this does not preclude the Registrar of Record from exercising its option to independently confirm the Registered Name Holder's intent to transfer its domain name to the Gaining Registrar in accordance with Section 3 of this policy.
126.96.36.199 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;
2.2.4 If the FOA expires pursuant to one of the aforementioned circumstances described in 2.2.3(a) – 2.2.3(c), 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.
Obligations of the Registrar of Record
3.1 A Registrar of Record shall confirm the intent of the Registered Name Holder when a notice of a pending transfer is received from the Registry by notifying the Registered Name Holder of the transfer. The Registrar of Record must do so in a manner consistent with the standards set forth in this agreement pertaining to Gaining Registrars.
3.2 In order to ensure that the form of the request employed by the Registrar of Record is substantially administrative and informative in nature and clearly provided to the Transfer Contact for the purpose of verifying the intent of the Transfer Contact, the Registrar of Record must use the FOA.
3.3 The FOA shall be communicated in English, and any dispute arising out of a transfer request, shall be conducted in the English language. Registrars may choose to communicate with the Transfer Contact in additional languages. However, the Registrar choosing to exercise such option is responsible for the accuracy and completeness of the translation into such additional non-English version of the FOA. Further, such non-English communications must follow the processes and procedures set forth in this policy. This includes but is not limited to the requirement that no Registrar shall add any additional information to the FOA used to obtain the consent of the Transfer Contact in the case of a transfer request.
In the event the Registered Name Holder preapproves a transfer, the Registrar of Record has the option of sending a modified version of the FOA, which informs the Registered Name Holder that the preapproved transfer has been initiated.
This requirement does not preclude the Registrar of Record from marketing to its existing customers through separate communications.
3.4 The FOA should be sent by the Registrar of Record to the Registered Name Holder as soon as operationally possible, but must be sent not later than twenty-four (24) hours after receiving the transfer request from the Registry Operator.
3.6 In the event that a Transfer Contact listed in the Whois has not confirmed their request to transfer with the Registrar of Record and the Registrar of Record has not explicitly denied the transfer request, the default action will be that the Registrar of Record must allow the transfer to proceed.
3.7 Upon denying a transfer request for any of the following reasons, the Registrar of Record must provide the Registered Name Holder and the potential Gaining Registrar with the reason for denial. The Registrar of Record may deny a transfer request only in the following specific instances:
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.
3.7.4 Express objection to the transfer by the authorized Transfer Contact. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact on an opt-in basis and upon request by the authorized Transfer Contact, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact to remove the lock within five (5) calendar days.
3.7.6 A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs). "Transferred" shall only mean that an inter-registrar transfer has occurred in accordance with the procedures of this policy.
3.10 The Registrar of Record has other mechanisms available to collect payment from the Registered Name Holder that are independent from the Transfer process. Hence, in the event of a dispute over payment, the Registrar of Record must not employ transfer processes as a mechanism to secure payment for services from a Registered Name Holder. Exceptions to this requirement are as follows:
4.1 Each Registrar is responsible for keeping copies of documentation, including the FOA and the Transfer Contacts response thereto, that may be required for filing and supporting a dispute under the dispute resolution policy. Gaining Registrars must maintain copies of the FOA as received from the Transfer Contact as per the standard document retention policies of the contracts. Copies of the reliable evidence of identity must be kept with the FOA.
4.2 Both the Gaining Registrar and the Registrar of Record must provide the evidence relied on for the transfer during and after the applicable inter-registrar domain name transaction(s). Such information must be provided when requested by, and only by, the other Registrar that is party to the transfer transaction. Additionally, ICANN, the Registry Operator, a court or authority with jurisdiction over the matter or a third party dispute resolution panel may also require such information within five (5) days of the request.
4.3 The Gaining Registrar must retain, and produce pursuant to a request by a Losing Registrar, a written or electronic copy of the FOA. In instances where the Registrar of Record has requested copies of the FOA, the Gaining Registrar must fulfill the Registrar of Record's request (including providing the attendant supporting documentation) within five (5) calendar days. Failure to provide this documentation within the time period specified is grounds for reversal by the Registry Operator or the Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with the requirements of this policy.
4.4 If either a Registrar of Record or a Gaining Registrar does not believe that a transfer request was handled in accordance with the provisions of this policy, then the Registrar may initiate a dispute resolution procedure as set forth in Section C of this policy.
4.6.1 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.
4.6.2 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 and will be recorded in, and protected by, the ICANN RADAR system. 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.
4.6.3 Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the Gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer.
4.6.4 The Losing Registrar will report failures to respond to a TEAC communication to ICANN Compliance and the registry operator. Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section 6 of this policy and may also result in further action by ICANN, up to and including non-renewal or termination of accreditation.
4.6.5 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. This documentation will be retained in accordance with Section 3.4 of the Registrar Accreditation Agreement (RAA). Users of the TEAC communication channel should report non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic tests of the Registrar TEAC communication channel in situations and a manner deemed appropriate to ensure that registrars are indeed responding to TEAC messages.
Requirements for the "ClientTransferProhibited" Status and "AuthInfo" Codes
Registrars may only set a domain name in "ClientTransferProhibited" status upon registration or subsequent request by the Registered Name Holder, provided, however, that the Registrar includes in its registration agreement (obtaining the express consent of the Registered Name Holder) the terms and conditions upon which it prohibits transfer of the domain name. Further, the Registrar must remove the "ClientTransferProhibited" status within five (5) calendar days of the Registered Name Holder's initial request if the Registrar does not provide facilities for the Registered Name Holder to remove the "ClientTransferProhibited" status.
5.2 Registrars must provide the Registered Name Holder with the unique "AuthInfo" code and remove the "ClientTransferProhibited" within five (5) calendar days of the Registered Name Holder's initial request if the Registrar does not provide facilities for the Registered Name Holder to generate and manage their own unique "AuthInfo" code and to remove the "ClientTransferProhibited" status.
5.3 Registrars may not employ any mechanism for complying with a Registered Name Holder'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 Registered Name Holder's contact or name server information.
5.4 The Registrar of Record must not refuse to remove the "ClientTransferProhibited" status or release an "AuthInfo Code" to the Registered Name Holder solely because there is a dispute between the Registered Name Holder and the Registrar over payment.
5.6 The "AuthInfo" codes must be used solely to identify a Registered Name Holder, whereas the FOAs still need to be used for authorization or confirmation of a transfer request, as described in Section 2 and Section 4 of this policy.
6.1 Upon receipt of the "transfer" command from the Gaining Registrar, Registry Operator will transmit an electronic notification to both Registrars. In the case of those Registries that use electronic mail notifications, the response notification may be sent to the unique email address established by each Registrar for the purpose of facilitating transfers.
6.3 When the Registry's database has been updated to reflect the change to the Gaining Registrar, Registry Operator will transmit an electronic notification to both Registrars. The notification may be sent to the unique email address established by each Registrar for the purpose of facilitating transfers or such other email address agreed to by the parties.
6.4 The Registry Operator shall undo a transfer if, after a transfer has occurred, the Registry Operator receives one of the notices as set forth below. In such case, the transfer will be reversed and the Registrar of Record field reset to its original state. The Registry Operator must undo the transfer within five (5) calendar days of receipt of the notice except in the case of a Registry dispute decision, in which case the Registry Operator must undo the transfer within fourteen calendar days unless a court action is filed. The notice required shall be one of the following:
Records of Registration
Each Registrar shall require its customer, the Registered Name Holder, to maintain its own records appropriate to document and prove the initial domain name registration date.
Effect on Term of Registration
The completion by Registry Operator of a holder-authorized transfer under this Part A shall result in a one-year extension of the existing registration, provided that in no event shall the total unexpired term of a registration exceed ten (10) years.
1.1 Transfer of the sponsorship of all the registrations sponsored by one Registrar as the result of (i) acquisition of that Registrar or its assets by another Registrar, or (ii) lack of accreditation of that Registrar or lack of its authorization with the Registry Operator, may be made according to the following procedure:
1.1.2 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.
1.2 Upon satisfaction of these two conditions, 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. 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.
Transfer Dispute Resolution Policy
Procedures for handling disputes concerning inter-registrar transfers are set forth in the Transfer Dispute Resolution Policy. Procedures in this policy must be followed by the applicable Registry Operators and ICANN accredited Registrars.
Inter-Registrant Transfer (Change of Registrant)
Availability of Change of Registrant
Change of Registrant Process
1.1.2 Obtain confirmation of the Change of Registrant request from the New Registrant, or a Designated Agent of the New Registrant. The Registrar must use a secure mechanism to confirm that the New Registrant and/or their respective Designated Agents have explicitly consented to the Change of Registrant;
1.1.3 Inform the Prior Registrant or its Designated Agent that if its final goal is to transfer the domain name to a different registrar, the Prior Registrant is advised to request the inter-registrar transfer before the Change of Registrant to avoid triggering the 60-day lock described in Section C.1.2;
1.1.4 Upon or after informing the Prior Registrant as described in 1.1.3 above, obtain confirmation of the Change of Registrant request from the Prior Registrant, or the Designated Agent of the Prior Registrant. The Registrar must use a secure mechanism to confirm that the Prior Registrant and/or their respective Designated Agents have explicitly consented to the Change of Registrant;1
188.8.131.52 inform the New Registrant and Prior Registrant that once the Change of Registrant is completed, the domain name will not be able to be transferred to a different registrar for 60 days (unless the Registrar gave the Prior Registrant the option to opt out of the 60-day lock, and the Prior Registrant opted out the 60-day lock);
184.108.40.206 include instructions on how to approve or cancel the Change of Registrant (example: URL) 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.7 Advise the Prior Registrant and New Registrant of the 60-day inter-registrar transfer lock as described in Section 3.3 or advise the Prior Registrant that it previously opted out of the 60-day inter-registrar transfer lock as described in Section C.1.2.
1.2 The Registrar must impose a 60-day inter-registrar transfer lock2 following a Change of Registrant, provided, however, that the Registrar may allow the Registered Name Holder to opt out of the 60-day inter-registrar transfer lock prior to any Change of Registrant request.
Introduction and Background: The IRTP Part C Policy Development Process (PDP) is the third in a series of five PDPs that address areas for improvements in the existing transfer policy.
The GNSO Council resolved at its meeting on 22 September 2012 to launch a PDP to address the following three issues:
- "Change of Control" function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security.
- Whether provisions on time-limiting Form Of Authorization (FOA)s should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold the FOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed.
- Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.
The IRTP Part C Working Group published its Initial Report [PDF, 1.23 MB] on 4 June 2012 in conjunction with the opening of a public comment forum (see section 6 for further details) followed by its Final Report [PDF, 624 KB] on 9 October 2012. The ICANN Board adopted the recommendations of the IRTP Part C Working Group on 20 December 2012. The Implementation Review Team in conjunction with ICANN staff worked together to develop a draft of the Transfer Policy. The draft policy was the subject of a public comment period.
All ICANN-accredited registrars are required to comply with policy by 1 August 2016.
Material Change: Paragraph 1.1(c) defines Material Change to mean a non-typographical correction. Registrars have some flexibility to determine what a Material Change is. Examples of typographical corrections could include:
(1) Changing the Registrant Name field from oJhn Smith to John Smith.
(2) Changing the Registrant Name field from Jane Kgan to Jane Kang.
(3) Changing the Registrant Organization from Example, Icn. to Example, Inc.
(4) Changing the Registrant Organization from ExampleCorp. to Example Corp.
For avoidance of doubt, nothing prevents the Registrar from treating any change to the Registrant Name or Registrant Organization field as a Material Change.
Secure Mechanism: The policy recommendations by the GNSO recognize that some flexibility is required in how registrars process a Change of Registrant. As a non-limiting example, Registrars may want to consider "out of band" authentication based on information that cannot be learned from within the registrar account or publicly available resources such as Whois. Examples may include, but are not limited to:
(1) sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar; or
(2) calling or sending an SMS to the Registered Name Holder's telephone number providing a unique code that must be returned in a manner designated by the Registrar; or
(3) calling the Registered Name Holder's telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the Registered Name Holder via web, email or postal mail.
1 The registrar may use additional contact information on file when obtaining confirmation from the Prior Registrant and is not limited to the publicly accessible Whois.
2 The Registrar may, but is not required to, impose restrictions on the removal of the lock described in Section 3.2. For example, the Registrar will only remove the lock after five business days have passed, the lock removal must be authorized via the Prior Registrant's affirmative response to email, etc.