How to Transfer a Domain to a New Registrar Without Downtime

Registrar, registry, and DNS are three different things

Your registrar is the company you buy the domain through. The registry is the authority for the whole TLD (Verisign for .com, for instance) and stores which nameservers are delegated to your domain. Your DNS host is whoever runs those nameservers and answers the actual A, MX, and TXT lookups. These are often the same company, but they do not have to be.

A registrar transfer changes the billing relationship and, at the registry, which registrar 'sponsors' the domain. It does not, by itself, change your DNS records. Downtime creeps in only when the nameserver delegation changes and the new nameservers don't yet have your records. So the entire game is: make sure whatever nameservers answer for your domain always hold a complete, correct copy of your zone.

There is one trap worth naming up front. Some registrars reset a domain's nameservers to their own defaults when a transfer completes. If that happens and you haven't replicated your zone there, your site and email vanish the instant the transfer lands. Knowing whether your gaining registrar does this is the single most important thing to check.

Lower TTLs and document your zone first

Start two or three days before you touch anything. Log into your current DNS host and drop the TTL on your critical records, A, AAAA, CNAME, and especially MX, to 300 seconds. TTL is how long resolvers cache a record, so a low TTL means that if you ever do change a record, the world picks up the new value in minutes instead of a day. You raise them back up once the dust settles.

Next, export or screenshot every record in the zone. Many providers let you export a standard zone file; if not, record each one by hand, name, type, value, priority, TTL. This is your master copy and your rollback plan. Miss a single MX or DKIM record here and email breaks in a way that is maddening to trace later. Our free DNS checker is a quick way to confirm what the world currently resolves for your domain so your export matches reality.

Decide what happens to DNS during the move

You have two clean paths. The safest is to leave DNS exactly where it is and only move the registrar. If you keep the same nameservers throughout, resolvers never see a change and there is zero DNS-related downtime. This works well when your DNS is hosted somewhere independent of the registrar (Cloudflare, Route 53, and so on).

The second path is moving DNS too, usually to the new registrar's nameservers. Here the rule is strict: build the complete zone at the new DNS host before you change the nameserver delegation. Recreate every record from your export, verify each one resolves when you query the new nameservers directly, and only then update the delegation. Because you already lowered TTLs, the cutover propagates fast, and because both old and new nameservers hold identical records, there is no window where a lookup returns nothing.

The diagram below shows why the order matters: a resolver walks from the root down to your authoritative nameservers, and if the delegation points somewhere that doesn't have your records yet, the answer is an outage.

Run the transfer itself

With DNS handled, the registrar transfer is mechanical. At your current registrar, unlock the domain (turn off the transfer lock / clientTransferProhibited), disable WHOIS privacy temporarily if the process requires it, and request the EPP or authorization code, a password that proves you own the domain.

Confirm the domain is eligible. ICANN imposes a 60-day lock after any new registration or a previous transfer, so a domain registered or moved within the last two months cannot be transferred yet. Also make sure the administrative contact email is one you can actually receive mail at, because that is where the approval link goes.

At the gaining registrar, start the transfer, pay (a transfer usually adds a year to the registration), and enter the auth code. Approve the request from the email that arrives, and if you want to skip the waiting period, look for an 'accept' or 'approve' option at your losing registrar to release it immediately. Otherwise ICANN rules let the transfer auto-complete in up to five days.

• Unlock the domain and disable the transfer lock
• Retrieve the EPP / authorization code
• Verify the admin contact email is reachable
• Confirm the domain is outside the 60-day post-registration/transfer lock
• Initiate at the new registrar, enter the code, and approve the email

Verify after the transfer lands

When the transfer completes, immediately check that the nameserver delegation is still what you expect, this is where the 'registrar reset my nameservers' trap springs if it is going to. Run a lookup against the domain and confirm the NS records and your critical A and MX records all resolve correctly. Then re-lock the domain, re-enable WHOIS privacy, and once you are confident, raise your TTLs back to their normal values.

The failure mode nobody plans for is silent: DNS answers correctly for weeks, then a delegation or a forgotten record quietly breaks and email starts bouncing before anyone notices. VigilDog monitors your domain, DNS, and DNS drift continuously and alerts you the moment a record changes unexpectedly or the domain's expiry creeps up, so a registrar move, or the renewal that follows it, never turns into a surprise outage. If you are unsure when the domain actually renews, our guide on when your domain expires covers how to read the dates.