Transferring a domain between registrars, step by step

A registrar transfer moves who bills you and manages the domain. It does not, by itself, change who owns the name, where it points, or what is on the website. Done properly it takes five to seven days and causes no downtime. Done carelessly it takes your email offline for a day because nobody copied the DNS records across first.

Here is the whole process, in order, plus the things that actually go wrong.

Before you start: check the domain is eligible

Most failed transfers fail at this stage, before anything technical happens. Run these checks first.

• The 60-day rule. Under ICANN policy, a gTLD domain (.com, .net, .org, .io in practice, and most others) cannot be transferred within 60 days of initial registration, or within 60 days of a previous registrar transfer. There is no way around this. You wait.
• The 60-day change-of-registrant lock. If the registrant name, organisation or email address changed recently, many registrars apply a further 60-day lock. Some let you opt out of it at the time of the change. If you have just bought a domain and the seller pushed it to you via an account change, check whether this clock is running.
• Registrar lock status. Look up the domain in a public WHOIS/RDAP tool. If the status reads clientTransferProhibited, it is locked at your current registrar and you unlock it in their control panel. If it reads serverTransferProhibited, the registry has locked it, usually because of a dispute or a legal hold, and you need to resolve that first.
• Expiry date. Do not start a transfer in the last few days before expiry. If the domain expires mid-transfer you can end up in redemption with restoration fees. Renew first, or wait until after renewal, then transfer.
• Contact email. The admin contact email on the domain must be one you can actually read. Approval messages go there.

Step by step: the standard gTLD transfer

Assume a .com. The sequence is the same at almost every registrar, even if the buttons are named differently.

1. Copy your DNS records

Do this before anything else. Open the current registrar's DNS zone and write down every record: A, AAAA, CNAME, MX, TXT (including SPF, DKIM and any domain-verification strings), SRV, CAA. Screenshot the lot. If your DNS is hosted somewhere other than the registrar — Cloudflare, Route 53, your host — this step matters less, because you are only moving the nameserver delegation, not the records. Confirm which situation you are in.

2. Unlock the domain

In the current registrar's panel, find the domain and switch off the transfer lock. The WHOIS status should drop clientTransferProhibited within minutes.

3. Disable WHOIS privacy

Not always required now that registration data is largely redacted, but privacy services sometimes mask the admin email and block the approval message. Turn it off for the duration and turn it back on afterwards.

4. Get the authorisation code

Also called an EPP code, auth code, transfer key or, on some ccTLDs, an AuthInfo code. Request it in the current registrar's panel. It may appear on screen or arrive by email to the admin contact. Treat it like a password: anyone with it plus an unlocked domain can move the name.

5. Start the transfer at the new registrar

Enter the domain and the auth code, pay for the transfer. For most gTLDs the transfer price includes one extra year added to the existing expiry date, so you are not losing time — you are prepaying a renewal. That extra year is why a transfer is rarely free.

6. Approve it

The gaining registrar sends a confirmation to the admin contact. Click it. The losing registrar then usually sends its own message offering you the chance to approve immediately or to decline. If you approve at the losing registrar, the transfer completes in minutes to hours. If you ignore it, the transfer completes automatically after five calendar days.

7. Rebuild DNS and re-lock

Once the domain lands, check the nameservers. Compare live DNS against the records you saved. Then re-enable the registrar lock, re-enable privacy, set auto-renew, and confirm the contact details are correct.

How to transfer without downtime

The safest pattern is to decouple DNS from the registrar entirely, well ahead of the move.

• Point the domain at a third-party DNS provider a week before you transfer. Verify the site and email still work.
• Then transfer the registration. Because nameservers are unchanged, nothing breaks at any point.

If you cannot do that, the fallback is to recreate the full zone at the new registrar before the transfer completes, then update nameservers once it lands. Lower your TTLs to 300 seconds a day or two before, so propagation is fast if something needs fixing.

The record people forget is MX, followed by the TXT records that prove domain ownership to Google Workspace, Microsoft 365 and your email-sending platform. Lose those and email stops flowing while everything else looks fine.

Country-code domains work differently

ICANN's transfer policy covers gTLDs. ccTLD registries set their own rules, and some are not remotely similar.

• .uk uses an IPS tag. You ask your current registrar to change the tag to the new registrar's tag; there is no auth code and usually no fee, and the expiry date does not move.
• .de uses an AuthInfo code and a KK (Konnektivitätskoordination) process, typically completing within a day.
• .ca and .au have their own registrant-eligibility requirements; the gaining registrar must be able to satisfy them.
• .eu, .fr and others each have quirks around auth code validity windows — codes can expire in days.

Check the registry's own documentation before you assume the .com process applies.

What to do when a transfer is rejected

Rejections are rarely mysterious. The usual causes, in rough order of frequency:

• Domain still locked, or the lock was re-applied automatically.
• Wrong or expired auth code. Request a fresh one.
• Inside a 60-day window, either from registration or a prior transfer.
• Unpaid balance or a chargeback at the losing registrar.
• Admin email is stale, so the approval never arrived. Update contacts, wait out any resulting lock, retry.

A losing registrar may legitimately deny a transfer for the reasons ICANN lists — fraud, dispute, non-payment, recent transfer — but it may not deny one simply because you are leaving. If you believe a registrar is obstructing a valid transfer, ICANN operates a Transfer Complaint process.

Buying a domain? Transfer is the last step, not the first

If the transfer follows a purchase, the order of operations matters more than the mechanics. On a brokered or marketplace sale, funds and the domain both sit with escrow, so neither side moves first. The seller pushes the domain or supplies the auth code, the buyer confirms receipt, and only then is the money released. On Names.com the seller pays 15% commission on completion and the buyer pays nothing extra.

Two practical notes for buyers. First, expect a fresh 60-day lock after the transfer, so plan any subsequent move accordingly. Second, if you are still choosing between candidates, sort out the name before you worry about registrars — a keyword domain that describes what you sell or a category-defining name is worth far more thought than which control panel you end up in. Registrars are easy to change. The name is not.