What is Auth code (EPP transfer code)? Definition and meaning
An auth code – also called an EPP transfer code, authorization code, or AuthInfo code – is a unique alphanumeric string generated by the registrar of record that a domain holder must supply to authorize the transfer of a domain name to a different registrar.
The auth code functions as a one-time password for domain transfers under the Extensible Provisioning Protocol (EPP), the technical standard that governs registrar-to-registrar communication for most gTLD domains. Without a matching code the gaining registrar cannot initiate a transfer, and the registry will reject the request. The code is typically case-sensitive, expires after a short window, and is issued by the losing registrar on the current registrant's request.
This page explains what an auth code is, what it is not, where it sits in the rules, how it plays out in practice, and why it matters in every domain acquisition, dispute, and brand-protection situation.
What does an auth code actually do?
The auth code is the technical gate that stands between a domain's current registrar and any gaining registrar. When a registrant decides to transfer a domain, the gaining registrar submits an EPP transfer command to the registry. That command must carry the auth code. The registry checks it against the value stored in the registration record. A match triggers the transfer process; a mismatch stops it entirely.
The mechanism was designed to prevent unauthorized outbound transfers – a category of domain theft that predates more sophisticated account-hijacking methods. Requiring a shared secret known only to the current registrant means that a third party cannot initiate a transfer without first obtaining either the code or control of the registrant's registrar account. In practice, auth code theft is a recognized step in domain hijacking, which is why the code should be treated with the same care as an account password.
What is an auth code NOT – and which term do people confuse it with?
The auth code is not the same as a registrar lock, a registry lock, or a domain transfer lock. These are status flags applied to a domain's registry record that prevent the EPP transfer command from being accepted at all – regardless of whether the correct auth code is supplied. A domain carrying a clientTransferProhibited or serverTransferProhibited status cannot be transferred even when the auth code is valid and correct.
The term most commonly confused with auth code is registrar lock. Both exist to prevent unauthorized transfers, but they operate at different layers. The lock is a status condition; the auth code is a credential. Lifting the lock is a prerequisite to using the auth code. Providing the code is a prerequisite to completing the transfer after the lock is lifted. In a domain acquisition, both steps must happen in the right order.
Auth code is also sometimes confused with the WHOIS/RDAP registrant ID or with a domain's administrative contact e-mail. Neither of those is the transfer credential. The administrative contact may receive a transfer approval e-mail from the registrar, but that approval is a separate confirmation layer, not the auth code itself.
Where does the auth code sit in the rules?
The authority for auth codes flows from ICANN's Inter-Registrar Transfer Policy (IRTP), which governs how accredited registrars handle domain transfers across the gTLD namespace – .com, .net, .org, and the hundreds of new gTLDs in the accredited pool. The IRTP requires the losing registrar to provide the auth code to the registrant on request, within a specified period, and prohibits the registrar from refusing to release it except in defined circumstances such as a pending UDRP dispute, an ongoing dispute lock, or a court order.
For most gTLDs the auth code is a registry-level requirement embedded in the registry-registrar agreement. Each registry defines its own technical specifications – length, character set, expiry window – but the function is universal across EPP-compliant zones. Some newer gTLDs impose additional verification steps, but the code remains the minimum credential.
ccTLD registries vary. Many operate their own transfer procedures that do not use EPP auth codes in the same way. The .uk zone, for instance, uses an IPS tag system managed by Nominet rather than an EPP auth code, and .de transfers through DENIC follow a different technical path. For any ccTLD, the governing national registry procedure determines how a transfer is authorized; do not assume that a gTLD auth code process applies.
How does the auth code appear in practice?
Three patterns account for most auth-code issues that arise in domain transactions and disputes.
Pattern 1 – Legitimate transfer during an acquisition. A buyer agrees to purchase a domain for a five-figure sum through a broker. The seller instructs the current registrar to release the auth code. The buyer's counsel verifies that the registrar lock has been lifted, confirms the code has not expired, and instructs the gaining registrar to submit the EPP transfer command. Escrow typically holds funds until the transfer completes and the domain appears in the buyer's account. Any delay in receiving the code – or a code that has already expired – is a warning sign that the seller may not have uncontested control of the account.
Pattern 2 – Auth code in a domain hijacking incident. A threat actor gains access to a registrant's account through a phishing e-mail or credential stuffing. The first step is usually to generate a new auth code, rendering the registrant's stored code invalid. The hijacker then initiates a transfer to a different registrar before the registrant notices. Recovery after this point requires rapid registrar escalation and, in most cases, engagement with the registry's dispute transfer process. The ICANN IRTP includes a "Registrar of Record Change Dispute" procedure, but the window to act is short and the outcome is not guaranteed.
Pattern 3 – Auth code and UDRP holds. A registrar may place a transfer lock on a domain once a UDRP complaint is filed. The auth code may still be technically valid, but the clientTransferProhibited status means no transfer can complete. This is by design: UDRP Paragraph 8 of the Rules prohibits the transfer of a domain under dispute without the panel's or the provider's consent. A registrant who attempts to transfer mid-proceeding – even with the correct auth code – risks a default finding on their non-cooperation. In our practice, we advise clients at the outset of any proceeding not to attempt a transfer until the case is resolved.
Why does the auth code matter in domain due diligence?
Receiving the auth code is not the final step in a domain acquisition – it is one mechanical step in a broader chain-of-title review. Before any transfer is initiated, due diligence should confirm that no UDRP complaint, URS proceeding, or court order is outstanding against the domain; that no registrar or registry lock is in place for a non-routine reason; that the selling registrant is the person or entity with authority to sell; and that no prior dispute history raises questions about the registration's legitimacy.
Many buyers assume that obtaining the auth code and completing the transfer clears all risk. It does not. A UDRP complainant who had already filed before the transfer can in some circumstances continue the proceeding against the new registrant, and a brand owner who did not file before the transfer may file against the buyer once the registration record updates. Pre-acquisition due diligence – including a UDRP history search and an RDAP registration-data review – is the only way to understand what arrives with the domain. The auth code confirms only that the current registrant is authorizing the transfer; it says nothing about whether that registration was legitimate to begin with.
For a full pre-acquisition due diligence review – including UDRP history, chain of title, and registrar lock status – contact info@cognomenlaw.com.
About COGNOMEN
COGNOMEN is an independent boutique focused exclusively on domain-name disputes. We recover, defend, and transact internet domains across generic and country-code zones, before WIPO, the Forum, CAC, ADNDRC, and national procedures, and in court where arbitration cannot reach. We act for brand owners, domain investors, and registrants – including respondent-side defense and reverse domain name hijacking. COGNOMEN focuses only on domain-name disputes – recovery, defense, and transactions – with coverage across every gTLD and ccTLD zone. To discuss a domain transaction or a dispute, contact info@cognomenlaw.com.
Related at COGNOMEN
Frequently asked questions
What is auth code (EPP transfer code)?
An auth code – also called an EPP transfer code or AuthInfo code – is a unique alphanumeric string that a domain's current registrar generates and provides to the registrant. The registrant supplies it to the gaining registrar when initiating a transfer to a different registrar. Without a matching code, the registry rejects the transfer command. The code is required under the ICANN Inter-Registrar Transfer Policy for gTLD domains and is case-sensitive and time-limited.
How is auth code (EPP transfer code) proven or established?
The auth code is generated by the losing registrar on the current registrant's authenticated request, typically through the registrar's account portal or by contacting registrar support. The registrant receives it by e-mail or in-account display. In a domain sale, the seller provides the code to the buyer (or directly to the buyer's gaining registrar) as the operative transfer credential. The code proves nothing about the legitimacy of the underlying registration – only that the account holder is authorizing the transfer.
Why does auth code (EPP transfer code) matter to my domain?
The auth code is the single technical control over whether your domain leaves your current registrar. If it is compromised – through account hijacking, phishing, or unauthorized disclosure – a transfer can be initiated without your knowledge. Conversely, if you cannot obtain it from your registrar (for example, because a dispute lock is in place), you cannot complete a legitimate sale or migration. Keeping the code confidential, confirming no transfer locks exist, and running pre-acquisition due diligence before any transaction are the three practical steps that protect domain value.
Author: Cordelia Roe — UDRP complainant practice & gTLD recovery; domain transactions and brand protection. Meet the team.
Speak with Cognomen Law
For a scoped view of your domain matter, contact info@cognomenlaw.com. Discuss your matter
This publication is general information and does not constitute legal advice. For advice on your situation, contact info@cognomenlaw.com.