FAQ for Registrars
On 17 May 2018 the ICANN Board adopted a Temporary Specification for gTLD Registration Data. This page is under review and will be updated to address the Temporary Specification.
The Policy provides that registrars should maintain a unique and private email address for transfer issues. Will ICANN maintain a database of these addresses on its website? How will we know if these addresses change?
As these email addresses are only intended for use by the registry and other registrars to respond to transfer issues, they will not be made publicly available on ICANN's website. ICANN will provide registrars with a list of all such addresses, and the list will be updated periodically.
What form or email format should we use for denial of a transfer request?
There is no required form or email format for denying a transfer request. Communication with regard to denial of a transfer request can take place via the dedicated email channels or other methods as agreed on between registrars.
Are we allowed to charge fees to process transfer requests?
Yes. The Inter-Registrar Transfer Policy does not make any provisions with regard to the fees a registrar may charge its customers.
The new Form of Authorization (FOA) requires the Gaining Registrar to send the form to the current Administrative Contact or Registrant as listed in the Whois. As Whois formats vary, how do we obtain this information?
As a Gaining Registrar initiating a transfer, you will need to build a step into the process to obtain the Whois contacts from the correct source. It will be the responsibility of the Gaining Registrar to obtain a valid completed FOA before initiating the transfer.
Will ICANN be releasing a corresponding Whois output regulation to ease processing of transfers between registrars?
At the current time, there are no Whois output regulations related to the Inter-Registrar Transfer Policy. The policy is subject to review at 3, 6 and 12 months after implementation, and additional Whois regulations may be recommended based on these assessments of the policy's effectiveness.
When denying a transfer, can we apply a rejection reason to more than one domain name?
Yes. If the same circumstances apply to a group of domains, all of the domains may be incorporated into one reason for denial.
Are we allowed to deny a transfer request if we do not believe the Gaining Registrar has obtained the proper authorization?
No. Transmission of a "transfer" command constitutes a representation on the part of the Gaining Registrar that the requisite authorization has been obtained. You may choose to file a dispute against the Gaining Registrar if you believe they have not followed the policy.
Can the AuthInfo Code be used in place of the Form of Authorization (FOA)?
No. The Auth-Info Codes must be used solely to identify a name holder, whereas the FOA needs to be used for authorization or confirmation of a transfer request, as described in the Inter-Registrar Transfer Policy.
Do we have to communicate the reason every time we deny a transfer?
Yes. The Inter-Registrar Transfer Policy requires that you provide both the registered name holder and the potential gaining registrar with the reason for denial. See Section 3 for the list of specific instances in which a transfer request may be denied.
How do we file a dispute against another registrar who is not following the transfer policy?
You have two options, as follows:
- You may file a dispute against the registrar by contacting the applicable registry operator. Each registry operator has determined its own fees and supplemental rules. You and the other registrar will be asked to provide the applicable documentation to the registry for a decision. You then have the option of appealing the decision with a third-party dispute resolution service provider.
- You may file a dispute with a third-party dispute resolution service provider. Current providers for the Transfer Dispute Resolution Policy will always be listed at http://www.icann.org/dndr/tdrp/approved-providers.htm. Each provider determines its own fees and supplemental rules.