Move DNS to Cloudflare Without Breaking Email (MX Records)

Moving authoritative DNS changes who answers questions about your domain. It does not move mailboxes, reset passwords, or migrate historical messages. Email breaks when the new DNS zone leaves out records that mail systems depend on.

This walkthrough separates the DNS change from the mail service, builds a verifiable inventory, and checks delivery before and after switching nameservers. Keep your existing email provider unless a separate migration is explicitly planned.

Inventory the zone before touching nameservers

Start with a complete record inventory from your current DNS provider. Automatic scanning is helpful, but it is not an authoritative export: uncommon hostnames, verification records, and selector-specific DKIM entries may be missed.

The JSON Formatter below helps inspect an inventory exported as JSON or assembled from your provider's API response. Format it to compare record names, types, priorities, and targets without losing fields in a wall of text. It does not validate DNS semantics or import the records into Cloudflare for you.

Record the current authoritative nameservers, registrar access details, and DNSSEC status as well. Take an inventory of the web application, email provider, mailing platform, and other services that publish records. A root-domain MX lookup alone cannot reveal everything required for reliable outgoing mail.

Use a local, sanitized export if the inventory contains private service names. Public DNS records are generally visible, but API tokens and account credentials must never be pasted into a formatting tool.

Understand which email records must survive

The MX records identify servers accepting mail for the domain. Lower numeric priorities are preferred. Copy the exact targets and priorities supplied by your mail provider; do not replace them with your website's IP address or infer them from a familiar provider name.

Also preserve sender authentication and client-discovery records. These often live at different names:

• SPF is a TXT record, usually at the domain root, describing authorized sending infrastructure.
• DKIM uses selector-specific names under _domainkey, with TXT keys or provider-managed CNAME targets.
• DMARC is a TXT record at _dmarc that publishes alignment policy and reporting destinations.
• Autodiscover, autoconfig, verification TXT records, and relevant SRV records may support client setup or service ownership.

Keep one SPF policy per owner name. Do not merge policies by blindly concatenating TXT values, and do not change DMARC enforcement while migrating DNS. Separating changes makes faults easier to isolate.

For protocol details, RFC 5321 describes SMTP routing and RFC 7208 defines SPF. Your provider's documented settings remain the source for your particular tenant's values.

Build and compare the Cloudflare zone

Add the domain to Cloudflare, review the discovered records, and manually fill gaps from your inventory. Use DNS-only mode for mail hostnames and provider-required service records. Cloudflare's standard HTTP proxy does not act as an ordinary SMTP, IMAP, or POP proxy.

MX records themselves are not HTTP-proxied. Pay particular attention to their destination names: if an MX target is a hostname you control, its address records must lead directly to the mail service rather than a web proxy. Do not assume an orange-cloud setting suitable for www is suitable for mail.

The following is a sanitized comparison object, not a Cloudflare API payload. Replace every illustrative value with your provider's actual records before creating anything:

{
"domain": "example.com",
"records": [
  {"type": "MX", "name": "@", "priority": 10, "content": "mail.example.com"},
  {"type": "A", "name": "mail", "content": "192.0.2.25", "proxied": false},
  {"type": "TXT", "name": "@", "content": "v=spf1 ip4:192.0.2.25 -all"}
]
}

This deliberately minimal example is not a production mail configuration. Documentation addresses cannot receive real mail, and the SPF example is appropriate only as a structural illustration. Real hosted mail often uses provider MX destinations, include mechanisms, and additional authentication records.

Review the Cloudflare documentation for DNS proxy limitations and current dashboard behavior. Leave website proxy changes for a separate maintenance step if possible, reducing the number of systems changing simultaneously.

Verify answers before changing delegation

Query both the old and new authoritative servers directly using explicit nameserver queries. Install dig through your operating system's DNS utilities package if needed. Substitute the actual old nameserver and the Cloudflare-assigned nameserver for the placeholder variables below.

OLD_NS='OLD_AUTHORITATIVE_NAMESERVER'
NEW_NS='CLOUDFLARE_ASSIGNED_NAMESERVER'
dig @"$OLD_NS" example.com MX +noall +answer
dig @"$NEW_NS" example.com MX +noall +answer
dig @"$NEW_NS" example.com TXT +noall +answer
dig @"$NEW_NS" _dmarc.example.com TXT +noall +answer
dig @"$NEW_NS" selector1._domainkey.example.com TXT +noall +answer

Use your real DKIM selector instead of selector1; if the provider uses CNAME delegation, query that record type too. Compare record content, not output order. Some interfaces split long TXT strings into multiple quoted chunks, which DNS clients concatenate within a single record.

Return to the JSON comparison tool when reviewing a revised inventory, especially if several people are editing the zone. Mark each record verified only after checking the new authoritative answer. Keep the original export unchanged so that accidental omissions remain discoverable.

A lower TTL can shorten caching of changed records, but lower it ahead of time on the existing zone. It does not instantly clear caches or guarantee that nameserver delegation changes complete within that interval.

Switch nameservers and test real delivery

Before switching, handle DNSSEC delegation deliberately. If a DS record exists at the registrar for the old signing keys, follow the providers' migration procedure. An unsupported or stale DS chain can make validating resolvers reject the whole domain even when direct authoritative queries look correct.

For a conventional migration without coordinated key continuity, disable the old DNSSEC delegation as instructed and allow the previous DS record to age out before switching. After Cloudflare is authoritative and stable, enable its DNSSEC and publish its exact new DS values at the registrar. Do not reuse the old provider's DS record.

Change nameservers at the registrar to the assigned pair. Keep the old DNS zone active through the transition and avoid unrelated edits. Query several recursive resolvers and compare them with the authoritative answers; expect temporary differences because of caches.

Then perform end-to-end mail tests:

1. Send inbound messages from an independent mail service to a normal mailbox and an alias.
2. Reply externally and inspect received headers for SPF, DKIM, and DMARC results.
3. Test website-generated mail, password resets, and any separate marketing sender.
4. Check provider delivery logs, queues, and bounce messages for delayed failures.

An existing IMAP session staying connected is not proof that new senders can find your MX records. Keep monitoring after the first successful test, since cached old answers can temporarily hide an omission.

For related infrastructure work, see the wildcard certificate guide; DNS validation records deserve the same inventory discipline. Browse Web Hosting & Servers when planning the next separate maintenance task rather than bundling it into this cutover.

Key takeaways

• Preserve MX and authentication records, plus client-discovery and service-verification entries.
• Keep mail hostnames DNS-only and compare answers from the new authoritative servers before delegation changes.
• Treat DNSSEC continuity as a migration requirement, not an optional cleanup item.
• Test real inbound and outbound messages, not just mailbox login or a single DNS lookup.
• Retain the old zone and inventory until caches and delivery checks show a stable transition.