Skip to content

Guide · Domains

How to transfer a domain

A transfer is a fifteen-minute job that occasionally becomes a fortnight, and it is almost always the same three things that cause the difference. This is the long version, including the parts your current registrar would rather not walk you through.

Rendering of three name tiles reading .com, .io and .dev.com.com.io.io.dev.devMove a name inGains a year

What a transfer actually moves

A domain transfer changes which registrar manages the registration. That is all it changes. It does not move your website, your files, your email or your DNS records, and it does not by itself alter where the domain points. If your nameservers are unchanged through the process, visitors and mail see nothing at all.

This matters because most transfer horror stories are not about transfers. They are about somebody changing nameservers at the same time, discovering the new provider had no MX records for their mail, and blaming the transfer for a day of bounced email. Keep the two operations separate and the risk collapses.

Is the domain even eligible?

Registry policy blocks some transfers outright, and no registrar can override it. Check all of these before you start, because each one costs you days if you find out late.

  • Sixty days since registration. A newly registered domain cannot be transferred for sixty days. Same rule after a previous transfer.
  • Sixty days since a registrant change. Changing the registered owner’s name or email typically starts its own sixty-day lock. If you are cleaning up contact details, do the transfer first.
  • Not expired. Most registries will not transfer an expired domain, and once it enters redemption you are paying a redemption fee as well. Renew where it is, then move.
  • Not in dispute or on registry hold. A status like serverTransferProhibited is set by the registry, not the registrar, and has to be resolved with whoever set it.

You can check the current status yourself with a WHOIS or RDAP lookup. What you are looking for is the domain status field: clientTransferProhibited is the normal registrar lock and is yours to remove, while anything beginning with server is set at the registry level and is not.

Do the DNS work first

Before you touch anything, write down the current zone. Every A, AAAA, CNAME, MX, TXT, SRV and CAA record, with its value and its TTL. Two reasons: if you end up changing nameservers you will need to recreate them exactly, and if something breaks later you want to know what it looked like when it worked.

Pay particular attention to TXT records. SPF, DKIM and domain verification records for mail providers, analytics, payment processors and identity systems all live there, and they are the ones nobody remembers until something quietly stops authenticating a week later.

If you are changing nameservers too

Do it as a separate step, days before or days after the transfer, not at the same time. Lower the TTL on the records you will change to a few minutes at least a day in advance, make the change, verify, then put the TTL back. One variable at a time is the whole technique.

Getting the auth code

The auth code — also called an EPP code, authorisation code, transfer key or domain secret depending on whose interface you are in — is a one-time password for the domain. It proves to the registry that whoever is requesting the move controls the domain today.

  1. Sign in to your current registrar and find the domain’s settings. Turn off the transfer lock, which may be called registrar lock, domain lock or theft protection.
  2. Request the auth code. Some panels display it immediately; many email it to the registrant address on file, which is why that address needs to be one you can read.
  3. Check whether WHOIS privacy hides the registrant email. If confirmations are being sent to a privacy relay, make sure the relay actually forwards to you — or disable privacy for the duration of the transfer and turn it back on afterwards.
  4. Use the code promptly. Codes commonly expire, and a stale one produces a rejection message that rarely explains itself clearly.

Running the transfer

With the domain unlocked and the code in hand, start the transfer at the gaining registrar and pay the transfer price. With us that is the renewal rate of the extension, and it buys the year the transfer adds — you are not paying twice, and you do not lose the time remaining on the current registration.

The registry then emails the registered owner to confirm. Approve it. This is the single most common point of failure, and it fails silently: an unapproved transfer simply expires after its window and you are back where you started with a slightly confusing email trail.

Once approved, the losing registrar has up to five days to respond. If they explicitly approve, the transfer completes immediately; if they do nothing, it completes at the end of the window. In practice, most transfers finish within a week and many within forty-eight hours.

When it goes wrong

The registrar will not give you the code

Registrars are required to provide the auth code to the registered owner, and they may not hold a domain hostage. If yours is stalling, put the request in writing, reference the registry transfer policy, and escalate above first-line support. For generic extensions, ICANN operates a formal complaint process for transfer failures, and registrars respond to it much faster than to a support ticket.

The transfer is rejected without a clear reason

Work through the eligibility list again — the sixty-day rules catch people constantly, particularly after they have just tidied up the registrant contact. Then check the domain status via WHOIS or RDAP for a lock you did not know about, and confirm the auth code has not expired.

The confirmation email never arrives

Look at the registrant email address in the WHOIS record rather than the one you use to log in — they are frequently different, and the registry writes to the former. If it is an address nobody has read since 2019, you will need to update the registrant contact first, which restarts the sixty-day clock. Annoying, but better discovered now.

The post-transfer checklist

  • Confirm the new expiry date is a year later than the old one. That is the year you paid for.
  • Check every DNS record against the list you wrote down at the start, especially MX and TXT.
  • Send and receive a test email, and load the site over HTTPS from a network that has never seen it.
  • Turn auto-renew on, and confirm the billing email is one you read.
  • Re-enable WHOIS privacy if you disabled it. With us it is free, at registration and at every renewal.
  • Put the transfer lock back on. It is the cheapest theft protection there is.

Transferring away from us

The same way, in reverse, and deliberately without friction: unlock the domain in the panel and copy the auth code. There is no retention step, no phone call, no offer you have to decline twice and no artificial delay. If we cannot keep your business by being worth the money, we would rather you left quickly than stayed annoyed.

The only thing we cannot waive is the registry rule: a domain cannot be transferred within sixty days of being registered with us or of having been transferred in. That one is not ours to bend.