How to Transfer a Domain to a New Registrar Without Downtime

You want to move a domain from one registrar to another, and you have heard stories: the site went offline for a day, email bounced, or the transfer failed and nobody could say why. Or it has already happened, and since the transfer finished the domain shows DNS_PROBE_FINISHED_NXDOMAIN, a parked page, or mail returns Domain not found.

A registrar transfer only changes which company holds the registration on your behalf. Your website lives with your web host and your mailboxes with your email provider, and neither needs to change. Downtime happens when the DNS records lived at the old registrar as a bundled extra and were switched off when the domain left, or when nameservers or DNSSEC were changed carelessly along the way. Agencies consolidating client domains and owners leaving an expensive registrar run into this most often.

What is happening

People use “moving the domain” for three very different jobs. Be clear which one you are doing.

Job	What changes	Where you do it	Risk to site and mail
Registrar transfer	Who you pay for the registration and where you manage it	Start at the new registrar, approve at the old one	None, if DNS stays where it is
Nameserver change	Which DNS host answers for the domain	The registrar’s nameserver screen	High, if the new DNS host is missing records
Hosting move	Which server the website runs on	DNS records (A, AAAA, CNAME) at the DNS host	The site, during the cutover

For a generic domain such as .com, .net or .org, the transfer runs between registrars through the registry. You give the new (gaining) registrar an authorization code, often called the auth code, EPP code or transfer code. The gaining registrar submits the request. The old (losing) registrar has five calendar days to approve or refuse with a valid reason; if it does nothing, the registry completes the transfer automatically. Most gTLD transfers also add one year to the registration, which is why the new registrar charges for it.

Country code domains follow their registry’s own rules. A .uk domain, for example, moves by changing a registrar tag rather than with an auth code. Check your registry’s procedure if you hold a country code domain.

Before you start

You need logins for the old registrar, an account at the new registrar, and access to the email address listed as the registrant or admin contact. If the domain is a client’s, confirm the client owns the registrar account and agrees in writing.

Your backup is a full copy of the DNS zone (Step 2), the current nameservers and any DS record. Save them in a dated file.

How to run the commands. Everything here runs on your own computer. dig, whois and curl are built into macOS; on Linux install dnsutils or bind-utils plus whois; on Windows use WSL, or PowerShell’s Resolve-DnsName for DNS and ICANN’s web lookup at lookup.icann.org for the registration data. No server access is needed.

Step 1: Find out where your DNS lives

This single fact decides whether the transfer is risky.

dig +short NS example.com

example.com is your domain and +short prints only the answer. Read the provider name inside the nameserver hostnames:

• A third party DNS host (Cloudflare, your web host, a dedicated DNS service): the transfer does not touch your records. Nameservers carry over unchanged in a normal transfer. This is the safe case.
• The old registrar’s own nameservers: your records live in a service that is part of your registrar account. Many registrars remove that zone, or stop serving it, once the domain transfers out, and the records do not travel with the domain. This is where outages come from.

Step 2: Protect the DNS zone before anything else

If DNS is at the old registrar, move it to an independent DNS host first, as its own project, before you start the transfer.

1. Export the zone file from the old registrar, or build a full record list with dig (our Cloudflare migration guide shows how to audit a zone, including the DKIM selectors and SRV records that scans miss).
2. Create the zone at the new DNS host, which can be the new registrar’s DNS if you plan to use it, or anywhere else.
3. Compare the new zone with the old one record by record, by querying both sets of nameservers directly with dig @NAMESERVER.
4. Change the nameservers at the old registrar to the new DNS host.
5. Wait at least two days, so caches that still point at the old nameservers expire, then confirm site and mail work.

Only then begin the transfer. Two quiet changes in sequence are far safer than one big change. Many registrars also refuse nameserver changes while a transfer is pending, so you could be stuck with broken DNS for days if you do it the other way round.

Step 3: Check the transfer prerequisites

Most failed transfers fail on one of these. The rules below come from ICANN’s Transfer Policy for generic domains. ICANN has been revising this policy. The revised rules, once in force, are expected to shorten the locks after registration and after a transfer to 30 days and to drop the change of registrant lock, but registrars apply them only from ICANN’s effective date. Until your registrar confirms the new rules apply, plan around the ones below, and check ICANN’s Transfer Policy page and your registrar’s help pages before you start.

Read the domain status

whois example.com | grep -i -E "status|expir"
curl -sL https://rdap.org/domain/example.com | grep -o '"status":\[[^]]*\]'

The first line queries WHOIS and filters for status and expiry lines; -i ignores case and -E allows the | alternative. The second queries RDAP, the modern replacement for WHOIS, through the rdap.org redirector; -L follows the redirect to the right registry and -s hides progress. The grep pulls out the status list.

What the statuses mean:

• clientTransferProhibited (RDAP: “client transfer prohibited”): the registrar lock is on. You can usually turn it off yourself in the old registrar’s dashboard.
• serverTransferProhibited: the registry has locked it, often for a dispute or a recent change. Your registrar has to explain why.
• pendingTransfer: a transfer is already in progress.
• redemptionPeriod or pendingDelete: the domain has expired. Renew or restore it at the current registrar first; our domain expired guide covers this.
• ok or active with no prohibited statuses: ready to transfer.

The 60 day rules

• New registrations: a registrar may deny a transfer within 60 days of initial registration.
• Recent transfers: a registrar may deny a transfer within 60 days of a previous transfer.
• Change of registrant: a material change to the registrant’s name, organization or email triggers a 60 day transfer lock unless you opted out before the change, if your registrar offers that option. You cannot opt out once the lock is applied. ICANN’s own advice is to transfer first and update contact details afterward.

The auth code and the email address

Request the auth code from the old registrar’s dashboard. Some display it instantly, others email it to the registrant address. That address must work, and ideally it should not be a mailbox on the domain you are transferring, so that a DNS problem cannot lock you out of your own approval emails. The losing registrar typically also sends a notice to the registrant with a link to approve or reject the transfer early.

Codes are case sensitive and often include symbols. Copy and paste rather than retyping, and check for trailing spaces.

Expiry date

Do not leave the transfer until the last few days before expiry. If the domain expires while the transfer is pending, you can end up with a renewal at one registrar and a failed transfer at the other. Give yourself at least a couple of weeks.

Step 4: Handle DNSSEC

Check whether DNSSEC is active:

dig +short DS example.com

Any output means the registry has a DS record for the domain. Empty output means DNSSEC is off and you can move on.

What to do depends on whether your DNS host changes:

• Registration moves, DNS host stays the same: the DS record should remain valid, because the same DNS host keeps signing with the same keys. After the transfer, confirm the DS record is still present and matches. If the new registrar dropped it, add it again from your DNS host’s DNSSEC screen.
• DNS host changes too (for example DNS was bundled with the old registrar): remove the DS record before changing nameservers, wait for its TTL to pass (read it with dig DS example.com +noall +answer), move DNS, then enable DNSSEC at the new DNS host and add the new DS record at whichever registrar holds the domain at that point.

A DS record that points at keys nobody is signing with makes validating resolvers return SERVFAIL, and the domain looks dead to a large share of the internet. Check after every change:

dig +dnssec example.com A @1.1.1.1

This asks a validating public resolver and requests DNSSEC data. Good output shows status: NOERROR and the ad flag (authenticated data) in the flags line. status: SERVFAIL while dig +cd example.com A @1.1.1.1 (checking disabled) works means DNSSEC is broken: fix or remove the DS record.

Step 5: Run the transfer and know the timeline

1. Day 0: unlock the domain at the old registrar, get the auth code, and confirm the contact email works.
2. Day 0: start the transfer at the new registrar, paste the code, pay. Choose to keep the existing nameservers if asked. Some registrars offer to switch you to their default nameservers during checkout; decline unless your zone already exists there.
3. Days 0 to 5: the losing registrar may send an approval email. Approve it to finish early, or let the five day window run out.
4. Completion: the domain appears in the new registrar’s account. Status shows the new registrar in WHOIS or RDAP.

If the transfer is rejected, the new registrar shows a reason: a wrong code, the lock still on, a 60 day restriction, or a dispute. Fix that and start again; most registrars refund or let you retry.

Step 6: What to check after the transfer

dig +short NS example.com
dig +short DS example.com
dig +short MX example.com
dig +short example.com A

Run these on your computer and compare each answer with the note you made before the transfer. The NS list should be identical, unless you planned a change. The DS record should be present if DNSSEC was on. MX and A should return your mail provider and web server.

Then in the new registrar’s dashboard:

• Turn the transfer lock back on.
• Check the expiry date has moved forward and auto renew is set the way you want.
• Check the registrant, admin and technical contacts, and update them now if needed (a change of registrant may now lock the domain at the new registrar for 60 days, which does not matter if you plan to stay).
• Turn on WHOIS privacy if it was on before; it does not always carry over.
• Set up two factor authentication on the new registrar account.

Finally, send a test email to and from the domain and load the site in a private window. Our diagnostic tools can confirm records from outside your network.

Advanced: Recovering when records vanished after the transfer

If the site and mail died the moment the transfer completed, the cause is almost always that DNS was hosted at the losing registrar. Confirm it:

dig +trace example.com A

+trace follows the delegation from the root servers down without using caches. Look at the block from the TLD servers: those NS names are what the registry holds. Then look at the final block. If the old registrar’s nameservers answer with status: REFUSED, no answer at all, or a parking IP, the zone was removed from their side while the registry still points there.

The fix:

1. Rebuild the zone at a DNS host you control, using your saved zone file. If you have no copy, reconstruct it: the web host knows the server IP, the email provider’s admin console lists the MX, SPF, DKIM and verification records it needs, and Certificate Transparency search (crt.sh) lists subdomains that had certificates.
2. At the new registrar, change the nameservers to the new DNS host. Now that the transfer is done, nameserver changes are allowed.
3. If a DS record exists, remove it unless you have enabled DNSSEC at the new DNS host and are adding its matching DS.
4. Ask the old registrar whether the zone can be restored or exported; some keep deleted zones for a short time.
5. Expect recovery to take as long as the registry’s NS TTL for some visitors, often up to two days for .com, because resolvers cached the old delegation.

A related trap: some registrars set their own default nameservers during the transfer when the old nameservers belonged to the losing registrar. The result looks the same, a domain pointing at an empty zone, and the fix is the same.

When to contact your host

For a stuck or rejected transfer, open a ticket with the gaining registrar first; they can see the registry response. For broken DNS after a transfer, contact whoever hosts your DNS. Include:

• The domain, both registrars, and the UTC time the transfer was started and completed.
• The nameservers and DS record before and after (from your notes and the Step 6 commands).
• The RDAP or WHOIS status lines.
• Any rejection reason or email you received, with full text.
• For site or mail failures: the URL, a bounce message with headers, and the dig +trace output.

If your website host also hosts your DNS, tell them a registrar transfer happened, because they may need to re-add the domain on their side. If the site is down right now, the Emergency Room has a short checklist.