The EPP Code (Auth Code) Explained: What It Is, How to Get One for a Domain, and the 2024 Transfer Authorization Code Shift

· Last reviewed · 16 min read

An EPP code, also called an auth code, is the password for a domain name. It is the secret string the current registrar holds for every domain, and you need it to move that domain from one registrar to another. Without the right code, an inter-registrar transfer cannot start.

The same string travels under a confusing pile of names: EPP code, auth code, Auth-Info code, transfer code, and, since the 2024 ICANN Transfer Policy, the Transfer Authorization Code or TAC. They describe the same idea with one important update to how long the code now lives.

This guide explains what the code is, what it looks like, how to get it, why a transfer still fails when the code is correct, and what changed in 2024. It is written for the case that matters to a buyer above all: you have acquired an aged or expired domain, and now you have to transfer it into your own account cleanly. SEO Domains operates the curated marketplace, a 220,000+ pre-screened catalogue from $100 entry-level aged domains through premium acquisitions, where that screened domain, and its auth code, come from.

What is an EPP code (auth code)?

An EPP code, or auth code, is a registrant-identifying secret that the current registrar holds for a domain name. It works as the domain’s transfer password: you must give it to a new registrar to prove you are authorised to move the domain there. ICANN requires an auth code for transferring a generic top-level domain between registrars.

ICANN, the body that coordinates the domain name system, defines the Auth-Code as a code created by the domain’s current registrar that helps identify the domain name holder. Its single job in everyday use is to authorise an inter-registrar transfer. A new registrar that receives the correct code treats it as proof the real holder approved the move.

Why the code exists

The code exists to stop domain theft. A domain is a valuable asset, and without a shared secret, anyone would be able to request a transfer of a name they do not own. The auth code closes that hole. Only the party who controls the domain at the current registrar can read the code, so only that party can hand it to a gaining registrar.

The name EPP comes from the Extensible Provisioning Protocol, the standard registrars and registries use to talk to each other about domains. The protocol is defined in RFC 5730, and the domain-specific rules, including the authorisation element, live in RFC 5731. The auth code is the human-facing piece of that machinery.

EPP code, auth code, Auth-Info, TAC: one thing, many names

EPP code, auth code, authorization code, Auth-Info code, transfer code, and Transfer Authorization Code (TAC) all name the same credential. The differences are vocabulary and era, not function. Registrars label the field differently, and the 2024 ICANN Transfer Policy introduced TAC as the current term for a code with a fixed lifetime.

The pile of names is the first thing that confuses buyers, because a registrar calls it one thing while a help article calls it another. The credential is identical. What changes is the label on the button and, after 2024, how long the code stays alive once issued.

Name you will seeWhere it appearsWhat it refers to
EPP codeHosting and registrar help pagesThe transfer secret, named after the EPP protocol that carries it
Auth code / authorization codeGoDaddy, ICANN, most US registrarsThe same transfer secret, plain-language name
Auth-Info code / AuthInfoThe EPP standard, RFC 5731The protocol field that stores the secret
Transfer code / secretOlder knowledge bases, name.comThe same secret, legacy phrasing
TAC (Transfer Authorization Code)ICANN 2024 Transfer Policy, current registrarsThe same secret, now with a maximum 14-day lifetime
Figure 1. Five labels, one credential. Wikipedia’s Auth-Code entry lists EPP code, authorization code, transfer code, and Auth-Info code as synonyms. The 2024 TAC is the same thing with a fixed time-to-live, covered in section 5.

Country-code domains are the exception

The synonym table holds for generic top-level domains such as .com, .net, and .org, where ICANN policy mandates an auth code in the transfer process. Country-code domains run their own registries and sometimes use a different mechanism. The .nz registry historically issued a Unique Domain Authentication Identifier, an eight-character code that expired after 30 days, before it adopted standard auth-code wording. The .uk registry uses an IPS tag, the identifier of the gaining registrar, in place of a per-domain password. If you transfer a ccTLD, read its registry rules, because the auth code is not universal.

What an EPP code looks like: format, length, and case

An EPP code is a string of letters, numbers, and sometimes special characters. Registrars publish different lengths: Namecheap describes a 6 to 16 character mix of letters and numbers, while registries on the CentralNic platform require 16 to 48 characters with mixed case, a digit, and a special character. Auth codes are case-sensitive, so an uppercase letter and its lowercase form are not interchangeable.

There is no single global format, which is why the code looks different from one registrar to the next. What is consistent is that the string is opaque, generated to be hard to guess, and tied to one domain. A code that protects a high-value domain is intentionally long and complex.

SourceLengthCharactersValidity
Namecheap KB6 to 16Letters and numbersUp to 30 days
CentralNic registries (via OpenSRS)16 to 48Upper and lower case, a digit, a special characterSet at the registry
Network Solutions KBCombination of letters and numbersCase-sensitiveProvided within 24 hours of request
ICANN 2024 TACRegistry-definedRegistry-defined, stored as a one-way hashNo more than 14 calendar days
Figure 2. Format and validity vary by registrar and registry. Length figures are quoted from each named source. The one constant is case sensitivity, which is the cause of a large share of failed code entries.

How the auth code fits into a domain transfer

In an inter-registrar transfer, the losing registrar issues the auth code, the holder passes it to the gaining registrar, and the gaining registrar submits it with the transfer request. The registry validates the code against the value stored in the EPP Auth-Info field. If it matches and the domain is unlocked, the transfer proceeds through a confirmation and a waiting period.

The auth code is one link in a defined chain. Understanding where it sits explains why a transfer can stall even when the code is right, which is the subject of section 7. The flow below is the standard inter-registrar sequence for a generic top-level domain.

STEP 1

The holder unlocks the domain at the losing registrar and requests the auth code. ICANN policy requires the registrar to provide it within 5 calendar days.

STEP 2

The holder starts the transfer at the gaining registrar and enters the auth code in the transfer form.

STEP 3

The gaining registrar submits the request and the code to the registry, which checks the code against the stored EPP Auth-Info value for that domain.

STEP 4

The transfer enters a confirmation and waiting window. Network Solutions reports a typical window of 5 to 7 days for a generic top-level domain.

STEP 5

The transfer completes and the domain now sits at the gaining registrar under the holder’s account.

Figure 3. The auth code is validated at step 3, against the EPP Auth-Info value the registry stores. The full sequence is documented in the inter-registrar domain transfer walkthrough.

The 2024 ICANN Transfer Policy and the new Transfer Authorization Code

The ICANN Transfer Policy that took effect on 19 November 2024 replaced the old static auth code with the Transfer Authorization Code, or TAC. The TAC is generated only when the holder requests it, and its time-to-live is capped at 14 calendar days. The registry stores it as a one-way hash, and it is meant for a single transfer. This tightens security around codes that sit unused in an inbox.

The change matters because the legacy model had a weakness. A static auth code was set once and stayed valid for a long time, routinely parked in an email or a control panel where it was exposed to a leak. The 2024 policy closes that window by making the code short-lived and on-demand.

Legacy static auth code

Set in advance and stored at the registrar. Remained valid for a long period, in cases up to 30 days or until changed. Convenient, but a stored secret is a standing risk if an inbox is compromised.

2024 Transfer Authorization Code (TAC)

Generated on demand, lives no more than 14 calendar days, stored at the registry as a one-way hash, and intended for a single transfer. A code that is requested but never used expires on its own.

Figure 4. The 2024 shift, attributed to the ICANN Transfer Policy Review and the policy effective 19 November 2024. The purpose of the 14-day cap is to enforce security around unused codes that the working group noted may sit in a registrant’s email.

One practical consequence runs through the rest of this guide: request the code when you are ready to act. A TAC pulled in advance can expire before you finish, and an expired code is the first thing to suspect when a transfer will not start. The behaviour ties closely to the ICANN’s 60-day transfer rule, which governs when a domain is eligible to move at all.

How to get your EPP or auth code, step by step

To get an auth code, log in to the current registrar, unlock the domain, and request or reveal the code from the domain’s management page. The exact wording differs by registrar, but the sequence is constant. The code is then emailed to the registrant or shown on screen. Copy it exactly, including case, and use it promptly before it expires.

The steps below are registrar-agnostic, with the common label variations noted. Every registrar puts these controls in its domain management area, even when the menu names differ.

  1. Log in to the current registrar and open the domain

    Sign in to the account that holds the domain and open its management page. This is the losing registrar, the one you are moving away from. On GoDaddy this is the Domain Portfolio; on Namecheap it is the Domain List.

    The mistake: trying to pull the code from the gaining registrar. The code always comes from the registrar that currently holds the domain, never the one you are moving to.

  2. Unlock the domain

    Turn off the registrar lock, sometimes labelled transfer lock or domain lock. A locked domain will not release a usable code path, because the lock is designed to block transfers. The lock and its status codes are explained in transfer locking and when to unlock.

    The mistake: requesting the code while the domain is still locked. You can end up with a code that the registry then refuses at validation because the transfer-prohibited status is still set.

  3. Request or reveal the auth code

    Find the option labelled auth code, EPP code, transfer code, or get authorization code, and request it. Network Solutions, as one example, emails the code to the registrant address within 24 hours. Other registrars display it on screen at once, and under the 2024 policy a TAC is generated fresh at this moment.

    The mistake: requesting the code far ahead of the transfer. A TAC lives no more than 14 calendar days, so an early request can expire before you act.

  4. Copy the code exactly

    Select the entire string and copy it with no leading or trailing spaces. Auth codes are case-sensitive, so preserve every uppercase and lowercase letter as shown. Pasting is safer than retyping, which is where character errors creep in.

    The mistake: retyping the code by hand or copying a trailing space. A single wrong character, or invisible whitespace, makes the gaining registrar reject the code as invalid.

  5. Enter it at the gaining registrar and submit

    Start the transfer at the registrar you are moving to, paste the code into the auth code field, and submit. The gaining registrar sends the code to the registry, which validates it. Confirm any approval emails promptly to avoid the request timing out.

    The mistake: ignoring the confirmation email. A large share of transfers stall not on the code but on an unconfirmed approval that quietly expires.

Figure 5. The five-step retrieval sequence, with the common error at each step. The full inter-registrar process around these steps is documented in the inter-registrar domain transfer walkthrough.

Why a transfer fails with the right code: locks and status codes

A correct auth code does not guarantee a transfer. The domain also has to be eligible. EPP status codes such as clientTransferProhibited and serverTransferProhibited block a transfer regardless of the code, and ICANN’s 60-day rules make a domain ineligible for a period after registration, a prior transfer, or a registrant change. The code is necessary, not sufficient.

This is the section the registrar help pages skip, and it is the one that saves a buyer the largest amount of time. When a transfer will not start, the reflex is to assume the code is wrong. As frequently, the code is fine and the domain is just not in a transferable state.

EPP status codes that block a transfer

EPP status codes are the flags the registry and registrar set on a domain to describe its state. Two of them stop a transfer outright, no matter how correct the auth code is. ICANN publishes the full list and what each one means.

  • clientTransferProhibited. Set by the registrar, this is the standard transfer lock. It is the flag you clear in step 2 of the retrieval sequence. While it is set, the registry rejects the transfer.
  • serverTransferProhibited. Set by the registry, this is a stronger hold, sometimes applied during a dispute or a security event. A registrant cannot clear it directly, and it overrides a valid code.
  • pendingTransfer. A transfer is already in progress. A second request, even with a fresh code, will not start until the first resolves or is cancelled.

The 60-day eligibility rules

Separate from status codes, ICANN’s Transfer Policy makes a domain ineligible to transfer for 60 days after certain events. The two that catch buyers first are a recent registration and a recent prior transfer. A newly registered or freshly transferred domain cannot move again for 60 days, no matter how valid the code. A change of registrant can trigger the same hold. The mechanics are covered in ICANN’s 60-day transfer rule.

Auth codes when you buy an aged or expired domain

When you acquire a previously owned domain, the auth code is the handover instrument. You receive the code from the seller or the marketplace and use it to transfer the aged domain into your own registrar account, where you control it. A clean handover means a valid code, an unlocked domain, and a name past its 60-day eligibility holds.

This is the context that registrar help pages never address, because they assume you already own the domain you are moving. An aged-domain buyer is in a different position: the domain arrives from someone else, and the auth code is how ownership control passes to you safely.

Where the code comes from in an acquisition

In a private sale, the seller pulls the auth code at their registrar and shares it with you, ideally through escrow so the code is released against payment. In an aftermarket or marketplace purchase, the platform manages the handover and supplies the code, or pushes the domain into an account it sets up. The order of operations for a private deal is documented in the post-transfer checklist for aged domains.

The risk in a sloppy handover is real. A seller who reuses a leaked static code, or a domain still inside a 60-day lock, turns a clean purchase into a stalled one. Sourcing from a screened marketplace removes that friction, because the inventory is verified and the transfer path is handled as part of the sale. Browse curated aged and expired domains, a 220,000+ screened catalogue from $100 entry-level names through premium acquisitions, with a clean transfer in, on the SEO Domains marketplace.

Common auth-code mistakes and how to fix them

The transfer problems that look like a broken auth code are a short, repeatable list. An expired code, a locked domain, a copy-paste error, a 60-day hold, and an unconfirmed approval email cover the bulk of failures. Each has a clear fix. Use this table as the scannable troubleshooting reference when a transfer will not start.

The left column is the symptom you see, the centre column is the cause, and the right column is the fix. Read together, they describe a clean transfer: a freshly generated code, pasted exactly, into an unlocked and eligible domain, with every confirmation answered.

SymptomLikely causeThe fix
Gaining registrar rejects the codeTrailing space or wrong case in the copied stringRecopy the full code, no stray spaces, preserve exact case
Code was valid yesterday, fails todayA TAC expired inside its 14-day windowGenerate a fresh code at the losing registrar and use it at once
Transfer will not start at allclientTransferProhibited lock still setUnlock the domain at the current registrar first
Transfer blocked despite an unlocked domainserverTransferProhibited set by the registryContact the registrar to identify and clear the registry hold
Eligible domain still cannot moveInside a 60-day post-registration or post-transfer holdWait out the 60-day window, then retry
Code requested but never arrivedSent to an outdated registrant emailUpdate the registrant contact, then request the code again
Transfer stalls after submitting the codeConfirmation or approval email left unansweredAnswer the approval email promptly before it expires
Registrar will not release the codeRequest not honoured within policy timeCite the 5-calendar-day ICANN rule and escalate
Figure 6. The auth-code troubleshooting checklist. Eight symptoms, their causes, and the fix for each. Note that the code itself is the cause in only two rows; the rest are locks, eligibility, and process. Deeper diagnosis lives in transfer failures: common causes and fixes.

EPP and auth code frequently asked questions

The questions buyers raise when they search for what an EPP code is, answered against ICANN policy and the registrar record.

Q1Where do I find my EPP code?

In the domain management area of your current registrar. Look for a field labelled auth code, EPP code, transfer code, or get authorization code, usually near the transfer or lock settings. The registrar either displays it on screen or emails it to the registrant address. A registrar like Network Solutions sends it within 24 hours, as its knowledge base documents.

Q2How long is an EPP code valid?

It depends on the registry and the era of the code. Namecheap describes legacy auth codes valid for up to 30 days. Under the 2024 ICANN Transfer Policy, a Transfer Authorization Code is generated on demand and lives no more than 14 calendar days. The safe practice is to generate the code right before you transfer and use it promptly.

Q3Who needs an EPP code?

Anyone moving a generic top-level domain such as .com, .net, or .org from one registrar to another. ICANN requires an auth code for the inter-registrar transfer of a gTLD. You do not need one to keep a domain where it is, only to move it. Country-code domains run their own registries and sometimes use a different mechanism.

Q4My auth code is correct but the transfer still fails. Why?

The domain is likely not eligible. An EPP status code such as clientTransferProhibited or serverTransferProhibited blocks the move regardless of the code, and ICANN’s 60-day rule makes a domain ineligible for a period after registration, a prior transfer, or a registrant change. Run a WHOIS or RDAP lookup, read the status line, and clear the lock before re-checking the code.

Q5Is the EPP code the same as the EPP protocol?

No. The EPP protocol is the full Extensible Provisioning Protocol that registrars and registries use to manage domains, defined in RFC 5730. The EPP code, or auth code, is one small piece of it: the Auth-Info value that authorises a transfer. The protocol itself is explained in the The EPP protocol explained guide.

A clean aged domain and its auth code: the SEO Domains marketplace

The auth code is the last step of an acquisition, and a clean one depends on everything before it: a verified domain, past its eligibility holds, handed over against payment. Sourcing from a screened catalogue removes the handover friction, because the inventory is vetted and the transfer in is part of the sale. SEO Domains operates that curated marketplace.

Why a clean handover starts at the source

A failed transfer is rarely a failure of the code. It is a failure of the domain’s state: a stale lock, a 60-day hold, a leaked static code, or a seller who is slow to release. Buying from a marketplace that verifies the domain and manages the transfer turns the auth code from a point of friction into a formality. The asset, an aged or expired domain with real inherited authority, is what you are paying for, and the clean transfer is how you take control of it.

What a screened acquisition gives you

A vetted purchase removes the parts of the auth-code process that go wrong:

  • A domain confirmed eligible to transfer, past its 60-day registration and transfer holds.
  • A clean, freshly issued auth code released as part of the sale, not a recycled static one.
  • A transfer path handled by the marketplace, so the code is a formality rather than a hurdle.
  • A screened backlink profile and authority history, so the asset is worth transferring in the first place.

The legitimate demand behind every auth-code search is control of a domain you have paid for. That is the product, an ownable aged or expired name with a clean transfer in, not a tool or a subscription. SEO Domains operates the curated marketplace where aged and expired domains are screened before they are listed, and where the handover, auth code included, is part of the deal.

Damyan Zagorski, Chief Commercial Officer at SEO Domains

Damyan Zagorski

Chief Commercial Officer @ SEO Domains

Damyan leads commercial strategy at SEO Domains, drawing on experience as a CEO and marketing director. He has driven the company’s branding, client growth, and revenue, helping establish it as a leading provider of aged domains for SEO.

He leads SEO at the SEO Domains marketplace, which operates a 220,000+ curated catalogue from $100 entry-level domains through premium acquisitions, screened across the catalogue, with ICANN-accredited transfer on every domain.

· Last reviewed