Transfer Authorization Codes: AuthInfo and EPP Codes

By Bill Hartzer, domain name expert and expert witness·August 10, 2026

What the Code Is

The transfer authorization code — called the AuthInfo code, the EPP code or the auth code depending on who is writing the support article — is the per-domain shared secret that a gaining registrar must present to prove the registrant actually consented to a transfer. The losing registrar is the one you are moving away from; the gaining registrar is the one you are moving to. The code is the thing that connects them.

It exists because inter-registrar transfers have to work between competitors who do not trust each other and cannot verify each other's customers. Rather than build an identity system, the transfer process leans on a secret: whoever presents the correct code for a domain is treated as authorized to move it. That design is efficient, it is decades old, and it means the code is a bearer credential — the security of your domain is the security of a string.

How a Transfer Actually Runs

The mechanics are worth knowing in order, because most stuck transfers are stuck at a specific step:

The registrant asks the losing registrar for the code.
The registrar generates it and sets it on the domain object at the registry. Under the Transfer Policy, registrar-generated AuthInfo codes must be unique on a per-domain basis, and registrars must follow best practices in generating and updating them.
The registrant gives the code to the gaining registrar and initiates the transfer there.
The gaining registrar submits the request with the code, and the registry validates it against the value it holds.
If it matches, the domain enters pendingTransfer, which ICANN defines as a transfer request received and being processed.
On completion the domain enters transferPeriod, a grace period following a successful inter-registrar transfer.

Note where the check happens. The code is created by the registrar but stored and validated by the registry, which is why a code your registrar shows you can still be rejected if the registry holds a different value — usually because it was regenerated after you copied it.

That split runs through everything on this page, and it is worth naming early. In EPP, the Extensible Provisioning Protocol that registrars use to talk to registries, the registrar is the client and the registry is the server. RFC 5731 section 2.3 puts the rule plainly: "Status values that can be added or removed by a client are prefixed with 'client'. Corresponding status values that can be added or removed by a server are prefixed with 'server'." So clientTransferProhibited is your registrar's to clear, and serverTransferProhibited is not. The code proves consent to the registry; the prefix on the lock decides who is even allowed to ask.

It Is a Bearer Credential

Anyone holding the code, plus the ability to receive the confirmation email, can move your domain. That is the entire threat model, and it explains why the most common mistake is so ordinary: emailing the code. It travels in plaintext through an inbox that is often hosted on the domain being transferred, sits in a sent-items folder indefinitely, and is retained by whatever archiving system the company runs.

The second most common mistake is requesting a code "just in case" and leaving it live. Under the long-standing AuthInfo model a code sat on the domain object until someone changed it, so a code generated years ago for a transfer that never happened may still work today. It only takes one exported password vault, one departed contractor or one compromised support ticket for that to matter.

Treat the code the way you would treat a password with no expiry and no second factor. Generate it at the moment of transfer, move it over a channel that is not the registrant email address on the domain, and rotate it immediately if one was ever generated and not used.

The Five-Day Rule and the Grounds for Denial

Your registrar does not get to sit on the code. The ICANN Transfer Policy, current text dated 21 February 2024 and mandatory for registrars from 21 August 2025, requires the registrar to remove clientTransferProhibited or provide the authorization code within five calendar days of the holder's request. ICANN's registrant-facing explainer describes the same obligation as five business days; the discrepancy is in ICANN's own material, and the policy text is the one to cite.

The policy also sets out when a registrar may legitimately refuse a transfer: evidence of fraud; a dispute over the identity of the registered name holder; nonpayment for a previous registration period where the domain has expired; express written objection from the holder; and a request made within 60 days of registration or of a prior transfer. Those are the grounds. A registrar's preference to keep the business for another billing cycle is not among them.

Where a transfer is being refused on a disputed-identity or fraud ground, the matter has stopped being an administrative one, and counsel and the registrar-level dispute process are the appropriate route rather than another support ticket.

The Windows and Locks That Block a Valid Code

A correct code is necessary and nowhere near sufficient. Transfers with a valid code fail routinely because something else is set:

Registrar lock. A domain carrying clientTransferProhibited will have the transfer rejected by the registry no matter how good the code is.
Registry lock. serverTransferProhibited stops it as well, and here the code and the registrar are both irrelevant — RFC 5731 section 2.3 reserves server-prefixed statuses to the registry, so the registry has to clear it after out-of-band verification.
The 60-day windows. A registrar may deny a request within 60 days of registration or of a prior transfer, and a 60-day inter-registrar transfer lock follows a Change of Registrant, with opt-out available in advance at some registrars.
Expiry. A domain that lapses mid-transfer, or that sits in redemptionPeriod, is not going anywhere until the registration is restored.

Registry lock and the transfer code are not alternatives, and I see them treated as such often. The code proves consent. The lock decides whether consent is even considered.

What Is Changing, and What Is Not Yet in Force

The policy under which transfers operate today is the Transfer Policy text dated 21 February 2024, which registrars could implement from 21 August 2024 and had to comply with by 21 August 2025. It replaced a version effective from 1 December 2016. Its predecessor, the Inter-Registrar Transfer Policy, took effect on 12 November 2004.

A rewrite is in the pipeline. The Transfer Policy Review Policy Development Process working group delivered its final report to the GNSO Council on 5 February 2025; the Council adopted it on 12 March 2025 at ICANN82 and forwarded the recommendations to the ICANN Board on 31 March 2025, with formal submission on 10 April 2025. The Board opened public comment on 28 April 2025 and a comment summary was published on 2 July 2025.

What has not happened is Board adoption. The GNSO project page still records the Board resolution date as to be determined, with no implementation review team convened. Until that changes, nothing in the reviewed regime is policy, no effective date exists, and any specific figure circulating for the new code lifetime or the replacement lock period traces to trade-body explainers and trade press rather than to adopted ICANN policy text.

The direction of travel is nonetheless clear enough to plan around: rename the code the Transfer Authorization Code, generate it only when the registrant asks for it rather than automatically at registration, give it a fixed lifetime after which the registry will not accept it, impose a minimum complexity standard, and let either the registry or the registrar nullify it. That is a straightforward improvement on a permanent secret sitting in a database waiting to be stolen. It is also not in force, and anything you read that gives it a start date is ahead of the record.

Handling the Code Well

None of the good practice here is difficult. It is just rarely done.

Generate the code only at the moment you intend to transfer, and let it go stale afterward.
Move it over a channel that is not the registrant email address on the domain — an attacker who repoints DNS captures that mailbox too, which is the failure SSAC warned about in SAC044.
Rotate it immediately after an employee departure, a suspected account compromise, or any transfer that was started and abandoned.
Confirm after the transfer completes that the gaining registrar re-applied clientTransferProhibited, because it is not always automatic.
Never store the code in the same place as the registrar password, and never in the mailbox that receives registrar correspondence.

One more point that costs people domains. The confirmation emails in a transfer go to the contact data on the registration, so whoever controls that address effectively controls the transfer. Auditing where those messages land is worth more than any amount of care taken with the code itself.

Frequently Asked Questions

What is a domain transfer authorization code?

It is a per-domain shared secret, also called the AuthInfo code, EPP code or auth code, that the gaining registrar must present to prove the registrant consented to move the domain. Your current registrar generates it and sets it on the domain object at the registry; the registry stores it and validates the code when a transfer request arrives. Under the ICANN Transfer Policy these codes must be unique on a per-domain basis, and registrars must follow best practices in generating and updating them. If it matches, the domain enters pendingTransfer.

How do I get my auth code, and how long should it take?

You request it from your current registrar, usually through the control panel or a support ticket. Under the ICANN Transfer Policy the registrar must remove clientTransferProhibited or provide the authorization code within five calendar days of your request. ICANN's registrant explainer describes this as five business days; the policy text says calendar days, and that is the version to cite. If the registrar simply refuses without one of the policy's permitted denial grounds, ICANN Compliance is the escalation route.

How long does an auth code stay valid?

Under the policy in force there is no ICANN-wide expiry, which is precisely the problem. A code generated for a transfer that never happened can remain valid on the domain object indefinitely, so a string sitting in an old email or an exported password vault may still move the domain years later. Rotate any code that was generated and not used. The Transfer Policy Review recommendations would add a fixed lifetime, but the ICANN Board has not adopted them, so that is a proposal rather than a rule you can rely on today.

Is it safe to email my transfer code?

No, and it is the most common handling mistake there is. The code is a bearer credential: anyone who holds it and can receive the confirmation email can move the domain. Email leaves copies in the sender's sent folder, the recipient's inbox, and any archiving or backup system in between, often for years. It is worse when the mailbox is hosted on the domain being transferred, because an attacker who takes over DNS gets both the code and the confirmations. Use a channel unconnected to the domain, and rotate the code afterward.

My auth code is correct but the transfer keeps failing. Why?

A valid code is necessary, not sufficient. Check the status codes on the domain in RDAP or WHOIS. clientTransferProhibited will cause the registry to reject the transfer, and your registrar must clear it. serverTransferProhibited means a registry lock, which only the registry can lift after out-of-band verification. Beyond locks, a registrar may deny a request made within 60 days of registration or of a prior transfer, a 60-day lock follows a Change of Registrant, and a domain in redemptionPeriod cannot transfer at all. Also confirm the code was not regenerated after you copied it.

Does the auth code work on a registry-locked domain?

No. Registry lock sets serverTransferProhibited, and RFC 5731 section 2.3 reserves server-prefixed statuses to the registry — the registrar has no valid EPP command to clear one. The registry will refuse the transfer regardless of how correct the code is, until an authorized representative at the registrar goes through the registry's out-of-band verification, normally a callback and a pre-agreed security phrase. This is the intended behavior and the reason registry lock is worth its cost: a leaked code stops being sufficient to lose the domain.

What is the difference between AuthInfo, EPP code and TAC?

They are three names for the same thing. AuthInfo is the term used in the EPP specification and in the current ICANN Transfer Policy; EPP code and auth code are the informal names most registrar support pages use; Transfer Authorization Code, or TAC, is the name used in the Transfer Policy Review recommendations. Those recommendations were adopted by the GNSO Council in March 2025 and forwarded to the ICANN Board, but the Board resolution is still recorded as to be determined, so TAC is not yet a policy term in force.

Transfer Authorization Codes