Cloudflare DNS migration checklist
Use this checklist to prepare a Cloudflare DNS migration before changing nameservers. It covers zone inventory, record validation, MX, SPF, DKIM, DMARC, CAA, delegated subdomains, proxy status, SSL/TLS readiness, DNSSEC, TTL planning, rollback, and post-cutover checks.
Use this checklist to prepare a Cloudflare DNS migration before changing nameservers. It covers zone inventory, record validation, MX, SPF, DKIM, DMARC, CAA, delegated subdomains, proxy status, SSL/TLS readiness, DNSSEC, TTL planning, rollback, and post-cutover checks.
Topics: cloudflare, resource, cloudflare, migration, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Export the full zone file from the current DNS provider and reconcile it against live lookups, so you capture every A/AAAA, CNAME, TXT, SRV, NS delegation, and CAA record rather than just the obvious ones.
- 2
Pay special attention to email and verification records — MX, SPF (TXT), DKIM selectors, DMARC, and any provider ownership-verification TXT records — since these are the most commonly broken in a DNS move.
- 3
Recreate every record in Cloudflare and decide proxy status per record: which hostnames should be proxied (orange-cloud) versus DNS-only (grey-cloud), keeping MX, mail, and non-HTTP records DNS-only.
- 4
Confirm SSL/TLS readiness for the records you intend to proxy — edge certificate coverage, encryption mode, and that the origin presents a valid certificate — before any of them go orange-cloud.
- 5
Document DNSSEC state at the current provider and registrar; if the zone is signed, plan the unsigned window and DS removal as a separate sequence so signing does not break during the move.
- 6
Identify delegated subdomains and split-horizon or third-party-managed records (mail, SaaS verification, CDN CNAMEs) and confirm they are preserved or re-delegated correctly in Cloudflare.
- 7
Lower TTLs on records that will change a day or more ahead, then move nameservers (or set up the partial/CNAME zone) and watch resolution roll over.
- 8
Validate end to end after the change: every record resolves correctly, proxied hostnames serve over TLS, mail flows, SPF/DKIM/DMARC pass, and keep the old zone intact as a rollback target until verified.
Risk register
Risks to control
Email breaks because MX, SPF, DKIM, or DMARC records were missed or accidentally proxied.
Keep all mail and verification records DNS-only (grey-cloud), copy SPF and DKIM exactly, and confirm mail flow and authentication after the move before closing the change.
A proxied hostname is enabled before TLS is ready, causing certificate errors or redirect loops.
Confirm edge certificate coverage and a valid origin certificate, and set the correct SSL/TLS mode, before switching any record to orange-cloud.
Delegated subdomains or third-party-managed records are dropped during recreation.
Reconcile the exported zone against live DNS and certificate SANs, and explicitly preserve NS delegations and externally managed CNAMEs in Cloudflare.
DNSSEC is left enabled at the old provider, so the chain breaks the moment authority moves.
Treat DNSSEC as its own sequence: remove the DS record and pass through an unsigned window sized to the DS/DNSKEY TTL before completing the move.
High TTLs leave stale answers cached and slow both cutover and rollback.
Lower TTLs well ahead of the change and keep them low until resolution and services are verified.
Proxy status is applied wholesale instead of per record, exposing or breaking non-HTTP services.
Decide orange vs grey cloud per record, proxying only HTTP/HTTPS hostnames and leaving mail and other protocols DNS-only.
Output
Useful deliverables
- Reconciled zone inventory covering every record type, with current TTLs and the source provider.
- Email and verification record sheet (MX, SPF, DKIM selectors, DMARC, ownership TXT) with the recreated values confirmed.
- Per-record proxy decision (orange vs grey cloud) with the rationale for each non-proxied record.
- SSL/TLS readiness note for proxied hostnames covering certificate coverage, encryption mode, and origin certificate validity.
- DNSSEC handling plan including registrar DS state and the unsigned-window sequence where applicable.
- TTL lowering schedule and the nameserver or CNAME-setup cutover plan.
- Post-cutover validation report covering resolution, TLS, mail flow, and SPF/DKIM/DMARC checks, plus the rollback target.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
Will moving DNS to Cloudflare break my email?
Only if mail records are missed or proxied. MX, SPF, DKIM, and DMARC records must be recreated exactly and kept DNS-only (grey-cloud) — Cloudflare's proxy is for HTTP/HTTPS, not mail. Confirm mail flow and authentication after the move before closing the change.
What is the difference between an orange-cloud and grey-cloud record?
Orange-cloud (proxied) records route HTTP/HTTPS traffic through Cloudflare's network for caching, WAF, and TLS; grey-cloud (DNS-only) records just return the address with no proxying. HTTP hostnames are usually proxied; mail and other non-HTTP records stay DNS-only.
How long does a DNS migration take to propagate?
It depends on the TTLs on the existing records and, for a nameserver move, registrar propagation of the new NS records. Lowering TTLs a day or more ahead shortens the window and makes rollback faster. The checklist treats low TTLs as a prerequisite, not an afterthought.
Do I need to handle DNSSEC during the DNS move?
If the zone is currently signed, yes — DNSSEC has to be sequenced so it does not break when authority changes. You remove the DS record at the registrar and pass through an unsigned window sized to the DS/DNSKEY TTL before completing the move, then re-enable signing on Cloudflare afterward.
Nanosek
Plan a DNS migration
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.