What is a Registrar Transfer Authorization Code

Moving a domain from one registrar to another is usually painless, but almost every transfer depends on one small string of characters: the transfer authorization code. It is also called the EPP code, auth code, auth-info code or transfer secret. If you have ever been stuck halfway through a transfer, the cause was very likely this code, a registrar lock, or a timing rule you did not know existed. This guide explains what the code is, where it comes from, how the transfer process actually works under ICANN rules, and how to solve the problems people run into most often.

What the authorization code actually is

Domain registries for most generic top-level domains (gTLDs) such as .com, .net, .org and the newer extensions run on the Extensible Provisioning Protocol (EPP). In EPP every domain object carries an authInfo value: a secret, usually random string that only the current registrar and the registrant should know. When a new registrar requests a transfer, it must submit that value to the registry. If the value matches, the registry accepts the transfer request; if not, the request is rejected immediately.

In practice the code works like a password for the domain itself, not for your account. Anyone who has it, and whose domain is unlocked, can start a transfer. That is why you should treat it like a credential:

• Do not paste it into email threads, chat groups or support tickets you do not control.
• Request it only when you are ready to transfer, and ask your registrar to regenerate it if it has been exposed.
• Keep the registrar lock on whenever you are not actively moving the domain.

How to obtain your EPP code

Most registrars let you generate or reveal the code from the domain management screen, often under a section called “Transfer”, “Auth code” or “Domain security”. Some email it to the registrant contact instead of showing it on screen. For gTLDs, the ICANN Transfer Policy says the registrar must provide the code to the registered name holder within five calendar days of a request and may not use it as leverage, for example by refusing to release it until you pay for an unrelated service.

Before you request it

• Check the registrant email. If the code or confirmation messages go to an old address, update it first, keeping in mind that a registrant change can trigger a lock (see below).
• Check expiry. A domain close to expiry is fine to transfer, but one that has already expired and entered redemption cannot be transferred until it is restored.
• Check the status codes. A quick lookup with the TLDix WHOIS/RDAP tool shows statuses such as clientTransferProhibited, serverTransferProhibited or pendingDelete, so you know in advance whether the transfer can work.

The transfer process step by step

For a typical gTLD, an inter-registrar transfer follows the same sequence regardless of which companies are involved:

1. Unlock the domain at the current (losing) registrar, which removes clientTransferProhibited.
2. Get the authorization code from the losing registrar.
3. Start the transfer at the new (gaining) registrar by entering the domain name and code, and pay for the transfer. For most gTLDs this adds one year to the registration, subject to the 10-year maximum.
4. Confirm if asked. Depending on the registrar and the policy version in force, you may receive a confirmation email or simply a notification that a transfer is under way.
5. Wait for completion. The losing registrar has five days to approve or deny the request on permitted grounds. If it does nothing, the registry approves the transfer automatically at the end of that window.
6. Verify DNS and renewal settings at the new registrar once the transfer is complete.

Nameservers normally stay the same during a transfer, so a website does not have to go offline. Problems tend to appear when DNS is hosted by the old registrar and that DNS service ends with the transfer. Copy your zone records to the new provider before you start.

The 60-day locks and other timing rules

Several waiting periods exist to reduce hijacking and fraud. The most important ones for gTLDs are summarized below.

We cover the lock statuses and how to read them in more detail in our domain transfer lock guide.

What the ICANN Transfer Policy says

All ICANN-accredited registrars must follow the Transfer Policy for gTLD domains. Among other things, it defines the limited reasons a losing registrar may deny a transfer: evidence of fraud, a pending dispute, a court order, an unclear identity of the registrant, non-payment for a previous term, the 60-day windows above, or an explicit objection from the registrant. A registrar cannot refuse simply because it would like to keep the customer.

The policy also gives registrants a dispute route if a transfer happened without consent or was wrongly refused: first through the registrars involved, then through the registry’s Transfer Dispute Resolution Policy process, and finally ICANN Compliance if a registrar ignores its obligations. ICANN has been reviewing and revising the Transfer Policy, including terminology and the handling of auth codes and locks, so some details such as confirmation emails and lock lengths may change as new versions take effect. Always check your registrar’s current documentation.

How ccTLDs handle transfers differently

Country-code TLDs are run by national registries that set their own rules, and the ICANN Transfer Policy does not bind them. A few examples show how varied this can be:

• .uk: Nominet does not use an auth code for registrar moves. Instead you ask the new registrar for its IPS tag and have the current registrar change the tag.
• .de: DENIC uses an AuthInfo code, which the registrar generates on request and which has a limited validity.
• .eu: EURid uses an authorization code obtained from the current registrar.
• .tr: since the move to the TRABIS system, transfers between registrars follow TRABIS procedures, which may include verification steps specific to Turkish domains.

Some ccTLDs do not add a year on transfer, some have no 60-day restriction, and some require extra identity checks. Read the registry rules before assuming a .com workflow applies.

Troubleshooting common transfer problems

“Invalid authorization code”

Copy the code again without leading or trailing spaces, watch for confusable characters such as 0 and O, and make sure it has not been regenerated since you received it. Codes can also expire at some registries.

Transfer rejected immediately

The domain is usually still locked, or a server-side status is set. Run a fresh lookup to see the current statuses, because some registrars take a while to push the unlock to the registry.

No confirmation email arrives

Privacy redaction means the gaining registrar often cannot see your email address. Follow the registrar’s instructions, check spam folders, and confirm that the registrant email at the losing registrar is current.

Transfer stuck as pending

Wait the full five-day window. If it is still pending afterwards, contact the gaining registrar with the domain name and the transfer request date.

Keeping control after the transfer

Once the domain arrives, turn the registrar lock back on, enable two-factor authentication on the new account, and check that auto-renew and payment details are correct. A new registrar also means new renewal dates and prices to remember. Adding the domain to the TLDix domain panel keeps the expiry date, registrar and status visible next to your SSL certificates and hosting renewals, so a successful transfer is not followed by an accidental expiry.