What Is an EPP/Authorization Code, and Where Do You Find It?

When you try to move a domain to a new registrar, the very first thing it asks for is a mysterious string called the EPP code, auth code, authorization code, or transfer key. They are all the same thing: a password attached to your domain at the registry, and without it the transfer cannot start. This article explains what the code is, how it works under the hood, where to find it at your registrar, what to do when it is rejected or your registrar will not give it to you, and how to keep it from becoming a security hole. If you are planning the whole move, pair this with how to transfer a domain to another registrar without downtime.

What Is an EPP Code?

An EPP authorization code is a secret string associated with a domain in the registry's database. When a new registrar requests a transfer, it must present the correct code. The registry compares it with the stored value and rejects the request if it does not match.

The name comes from the Extensible Provisioning Protocol (EPP), the protocol registrars use to manage domains at registries (RFC 5730). The domain mapping, RFC 5731, defines an element called authInfo that holds this code. Registrars and the public call it many things:

Name you might see	Where it is common
EPP code / EPP key	Most gTLD registrars
Auth code / authorization code	Most registrars and ICANN documents
Transfer key / transfer secret	Some registrars and some ccTLDs
AuthInfo	Technical documentation, .de
Transfer Authorization Code (TAC)	ICANN's revised Transfer Policy terminology

Whatever the label, the purpose is identical: proving that the person requesting the transfer is authorized by the domain holder.

How the Code Works in a Transfer

The flow for a gTLD such as .com looks like this:

1. You remove the registrar lock at your current (losing) registrar.
2. You ask the losing registrar for the auth code, and it gives it to you.
3. You enter the code at the new (gaining) registrar.
4. The gaining registrar sends an EPP transfer request to the registry, including the code.
5. The registry checks the code. If it matches and no transfer-prohibited status is set, the domain enters pendingTransfer.
6. The losing registrar can approve or reject the transfer, and if it does neither, the registry approves it automatically after five days.

Here is the EPP command a gaining registrar sends in step 4, as defined in RFC 5731:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <transfer op="request">
      <domain:transfer xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:authInfo>
          <domain:pw>2fooBAR!x9Kq</domain:pw>
        </domain:authInfo>
      </domain:transfer>
    </transfer>
    <clTRID>XFR-20261026-0001</clTRID>
  </command>
</epp>

The domain:pw element carries your code. The period element adds a year to the registration as part of the transfer, which is why transfers usually extend your expiration date.

Two important details:

• The code alone is not enough. If clientTransferProhibited or serverTransferProhibited is set, the registry refuses the transfer even with a correct code. That is why registrar lock matters so much.
• The code is not public. It never appears in WHOIS or RDAP output. Only the sponsoring registrar (and the registry) knows it.

Where to Find Your EPP Code

Every registrar puts it somewhere slightly different, but the path is almost always similar:

1. Log in to the registrar account that holds the domain.
2. Open the domain list and select the domain.
3. Look for a section named Transfer, Transfer out, Sharing & Transfer, Domain settings, or Security.
4. Unlock the domain if required, then click Get authorization code, Get EPP code, or Send auth code.
5. The code is either shown on the screen or emailed to the registrant or account email.

Some registrars show the code immediately; others require you to confirm by email first, or add a waiting period as a fraud check. If you cannot find the option, search your registrar's help center for "auth code" or "transfer out."

If You Bought Through a Web Host or Reseller

If your domain came bundled with hosting or a website builder, the registrar of record is often a different company. The code is still requested through the company you pay, usually in its domain or billing section. To see who the actual registrar is:

curl -sL https://rdap.org/domain/example.com \
  | jq -r '.entities[] | select(.roles | index("registrar")) | .vcardArray[1][] | select(.[0]=="fn") | .[3]'

If an Agency or Former Employee Controls the Account

The code goes to whoever controls the registrar account, which is not always the person who owns the business. If a developer or agency registered the domain in its own account, ask it to either give you the code or move the domain into your own account at the same registrar first. If the registrant name is not yours, read who really owns your domain.

Country-Code TLDs

ccTLDs follow their own rules, so the "code" may look different:

• .uk: Nominet does not use an auth code for transfers between registrars. Instead, you ask your current registrar to change the domain's IPS tag to the new registrar's tag.
• .de: uses an AuthInfo code, generated by the current registrar on request.
• .eu, .ca, .au, and many others use an auth code, sometimes with additional eligibility checks.

Check the new registrar's transfer instructions for your specific TLD.

How Long Is an EPP Code Valid?

This varies. Under the rules many registrars have used for years, a code could stay valid until it was changed, and some registrars generated a fresh one each time you asked. ICANN's revised Transfer Policy moves gTLD registrars toward a stricter model for what it calls the Transfer Authorization Code (TAC): a code that is generated only on request, stored securely by the registry, used once, and valid for a limited time (14 days in the new rules). Implementation dates vary, so treat any code as short-lived:

• Request it only when you are ready to transfer.
• Use it promptly.
• If it is rejected, request a fresh one rather than reusing an old email.

Registrars must provide the code to the registrant within a set time after a request. Under the Transfer Policy that has long been five calendar days, and many registrars provide it instantly.

Why Your Code Might Be Rejected

Symptom	Likely cause	Fix
"Invalid authorization code"	Typo, extra spaces, or a code that has been regenerated or expired	Copy carefully or request a new code
Code works but transfer still refused	clientTransferProhibited or serverTransferProhibited still set	Unlock at the registrar, or resolve the server-level hold
Code accepted but transfer never completes	Losing registrar rejected it, or a confirmation email was missed	Check your email and the losing registrar's dashboard
Code characters look ambiguous	Characters like l, 1, O, 0 confused when typed by hand	Copy and paste instead of retyping
Special characters get mangled	Some forms trim or escape characters like & or quotes	Request a new code or contact the gaining registrar's support

Paste the code into a plain-text editor first if you suspect stray whitespace. Many failures are simply a trailing space from copying out of an email.

If the code is fine but the transfer is still blocked, see why you can't transfer your domain for a full list of transfer blocks, including the 60-day transfer lock.

What If Your Registrar Will Not Give You the Code?

For gTLDs, the registrant has a right to the auth code. ICANN's Transfer Policy limits the reasons a registrar may deny a transfer, and refusing to provide a code is not a valid way around that. If your registrar stalls:

1. Ask in writing through its support ticket system, and keep a record.
2. Check for legitimate blocks: an unpaid invoice for a previous period, an active UDRP case or court order, a recent registration or transfer, or a dispute over who the registrant is.
3. Escalate to ICANN Contractual Compliance if the registrar still refuses without a valid reason. ICANN has a dedicated transfer complaint form.

For ccTLDs, escalate to the relevant registry's complaint process instead.

Keeping Your EPP Code Secure

An auth code is effectively a password to your domain. Treat it like one:

• Keep the domain locked so a leaked code is useless on its own.
• Never email the code to anyone you have not verified. Phishing emails pretending to be registrars sometimes ask for it.
• Do not store codes in shared documents or tickets longer than needed.
• Protect your registrar account with two-factor authentication, because anyone who can log in can generate a new code.
• Regenerate the code after a transfer is cancelled, or if you think it was exposed.

If you are a developer building a registrar or reseller integration, generate codes with a cryptographically secure random generator, not a predictable function. This Python example produces a code that meets typical registry complexity rules (mixed case, digits, and a symbol):

import secrets
import string

def generate_auth_code(length: int = 16) -> str:
    """Generate a random EPP auth code with letters, digits, and symbols."""
    symbols = "!@#$%^*-_=+"
    alphabet = string.ascii_letters + string.digits + symbols
    while True:
        code = "".join(secrets.choice(alphabet) for _ in range(length))
        if (any(c.islower() for c in code)
                and any(c.isupper() for c in code)
                and any(c.isdigit() for c in code)
                and any(c in symbols for c in code)):
            return code

print(generate_auth_code())

Registries publish their own length and character rules, so check them before relying on a specific format.

---

EPP Code FAQ

Conclusion

The EPP authorization code is a simple idea with big consequences. It is a password stored at the registry and known only to your registrar, and presenting it is how a new registrar proves you authorized a transfer. You find it in your registrar's transfer or security settings, it may be emailed rather than displayed, and for some ccTLDs, like .uk, it is replaced by a different mechanism altogether.

Treat the code as sensitive and short-lived. Request it only when you are ready to move, use it quickly, and keep registrar lock on the rest of the time so a leaked code cannot be used on its own. If your registrar refuses to provide it for a gTLD domain without a valid reason, you have the right to escalate to ICANN.

Here are some useful references for going deeper on EPP and authorization codes:

1. RFC Editor: RFC 5731: EPP Domain Name Mapping — defines authInfo and the transfer command.
2. RFC Editor: RFC 5730: Extensible Provisioning Protocol — the base protocol registrars and registries use.
3. ICANN: Transfer Policy — registrar obligations to provide auth codes and the allowed reasons to deny a transfer.
4. ICANN: EPP Status Codes: What Do They Mean, and Why Should I Know? — how transfer locks interact with the code.