How to Transfer a Domain Without Downtime or Losing Email

Most people who lose email during a domain transfer didn't lose it because of the transfer. They lost it because they treated the transfer and the DNS as the same event. They're not. A registrar transfer moves who bills and manages the domain. It does not, by itself, touch where your traffic and mail actually resolve—unless you let it.

That distinction is the whole game. Handle it correctly and you can transfer a domain without downtime or losing email, no matter how much revenue is riding on the name. Handle it carelessly and you get an afternoon of bounced mail and a support ticket you'll remember. This walkthrough covers the exact sequence operators use to keep the site up and the inbox flowing through a clean move.

Why transfers cause downtime (and why they usually shouldn't)

A domain has two layers that people conflate. The first is registration—the ownership and billing record held at your registrar and reflected in ICANN's system. The second is DNS—the set of nameservers and records that tell the internet where your website lives and where your MX (mail) records point.

When you transfer registration between registrars, the DNS can follow along, but it doesn't have to. Downtime happens in one of two ways:

• The gaining registrar resets your nameservers to its own defaults during the transfer, wiping the custom records you were relying on.
• Your DNS was hosted at the losing registrar, and once the domain leaves, that free DNS service stops answering—so your A records and MX records vanish.

Email is the more fragile of the two because mail delivery depends on MX records that many people forget even exist. Your website going dark is obvious in seconds. A missing MX record fails quietly, and by the time you notice, senders have already gotten bounce notices.

The safest transfers are boring. Nothing about the live configuration changes on the day the registration moves.

The core principle: separate DNS from registration first

The single most reliable way to avoid interruption is to decouple your DNS from the registrar before you initiate anything. If your DNS is hosted somewhere neutral—Cloudflare, your web host, a dedicated DNS provider—then the registrar transfer becomes a paperwork exercise. Ownership changes hands; resolution never flinches.

If your DNS currently lives at the losing registrar, move it out first and let it stabilize before you touch the transfer. This is the step most rushed operators skip, and it's the one that saves them.

Step 1: Document everything that's live right now

Before you change a thing, capture the current, working configuration. Export or screenshot every record:

• A and AAAA records pointing to your web server.
• CNAME records for subdomains, marketing tools, and verification.
• MX records—the priority values and hostnames for your mail provider.
• TXT records, including SPF, DKIM, and DMARC, plus any domain-verification strings.

Miss an SPF or DKIM record and your mail may still deliver—straight into spam folders. Treat this inventory as the source of truth you'll rebuild against.

Step 2: Stand up DNS at a neutral host

Point your domain's nameservers to a DNS provider that isn't tied to either registrar. Recreate every record from Step 1 exactly, then let the change propagate fully—give it up to 48 hours, though it's often much faster. Confirm the site loads and test-send email in and out. You want this new DNS setup proven before the registration moves, so the transfer has nothing to break.

Step 3: Lower your TTLs before the cutover

If you anticipate any record changes around the transfer, drop your TTL (time to live) values to 300 seconds a day or two ahead. Low TTLs mean that if you do need to correct something, the fix propagates in minutes instead of hours. Raise them back to normal once everything is stable.

Running the transfer itself

With DNS living safely off the registrar, the registration transfer is straightforward—and we've documented the mechanics end to end in our step-by-step registrar transfer walkthrough. The short version:

1. Confirm eligibility. A domain must be at least 60 days past registration or a prior transfer. If you just acquired the name, read why domains are locked for 60 days after purchase so the timing doesn't ambush you.
2. Unlock the domain at the losing registrar and disable any transfer prohibition.
3. Get your authorization code. This EPP key authenticates the move; our guide to authorization codes and EPP keys covers retrieving it cleanly.
4. Initiate at the gaining registrar and approve the confirmation email promptly to avoid delays.
5. Do not touch nameservers during or after the transfer. Because your DNS is hosted elsewhere, the nameserver values travel with the domain and keep answering the whole time.

When the gaining registrar asks whether to use its default DNS, decline. Keep your neutral nameservers in place. This one choice is what preserves both uptime and mail continuity.

Protecting email specifically

Email deserves its own checklist because its failure modes are quiet:

• Verify MX records survived the move immediately after the transfer completes—not tomorrow.
• Re-check SPF and DKIM. These authentication records are the difference between the inbox and the spam folder.
• Send a live test both directions. Mail yourself from an outside account and reply. Confirm delivery, not just that the server accepts the connection.
• Watch for 24 hours. Some senders cache old routing briefly. Monitoring for a full day catches stragglers.

If your mailbox provider is separate from your DNS host (say, Google Workspace or Microsoft 365 on a Cloudflare-managed domain), you're already in good shape—those services never knew or cared that the registrar changed, as long as the MX records stayed put.

What to do if something goes sideways

Even disciplined transfers occasionally stall—an unanswered confirmation email, a lingering lock, a registrar-of-record dispute. If yours hangs, work through our transfer troubleshooting checklist before escalating. A stuck registration transfer, notably, does not take your site or email down—because you already decoupled the DNS. That's the whole point of the sequence. The worst case becomes an administrative delay, not an outage.

It's also worth knowing what a transfer actually costs so the finance side holds no surprises; our breakdown of domain transfer costs and renewal fees lays out what operators really pay, including the renewal year most transfers tack on.

The operator's pre-flight checklist

1. Inventory every live DNS record, especially MX, SPF, and DKIM.
2. Move DNS to a neutral host and verify the site and email work there.
3. Lower TTLs a day or two ahead.
4. Confirm the domain is unlocked, past its 60-day lock, and armed with a valid auth code.
5. Initiate the transfer; decline the gaining registrar's default nameservers.
6. Post-transfer, re-verify DNS, test email both ways, and monitor for a day.
7. Restore normal TTLs once everything is stable.

Do this and the transfer becomes what it should be: invisible to your customers and your inbox. For the deeper strategic context—like why a well-structured name is worth protecting this carefully in the first place—see our take on premium versus cheap domains. And if you're still shaping the asset itself, our guide to choosing the right domain name pairs well with everything here.

For the authoritative rules governing inter-registrar transfers, ICANN's Transfer Policy is the primary reference worth bookmarking.

At PixelWorks Domains, every name we broker is treated as digital real estate worth moving carefully. If you're evaluating an acquisition and want the handoff handled cleanly—no downtime, no lost mail—browse our curated inventory or reach out about a specific name. We're happy to walk through the transfer path before you commit, so the asset is working for you from day one.