Transferring a Domain Between Registrars: Auth Codes, Locks and Timing

Transferring a domain between registrars means moving who manages and bills your domain, and the process is governed by ICANN rules, not by any single company. In short: confirm the domain is eligible (not newly registered or recently transferred, and not locked), unlock it and turn off any privacy or registrar lock if needed, retrieve the authorization code (the EPP code, also now called a TAC or Transfer Authorization Code), start and pay for the transfer at the new (gaining) registrar, approve the confirmation email, and then wait. Most transfers complete in about five to seven days. Done carefully, your website and email keep running throughout, because transferring the registrar does not by itself change your DNS.

Step one: confirm the domain is eligible

Before anything else, check that the domain can legally be transferred right now. ICANN imposes lock periods to prevent fraud.

• The age rule. A domain cannot be transferred within 60 days of its initial registration or of a previous transfer. Historically this has been a flat 60-day lock. Under the ICANN Transfer Policy changes approved at ICANN82 and rolling out across registrars through 2026, the post-registration and post-transfer locks are moving to 30 days, and the old change-of-registrant lock is being removed. Because the rollout is staggered, assume 60 days unless your registrar states otherwise.
• Registrar lock. Separately from the age rule, most domains sit with a clientTransferProhibited status, a protective lock you control. You must turn this off before a transfer can start.
• Recent changes. Some registrars apply their own short lock after you update contact details, so make any WHOIS edits well before you plan to move.

You can read the current status from public WHOIS. The status codes tell you exactly what stands between you and a transfer.

$ whois example.com | grep -i "status\|expiry\|created"
Creation Date: 2019-04-12T08:00:00Z
Registry Expiry Date: 2027-04-12T08:00:00Z
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

Step two: unlock and retrieve the auth code

At your current (losing) registrar, do two things in the control panel.

1. Disable the registrar lock so the status changes from clientTransferProhibited to ok. If WHOIS privacy masks your contact email, turn privacy off temporarily too, because you must be able to receive approval mail.
2. Request the authorization code. This is the EPP code, auth code, AuthInfo, or TAC depending on the registrar's wording. It is a unique secret that proves you control the domain. Many registrars now email it or show it only briefly, and codes can expire, so retrieve it right before you start the transfer rather than days ahead.

Treat the auth code like a password. Anyone holding it plus access to the admin email could initiate a transfer.

Step three: start and pay at the gaining registrar

At the new registrar, begin an inbound transfer and paste in the auth code. A few things are standard here.

• You pay for the transfer, and for most gTLDs the fee includes a one-year renewal that is added on top of your existing expiry date, so you do not lose the time you already paid for.
• The gaining registrar validates the auth code against the registry. A wrong or expired code is the most common reason a transfer is rejected at this stage.
• Keep your WHOIS contact email reachable. The entire approval flow depends on email, so confirm the listed administrative address is one you can open today.

Step four: approve and wait out the window

Once the transfer is submitted, the confirmation and acknowledgment phase begins.

If you do nothing, many registrars will still auto-approve a valid transfer after the ICANN waiting period, but approving the confirmation email yourself is the fastest path. You can cancel a transfer in progress from the losing registrar if something looks wrong.

Keep your site and email alive during the move

This is the part people fear most, and it is avoidable. A registrar transfer changes who bills and manages the domain; it does not automatically change your DNS or wipe your records. The risk comes only if the two sides use different nameservers and your records do not follow.

1. Record everything first. Before you start, export or write down your full zone: A, AAAA, CNAME, MX, TXT (including SPF, DKIM, and DMARC), and any others. A screenshot is not enough; capture the exact values and TTLs.
2. Decide where DNS will live. If you keep the same nameservers (for example a dedicated DNS provider rather than the registrar's), nothing changes and your records are untouched. If DNS will move to the new registrar, recreate every record there before the transfer completes.
3. Lower TTLs ahead of time if you expect any nameserver change, so corrections propagate quickly. See the Valla DNS guide on TTL strategy for the exact timing.
4. Verify after cutover. Once the transfer completes, confirm each critical record still resolves, especially MX and the email authentication TXT records, so mail does not silently break.

Common reasons a transfer fails

• The domain is still inside the 60-day (or 30-day) post-registration or post-transfer lock.
• The registrar lock (clientTransferProhibited) was never turned off.
• The auth code was mistyped, expired, or regenerated after you copied it.
• The admin contact email is behind privacy or is an address you can no longer access, so the approval mail never gets actioned.
• The domain is too close to its expiry date; transfer well before expiry to avoid redemption complications.

Plan the DNS side of your transfer

A registrar move is mostly a timing and paperwork exercise, but the DNS side is where real outages happen. Before and after the move, watch each record roll out with the Valla DNS propagation checker so you can confirm your site and mail resolve correctly at every step. For the surrounding topics, see the guides in the Valla DNS learning hub on WHOIS lookups and pre-transfer checks, TTL strategy before a migration, and keeping SPF, DKIM, and DMARC intact.