Skip to main content

FAQ for Registrars

Pursuant to Appendix G of the Temporary Specification adopted on 17 May 2018, until such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered, if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, the Gaining Registrar is not required to obtain a Form of Authorization from the Transfer Contact. In this instance, the Registrant must independently re-enter Registration Data with the Gaining Registrar. In such instance, the Gaining Registrar is not REQUIRED to follow the Change of Registrant Process as provided in Section II.C. of the Transfer Policy.

The Temporary Specification does not modify the requirement for registrars of record, at Section I.A.3 of the Transfer Policy, to confirm the intent of the Registered Name Holder using the FOA when a notice of pending transfer is received.

The Transfer 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:

  1. 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.
  2. 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 Each provider determines its own fees and supplemental rules.
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."