Inter-Registrar Transfers Security and Policy Checks

Inter-registrar transfers, the process by which domain name holders move their domain registrations from one accredited registrar to another, represent a fundamental aspect of competition, user autonomy, and market efficiency within the domain name system. This process, while appearing seamless to many registrants, is underpinned by a carefully defined policy and a robust set of technical and security checks. These measures are designed to protect registrants against hijacking, fraud, and administrative errors, while also ensuring that the rights and responsibilities of all stakeholders—registrants, registrars, and registries—are respected within ICANN’s contractual framework.

The policy foundation for inter-registrar transfers is codified primarily in the ICANN Transfer Policy, formerly known as the Inter-Registrar Transfer Policy (IRTP). This policy lays out the rules and procedures for transferring generic top-level domain (gTLD) names between registrars. The policy exists to ensure that registrants can exercise choice over their service providers without undue restriction, and that registrars do not engage in anti-competitive behavior or domain lock-in practices. At the same time, it provides safeguards to ensure that transfers are authorized and legitimate, particularly in an environment where domain names are valuable digital assets.

At the heart of the transfer process is the concept of the AuthInfo code, also known as the EPP authorization code or transfer code. This code is a unique password-like string associated with each domain name, and it acts as a shared secret between the registrant and the gaining registrar. To initiate a transfer, the registrant must provide this code to the gaining registrar, who then submits a transfer request through the registry’s Extensible Provisioning Protocol (EPP) interface. The registry verifies the code and, if it matches and no other restrictions apply, initiates a five-day pending transfer period. During this time, the losing registrar may contact the registrant to confirm the request or object if the transfer is unauthorized.

To mitigate unauthorized transfers, ICANN’s policy includes several layers of security. Domain names are often placed in a transfer lock state by default, requiring the registrant to log into their account and unlock the domain before a transfer can proceed. This adds a verification step to confirm that the registrant has control of the domain. Additionally, registrars are required to validate the identity of the person requesting the AuthInfo code, and the code must be provided in a secure and timely manner—generally within five calendar days of a legitimate request.

The Transfer Policy also sets clear conditions under which a transfer request may be denied. These include circumstances such as: the domain name being within 60 days of initial registration or a previous transfer, the domain being involved in a UDRP or court dispute, evidence of fraud or identity theft, or the domain being subject to a registrar lock applied by the registrant. These checks are designed to prevent rapid domain flips used in malicious activity or the exploitation of compromised registrar accounts.

Security concerns have prompted enhancements to transfer-related protocols over time. For example, the Registrar Transfer Dispute Resolution Policy (TDRP) allows registrars to challenge unauthorized or failed transfers through a formal process, and ICANN Contractual Compliance can intervene in cases where registrants allege that their rights have been violated. In parallel, working groups within ICANN’s policy development process have explored improvements to the transfer experience, including stronger identity verification methods and better communication requirements between registrars and registrants.

Domain hijacking—where an attacker fraudulently gains control of a domain and transfers it away—is a primary concern motivating these protections. In high-profile cases, attackers have obtained access to registrar accounts through compromised email credentials or social engineering and then used the inter-registrar transfer process to move domains to registrars in jurisdictions with weaker enforcement capabilities. Once a domain is transferred away, recovery can become difficult, especially if the attacker promptly resells or changes the registration data. To address this, registrars are encouraged to implement multi-factor authentication for account access, notify registrants of transfer attempts in real time, and monitor for unusual transfer activity.

The use of the Transfer Policy in practice is not without challenges. Registrants frequently report confusion about the transfer process, particularly the distinction between registrar transfers and changes in registrant contact data, which can also trigger confirmation emails under the IRTP-C rules introduced in 2016. These rules mandated explicit consent from both the old and new registrant when domain ownership changed, which in some cases led to delays or cancellations of legitimate transfers. Recognizing these operational frictions, ICANN’s GNSO Council launched the Transfer Policy Review PDP (Policy Development Process) in 2020 to simplify and modernize the transfer experience while maintaining security and trust.

Another evolving aspect of inter-registrar transfers concerns the role of WHOIS data, which has traditionally been used by registrars to validate ownership and contact details during a transfer. With the advent of the General Data Protection Regulation (GDPR) and the redaction of WHOIS data under ICANN’s Temporary Specification, registrars no longer have automatic access to registrant email addresses and other identifying information. This complicates the validation process and may open new vectors for abuse if authentication measures are not strengthened accordingly. As a result, the development of a standardized System for Standardized Access/Disclosure (SSAD) or other data-sharing mechanisms is closely watched for its implications on secure transfers.

Looking forward, technological innovation and policy refinement will continue to shape inter-registrar transfers. Blockchain-based domain systems, decentralized identifiers, and new gTLD operational models may all introduce variations in how domain control is asserted and transferred. However, the core principles—user empowerment, security, and competitive choice—will remain constant. ICANN, registries, and registrars must ensure that their systems and agreements evolve in tandem with emerging threats and user expectations.

In conclusion, inter-registrar transfers are far more than routine administrative procedures. They are central to the integrity of domain ownership, the competitiveness of the registrar marketplace, and the trustworthiness of the DNS. Security checks, policy safeguards, and dispute mechanisms are all critical elements in ensuring that transfers serve registrants and not malicious actors. As digital identities and assets become increasingly tied to domain names, the need for rigorous yet user-friendly transfer mechanisms will only grow. The challenge for TLD governance will be to maintain this balance at scale, across jurisdictions, and in the face of ongoing technological change.

Inter-registrar transfers, the process by which domain name holders move their domain registrations from one accredited registrar to another, represent a fundamental aspect of competition, user autonomy, and market efficiency within the domain name system. This process, while appearing seamless to many registrants, is underpinned by a carefully defined policy and a robust set of…