It has taken a while, but this week ICANN finally adopted the changes to the gTLD transfer process that were proposed by the Registrar Stakeholder Group. This article covers the 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. At this moment, no changes to the ccTLD transfer processes are known.
ICANN is the organization responsible for coordinating the maintenance and procedures of all gTLDs. The current transfer policy of ICANN requires the gaining registrar to send an e-mail to the domain holder and/or administrative contact. Only after the domain contact affirmatively responded to this e-mail (by clicking a link), the transfer was requested at the registry. That has never been a problem, as the ICANN policies require every registry and registrar to publish this information in the whois database.
However, with the GDPR in mind, it is no longer allowed to do so: most of the whois information is personal data like name, address and e-mail address. As a result, before the 25th of May almost all gTLD registries and registrars will limit the whois output of their domains. No e-mail address is shown anymore by default. Because of that change, the transfer policy cannot be left unchanged: 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. Those changes still need to be approved by the ICANN board, but we’re 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 e-mail address of the current holder and/or administrative contact cannot be retrieved.
As a result, in many cases the transfer will be requested at the registry immediately (provided the authorization code is correct), skipping the required 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 he does not explicitly approve or reject, the transfer will be auto-approved after five days.
A big change compared to the current policy, is that the losing registrar may also reject a transfer within five days if he gets no affirmative response from the domain holder. In the current policy refusal of an outgoing transfer by the losing registrar was only possible in a few very strictly defined cases.
There are two risks related to this change:
- The procedure is not unambiguous anymore: because the disclosure of the e-mail address may differ per registry and registrar, some transfers will start with an e-mail 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 straight-forward 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 an e-mail is sent or not.
- Some registrars may implement an auto-reject policy: because the losing registrar may refuse an outgoing transfer if he gets no affirmative response from the domain holder, some registrars may use that rule to make outgoing domains more complex: they may demand affirmative response. This may lead to unwanted situations, because 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 a problem if your communication to the domain holder is clear.