EPP Code: What It Is and How to Get It for a Transfer

In short

An EPP code, also called an auth code, AuthInfo code or transfer code, is a password your current registrar creates for one domain name. The new registrar needs it to request the transfer, and the registry checks it. If your registrar has no self-service option, it must give you the code and remove its transfer lock within 5 calendar days of your request. For generic TLDs it may refuse a transfer in the first 60 days after registration or after a previous transfer, and it must refuse one for 60 days after a change of registrant unless you opted out beforehand.

What an EPP code is

ICANN's registrant FAQ defines it: "An Auth-Code (also called an Authorization Code, AuthInfo Code, Auth-Info Code, or transfer code) is a code created by a registrar to help identify the domain name holder and prevent unauthorized transfers (also known as a registrant or registered name holder)." And "An Auth-Code is required for a domain holder to transfer a domain name from one registrar to another."

EPP is the Extensible Provisioning Protocol, which ICANN's glossary defines as "A protocol used for electronic communication between a registrar and a registry for provisioning (creating, amending, and removing) domain name registrations." In RFC 5731 the code is the authorization information of the domain: "Authorization information is associated with domain objects to facilitate transfer operations." ICANN's Transfer Policy calls it the AuthInfo code, one per domain name. The registry "MUST (1) verify that the "AuthInfo" code provided by the Gaining Registrar is valid in order to accept an inter-registrar transfer request", but the decision stays with the owner: "The Registered Name Holder is the only party that has the authority to approve or deny a transfer request to the Gaining Registrar."

How to get your EPP code

The code comes from the registrar that holds the name now, not from the new registrar and not from ICANN. To see which registrar that is, run a lookup; in ICANN's tool "The "Registrar" field shows you who your registrar is." The RDAP lookup page reads the same data.

"Your registrar may allow you, via an online interface tool, to generate and manage your own AuthInfo code. If not, you will need to contact your registrar directly to obtain it. Your registrar must provide you with the AuthInfo code within five (5) calendar days of your request." The policy text behind that answer covers the transfer lock too: registrars "must provide the Registered Name Holder with the unique "AuthInfo" code and remove the "ClientTransferProhibited" within five (5) calendar days" of your first request when they offer no self-service. A billing quarrel is no excuse, as the registrar "must not refuse to remove the "ClientTransferProhibited" status or release an "AuthInfo Code" to the Registered Name Holder solely because there is a dispute between the Registered Name Holder and the Registrar over payment." Registrars may charge for a transfer, but "a transfer cannot be denied due to non-payment of this transfer fee."

Treat the code like a password. RFC 9154 says "For authorization information to be secure, it MUST be generated using a secure random value." It also has the registrar give each code a lifetime: "the sponsoring registrar MUST inform the registrant of the TTL when the authorization information is provided to the registrant."

Domain transfer eligibility checker

Enter the dates from a WHOIS or RDAP lookup and paste the status lines. The checker applies the reasons for denial in ICANN's Transfer Policy to the day you pick and shows when the 60-day rules end. It runs in your browser and sends nothing.

Try:

Source: ICANN Transfer Policy (updated February 21, 2024), sections I.A.3.7 to I.A.3.9, I.A.5 and II.C.2, fetched September 27, 2026. Status codes as on the domain status codes page. Machine-readable: transfer-policy-20260927.json.

When a registrar may, must or may not refuse

Having the code does not settle everything: "The Registrar of Record may deny a transfer request only in the following specific instances:" The table lists those reasons, the cases in which the registrar must refuse, and examples of reasons it may not use. Every refusal comes with an explanation, since "the Registrar of Record must provide the Registered Name Holder and the potential Gaining Registrar with the reason for denial."

Rule	What it covers	Section
May refuse	Evidence of fraud	I.A.3.7.1
May refuse	A reasonable dispute over who the registrant is	I.A.3.7.2
May refuse	A past registration period left unpaid, after putting the name on Registrar Hold	I.A.3.7.3
May refuse	Your own objection or lock, which the registrar must let you lift within five calendar days	I.A.3.7.4
May refuse	Within 60 days of the creation date	I.A.3.7.5
May refuse	Within 60 days after a previous transfer	I.A.3.7.6
Must refuse	A pending UDRP case the registrar knows of	I.A.3.8.1
Must refuse	An order of a competent court	I.A.3.8.2
Must refuse	A pending dispute under the Transfer Dispute Resolution Policy	I.A.3.8.3
Must refuse	A URS case or URS suspension the registrar knows of	I.A.3.8.4
Must refuse	The 60-day lock after a change of registrant, unless you opted out before it	I.A.3.8.5
May not refuse	Nonpayment for a pending or future registration period	I.A.3.9.1
May not refuse	No response from you	I.A.3.9.2
May not refuse	A registrar lock you had no fair chance to lift before the request	I.A.3.9.3
May not refuse	Any time limit other than the three 60-day windows	I.A.3.9.4
May not refuse	Payment disputes between the registrar and its partners when you paid	I.A.3.9.5

Expiry alone does not count: "You have the right to transfer an expired domain. Registrars are not allowed to deny a transfer due to expiration or nonrenewal", as long as earlier periods were paid. A deleted name is different: "During the Redemption Grace Period, the registry must disable DNS resolution and prohibit attempted transfers of the registration." The domain lifecycle page has those dates.

The 60-day rules

The policy has three time limits of 60 days. A registrar may refuse when "The transfer was requested within 60 days of the creation date as shown in the registry RDDS record for the domain name." It may also refuse when "A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs)." Both allow a refusal without requiring one, and no other time limit is a valid reason.

The third binds the registrar: "The Registrar must impose a 60-day inter-registrar transfer lock following a Change of Registrant, provided, however, that the Registrar may allow the Registered Name Holder to opt out of the 60-day inter-registrar transfer lock prior to any Change of Registrant request." A new registrant email address is enough to start it, as the transfer domain ownership page explains, so move the name first and change the owner data after. If you only need a new web host, ICANN notes: "You may have the option to change web-hosting providers instead of registrars to avoid the inter-registrar transfer process (and lock) altogether."

TAC and 30 days: what ICANN adopted in 2026

These are the rules in force: "Contracted parties may implement this updated Policy beginning on 21 August 2024 and must implement no later than 21 August 2025." On June 7, 2026 the ICANN Board adopted a rewrite: "Resolved (2026.06.07.04), the Board adopts the Recommendations, and directs ICANN's President and CEO, or his designee(s), subject to prioritization, to implement the Recommendations". ICANN's scorecard of September 21, 2026 lists it as "Currently in the planning/resourcing process.", new policies come with "a window of at least six months for contracted parties to update their operations", and ICANN's transfers page lists no newer text, so nothing has changed yet.

For EPP codes, the rewrite "MUST use the term "Transfer Authorization Code" or "TAC" in place of the currently used term "AuthInfo Code" and related terms." Also, "The TAC MUST be valid for 336 hours from the time it is set at the Registry, enforced by the Registry." The windows after registration and after a transfer become required restrictions of 720 hours, or 30 days, and the lock after a change of registrant goes away. The checker shows both sets of dates.

EPP code: frequently asked questions

What is an EPP code?

A password your current registrar creates for one domain name, also called an auth code, AuthInfo code or transfer code. The new registrar needs it to request the transfer, and the registry checks it.

Where do I find my EPP code?

In your account at the registrar that holds the name, if it offers self-service. Otherwise ask that registrar, which must send it within 5 calendar days under ICANN's Transfer Policy. A WHOIS or RDAP lookup shows your registrar.

How long is an EPP code valid?

ICANN's current policy sets no fixed lifetime; under RFC 9154 your registrar sets one and tells you. The rules ICANN adopted on June 7, 2026, not in force yet, would make it 336 hours, or 14 days.

Why can't I transfer my domain for 60 days?

A registrar may refuse a transfer within 60 days of registration or of a previous transfer, and must refuse one for 60 days after a change of registrant unless you opted out beforehand. The checker gives the dates.

Can my registrar refuse to give me the EPP code?

Not over a payment dispute, and not by making it harder to get than a change of your contact details. It may refuse the transfer only for a reason listed in the policy and must tell you which; otherwise you can file a Transfer Complaint with ICANN.

Is the EPP code the same as a TAC?

Yes. Transfer Authorization Code is the new name in the recommendations ICANN adopted on June 7, 2026, which also make the code single-use and valid for 14 days. ICANN has not set a date for them yet.

Sources and method

ICANN Transfer Policy (updated 21 February 2024, required from 21 August 2025) and the ICANN domain name transfers page, fetched September 27, 2026.
ICANN FAQs for Registrants: Transferring Your Domain Name, ICANN Expired Registration Recovery Policy, ICANN EPP Status Codes and ICANN glossary (EPP), fetched September 27, 2026.
RFC 5731, RFC 3915 and RFC 9154.
Adopted, not in force: ICANN Board resolution 2026.06.07.04, ICANN policy scorecard of 21 September 2026, ICANN policy implementation page and the GNSO Transfer Policy Review Final Report, fetched September 27, 2026.
Method: the checker counts calendar days, and a 60-day window runs through the 60th day after its start. Status codes are read with the parser of the domain status codes page.
This page explains ICANN policy for general information. It is not legal advice; for a dispute, ask your registrar or a lawyer.