Transferring a domain between registrars, step by step

A registrar transfer changes who bills you and whose control panel you log into. It does not change who owns the name, where it points, or what visitors see. Do it properly and it takes five to seven days with nothing breaking. Do it carelessly and your email stops on a Tuesday afternoon because nobody wrote down the MX records.

The mechanics are dull. The failure modes are where the interest is.

Most transfers die before they start

Almost every failed transfer fails at the eligibility stage, long before anything technical happens. Five checks, in order.

• The 60-day rule. ICANN policy blocks a gTLD domain (.com, .net, .org, .io in practice, and most others) from transferring within 60 days of initial registration, or within 60 days of a previous registrar transfer. There is no workaround, no support ticket that helps. You wait.
• The 60-day change-of-registrant lock. Change the registrant name, organisation or email and many registrars apply a further 60-day lock. Some offer an opt-out at the moment of the change. If a seller just pushed a domain into your account, find out whether that clock is running before you make plans.
• Registrar lock status. Look the domain up in a public WHOIS/RDAP tool. clientTransferProhibited means your current registrar has it locked, and you can switch that off yourself. serverTransferProhibited means the registry did it, usually over a dispute or legal hold, and that has to be resolved first.
• Expiry date. Never start a transfer in the final days before expiry. A domain that expires mid-transfer can land in redemption, with restoration fees attached. Renew, then transfer.
• Contact email. The admin contact address has to be one you can actually open. Every approval message goes there.

The standard .com sequence, in order

Assume a .com. Button names differ between registrars; the order does not.

Write down your DNS before you touch anything

Open the current registrar's DNS zone and record everything: A, AAAA, CNAME, MX, TXT including SPF, DKIM and any domain-verification strings, SRV, CAA. Screenshot all of it. If your DNS lives somewhere else already, at Cloudflare, Route 53 or your host, this matters much less, because you are only moving the nameserver delegation and the records stay put. Work out which of those two situations you are in before you go further.

Unlock it

Find the domain in the current panel and switch off the transfer lock. clientTransferProhibited should disappear from WHOIS within minutes.

Turn privacy off, temporarily

Less often required now that registration data is largely redacted anyway. But privacy services sometimes mask the admin email and swallow the approval message, so switch it off for the duration and back on when you are done.

Request the authorisation code

EPP code, auth code, transfer key, AuthInfo code on some ccTLDs. Same thing. Request it from the current registrar; it either appears on screen or arrives by email to the admin contact. Treat it exactly like a password. Anyone holding it, with an unlocked domain, can move the name.

Start the transfer at the registrar you're moving to

Enter the domain, paste the code, pay. For most gTLDs the transfer price buys one extra year on top of your existing expiry date, so you are prepaying a renewal rather than losing time. That extra year is why transfers are rarely free.

Approve, twice if you're in a hurry

The gaining registrar emails the admin contact for confirmation. Click it. The losing registrar then typically sends its own message, offering the chance to approve now or decline. Approve there and the transfer finishes in minutes to hours. Ignore it and it completes automatically after five calendar days.

Rebuild and re-lock

When the domain lands, check the nameservers, then compare live DNS against the records you saved. Re-enable the registrar lock. Re-enable privacy. Set auto-renew. Confirm the contact details survived the trip.

The trick is to move DNS first, weeks earlier

The safest pattern separates DNS from the registrar entirely, well ahead of the move.

• Point the domain at a third-party DNS provider about a week before. Confirm site and email still work.
• Then transfer the registration. Nameservers never change, so nothing can break.

If that isn't available to you, recreate the full zone at the new registrar before the transfer completes, then swap nameservers once it lands. Drop your TTLs to 300 seconds a day or two beforehand so any fix propagates quickly instead of sitting stale for hours.

MX is the record people forget. Then the TXT records proving ownership to Google Workspace, Microsoft 365 and whatever platform sends your marketing mail. Lose those and email quietly stops while the website looks perfectly healthy, which is the worst kind of outage.

Country-code domains play by their own rules

ICANN's transfer policy applies to gTLDs. ccTLD registries write their own, and some bear no resemblance to the .com process at all.

• .uk runs on IPS tags. You ask your current registrar to change the tag to the new one. No auth code, usually no fee, and the expiry date stays where it is.
• .de uses an AuthInfo code and the KK (Konnektivitätskoordination) process, generally done inside a day.
• .ca and .au impose registrant-eligibility requirements, and the gaining registrar has to be able to satisfy them.
• .eu, .fr and others have quirks around how long an auth code stays valid. Some expire within days.

Read the registry's own documentation rather than assuming.

Rejections are boring, which is good news

Almost nothing about a failed transfer is mysterious. The usual causes, roughly in order of how often they turn up:

• Still locked, or the lock came back automatically.
• Wrong or expired auth code. Ask for a fresh one.
• Inside a 60-day window, from registration or a previous transfer.
• An unpaid balance or a chargeback sitting at the losing registrar.
• Stale admin email, so the approval message went nowhere. Update contacts, wait out whatever lock that triggers, try again.

A losing registrar may deny a transfer for the reasons ICANN sets out: fraud, dispute, non-payment, a recent transfer. It may not deny one because it would rather keep your business. If you think a registrar is obstructing a legitimate transfer, ICANN runs a Transfer Complaint process.

If you're buying, the transfer comes last

When a transfer follows a purchase, sequencing matters far more than the technical steps. On a brokered or marketplace sale, both funds and domain sit with escrow so neither party has to move first. The seller pushes the domain or hands over the auth code, the buyer confirms receipt, and the money releases after that. On Names.com the seller pays 15% commission on completion; the buyer pays nothing on top.

Two things buyers should plan for. A fresh 60-day lock lands after the transfer, so any onward move waits. And if you are still weighing up candidates, settle the name before you think about registrars at all: a keyword domain that says what you actually sell or a name that defines its category deserves far more of your attention than which control panel you end up staring at. Registrars are trivially easy to change. The name is not.