It has taken a while, but this week ICANN has finally adopted the changes to the gTLD transfer process that the Registrar Stakeholder Group proposed. This article covers the new transfer process of “generic” extensions or gTLDs: for example, .com, .net, .jobs, .cat, .london, .amsterdam, .email and .москва. To understand the changes, it’s important to know about the background.
This article explicitly does not cover “country code” extensions or ccTLDs (such as .nl, .be and .ru). At this moment, no changes to the ccTLD transfer processes are known.
Background of the transfer process change
ICANN is the organization responsible for coordinating the maintenance and procedures of all gTLDs. ICANN’s current transfer policy requires the gaining registrar to send an e-mail to the domain holder and/or administrative contact. Only after the domain contact has responded to this e-mail (by clicking a link), the transfer is requested at the registry. That has never been a problem. ICANN policies require every registry and registrar to publish this information in the Whois database.
However, with the GDPR in mind, registries and registrars are no longer allowed to do so. Most of the data in the Whois is personal, such as a name, address and email address. As a result, before the 25th of May, almost all gTLD registries and registrars will limit the Whois output of their domains. By default, the Whois will no longer show email addresses. Because of that change, ICANN has to change the transfer process, or domain transfers would not be possible anymore.
Initial transfer e-mail not always required anymore
As a result, ICANN has proposed changes to the transfer policy. The ICANN board still needs to approve these changes, but we are confident this will be the final plan for the short term.
The primary change is that the initial “Form of Authorization” (FOA, also called “transfer confirmation e-mail”) is no longer required if the email address of the current holder and/or administrative contact cannot be retrieved.
As a result, in many cases, registrants can request a transfer at the registry immediately (provided the authorization code is correct). Registries will therefore skip the e-mail approval by the domain contact. This will reduce the transfer time to a maximum of five days.
Note that, in all cases, the losing registrar will still send the notification about the outgoing transfer to the domain registrant. The registrant can still approve or reject the transfer. If they does not explicitly approve or reject the transfer, the system auto-approves the transfer after five days.
A big change compared to the current policy is that the losing registrar may also reject a transfer within five days. This is the case if they get no affirmative response from the domain holder. In the current policy, refusal of an outgoing transfer by the losing registrar was only possible in very few cases.
There are two risks related to this change:
- The procedure is not unambiguous anymore. Because the disclosure of the email address may differ per registry and registrar, some transfers will start with an email while others are immediately requested at the registry. This can even be different within a single TLD. For example one .com domain may require e-mail confirmation while the other .com domain does not. There is no straightforward overview of this. In case of doubt, check the transfer status in the domain details page in your control panel. That will always show whether the process involves an initial email or not.
- Some registrars may implement an auto-reject policy. A losing registrar may refuse an outgoing transfer if he gets no affirmative response from the domain holder. That’s why some registrars may use that rule to make outgoing domains more complex. They may demand an affirmative response, which may lead to an unwanted situation. After all, the current best practice is “ignore this second transfer e-mail – the transfer will be auto-approved after 5 days”. This issue may be less of a problem if your communication to the domain holder is clear.