DNS Migration: Moving Your Domain to Cloudflare Without Breaking Email

A DNS migration sounds like a website task, but the thing it breaks most often is email. Your domain's DNS zone holds the records that tell the world where your mail goes, which servers are allowed to send as you, and how to verify your signatures. Move the zone and miss one of those records, and messages start bouncing or landing in spam, often without anyone noticing for days.

We moved our own domains to Cloudflare and do the same for clients running Microsoft 365, Google Workspace, marketing platforms and form senders side by side. The move itself is not hard. What makes it safe is the preparation: a complete inventory, a plan for DNSSEC, and a deliberate check of email after the switch. This guide walks through the full process.

What actually changes in a DNS migration

When you move DNS to Cloudflare, you are changing which nameservers answer questions about your domain. Your registrar (where you bought the domain) keeps a pointer to those nameservers. Today it points at your current DNS provider, which might be your registrar itself, your web host or a service like Route 53. After the migration it points at the two nameservers Cloudflare assigns you.

Your website, mailboxes and apps stay where they are. The critical requirement: every record that exists today has to exist in Cloudflare, with the same values, before you change the nameservers. If it does, the switch is invisible. If it does not, whatever depended on the missing record stops working.

Step 1: Inventory every record

Cloudflare offers to scan your existing DNS and import what it finds when you add a domain. Use it, but do not trust it as your inventory. Cloudflare's own documentation says the scan is not guaranteed to find everything and tells you to review apex records, subdomains and email records yourself. DNS does not provide a way to list every name in a zone from the outside, so a scanner can only check names it guesses.

The reliable approach is to get the full list from the source. Most DNS providers let you export a zone file or at least view every record in one table. Copy all of it. Then check it against this list, because these are the records that cause trouble when they go missing.

Mail routing

• MX records for the root domain and any subdomains that receive mail. For Google Workspace this is typically a single record pointing at smtp.google.com. For Microsoft 365, use the exact value shown in your admin center, since Microsoft's MX hostnames vary by tenant.
• Any A records that MX records point at, if you run your own mail server or a mail filtering service.

Sender authentication (TXT and CNAME)

• SPF: the TXT record at the root starting with v=spf1. There must be only one.
• DKIM: one record per sending service, at a name like selector._domainkey. Microsoft 365 uses CNAMEs at selector1._domainkey and selector2._domainkey. Google Workspace uses a TXT record, by default at google._domainkey. Marketing platforms, CRMs and transactional senders each add their own.
• DMARC: the TXT record at _dmarc.
• Records on sending subdomains. If your marketing platform or form sender uses a subdomain such as mail. or forms., it has its own SPF, DKIM and sometimes MX records.

Our SPF, DKIM and DMARC guide explains what each of these does if you want the background.

Verification and service records

• Domain verification TXT records for Google Search Console, Microsoft 365, Meta, Apple, Atlassian, Stripe and similar services. Delete one and the service may quietly flag your domain as unverified.
• Microsoft 365 records such as the autodiscover CNAME, and any SRV records for older Teams or Skype setups.
• CAA records, if you restrict which certificate authorities can issue for your domain.

Subdomains

Go through every subdomain: www, shop, app, portal, status, help, links, and anything a vendor asked you to add years ago. These are the records scanners miss most often, and they usually belong to a tool someone still uses.

Put the full inventory in a spreadsheet with name, type, value, TTL and what it is for. That spreadsheet becomes your checklist for the next steps.

Step 2: Lower TTLs at the current provider

TTL (time to live) tells resolvers how long they may cache an answer. A day or two before the move, lower the TTLs on your important records at the current provider, especially MX and the website records, to something short such as 300 seconds. Wait at least one full old-TTL period so caches have picked up the short values.

This does not speed up the nameserver change itself. The pointer from the registry to your nameservers has its own TTL, set by the top-level domain operator, which you cannot change and which is often as long as two days for .com. What lower record TTLs give you is agility: if you discover a wrong value after the switch, a fix reaches the world in minutes rather than hours.

Step 3: Build the zone in Cloudflare and compare

Add your domain to Cloudflare, let the scan run, then compare the imported records line by line against your inventory. Add anything missing and correct anything that differs.

Pay close attention to the proxy status column. Cloudflare can proxy A, AAAA and CNAME records (the orange cloud), which routes web traffic through its network and returns Cloudflare's addresses instead of your server's. That is what you want for your website. It is not what you want for anything mail related or for verification CNAMEs. Cloudflare recommends DNS only (the grey cloud) for those. MX and TXT records cannot be proxied at all, but an A record for a mail server hostname or a DKIM CNAME can be, and proxying them will break mail.

A quick rule of thumb:

Step 4: Turn off DNSSEC at the registrar first

If DNSSEC is enabled on your domain, turn it off at your registrar before you change nameservers. DNSSEC publishes a signature fingerprint (a DS record) at the registry that matches your current provider's signing keys. Cloudflare's documentation is direct about the risk: changing nameservers while DNSSEC is active can make your domain unreachable, because resolvers will reject Cloudflare's answers as invalid.

Remove the DS record at the registrar, wait for that change to take effect (give it a day if the DS record had a long TTL), and only then move on. Once the domain is active on Cloudflare, re-enable DNSSEC through Cloudflare and add the new DS record it gives you at the registrar.

Step 5: Change the nameservers

At your registrar, replace the existing nameservers with the two Cloudflare assigned to your domain, spelled exactly as shown. Cloudflare allows up to 24 hours for the registrar update to be picked up, and it will email you and mark the domain Active once it sees the change.

During this window, some resolvers ask the old provider and some ask Cloudflare. That is why both zones must contain the same records. Do not edit or delete anything at the old provider until the move is complete and stable.

Step 6: Check email after cutover

Once Cloudflare shows the domain as Active, test email deliberately rather than waiting for complaints.

1. Look up your MX, SPF, DKIM and DMARC records against a public resolver such as 1.1.1.1 or 8.8.8.8 and confirm the answers match your inventory.
2. Send a message from an outside account (a personal Gmail or Outlook.com address) to a mailbox on the domain and confirm it arrives.
3. Send from the domain to an outside account, open the message headers and confirm SPF, DKIM and DMARC all show pass.
4. Repeat the outbound test for each sending service: your marketing platform, CRM, website form and any transactional sender.
5. Check any shared mailboxes, aliases and forwarding rules that depend on the domain.
6. Over the next few days, watch for bounce messages and check that Search Console and other verified services still show the domain as verified.

If DMARC aggregate reports are enabled, they are a useful cross-check for the first week. Our article on reading DMARC reports explains what to look for.

Step 7: Clean up

Leave the old DNS provider's zone in place for a week or two as a safety net. Then raise the TTLs back to normal values, re-enable DNSSEC through Cloudflare if you have not already, and document the new setup: which records exist, what each is for and who owns the Cloudflare account. If you manage several domains, our article on managing DNS at scale with Claude and Cloudflare covers keeping them consistent over time.

This is routine work for our DNS management service, and we usually pair it with an email authentication review so the zone that lands in Cloudflare is cleaner than the one that left.

Frequently asked questions

Will moving DNS to Cloudflare cause email downtime?

It should not, as long as every mail-related record exists in Cloudflare with the same values before you change nameservers, and mail-related hostnames are set to DNS only. Most email outages during DNS migrations come from a missing MX, DKIM or verification record, not from the move itself.

How long does a DNS migration to Cloudflare take?

Preparing the inventory and zone is usually the longest part. The nameserver change itself can take up to 24 hours for Cloudflare to confirm, and resolvers may keep using cached delegation data for up to a couple of days depending on the domain's top-level registry.

Do I need to disable DNSSEC before moving to Cloudflare?

Yes, in almost every case. Turn it off at the registrar before changing nameservers, then re-enable it through Cloudflare after the domain is active. Leaving it on during the move can make the domain unreachable.

Should my MX records be proxied in Cloudflare?

MX records cannot be proxied, and any hostname an MX record points at should be set to DNS only. Proxying is for web traffic. Mail and verification records should always be grey cloud.

Do I need to transfer my domain registration to Cloudflare too?

No. Changing nameservers moves DNS hosting only. Your domain can stay at its current registrar. Transferring registration is a separate, optional step.