DNS records · Cloudflare
Move your DNS records to Cloudflare
Moving DNS is the step that breaks email, and it breaks it silently. This page is about Cloudflare as the destination — what its zone editor can hold, how records get in, and whether you can rehearse the move or have to perform it live.
The good news is that Cloudflare imports zone files, so the bulk of the work is an upload rather than an hour of retyping.
Checked against Cloudflare's documentation on August 9, 2026.
What is different about Cloudflare
The process is standardised. These are the parts that are not — the things that are true of Cloudflare and not of everyone else.
You can build the zone before delegating to it
Cloudflare saves records added while the domain still points elsewhere and simply keeps them inactive until the nameservers change. That means you can build the entire zone, read it back, verify it, and only then cut over — the safe order, which several competitors do not permit.
It imports BIND zone files
Bulk import means a zone from another provider goes in as a file. Clean it first: the address records in an export still point at your old host, and importing them unchanged leaves you serving from the host you are trying to leave.
What the editor can actually hold
Cloudflare documents A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, PTR, DNAME. If your zone uses a type outside that list, find out before you commit rather than at cutover.
Cloudflare at a glance
- Zone editor
- Cloudflare dashboard → the domain → DNS → Records
- Record types
- A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, PTR, DNAME
- Zone import
- Yes, BIND format
- Zone export
- Yes, BIND format
- Editable before delegation
- Yes
- Propagation
- usually minutes to a few hours once nameservers update
Step-by-step
- 1At your current provider
Inventory the zone you are leaving
Whatever the source, you need a complete picture before you touch anything. If your current provider exports a zone file, take it — it doubles as a dated record of a configuration that works.
- Capture type, name, value, priority and TTL for every record
- List every service that depends on DNS: website, email, newsletter sending, Search Console, Microsoft 365, payment providers
- Note anything you cannot explain, and keep it until you can
- 2At your current provider
Lower the TTLs a day ahead
Dropping TTLs to 300 seconds the day before means a mistake propagates its correction in five minutes rather than four hours. Do it at the old provider, while it is still authoritative.
- Edit the TTL on the A, CNAME and MX records
- Do it at least one full old-TTL period before cutover, or the change itself is still cached
- Raise them back afterwards
- 3At Cloudflare
Clean the zone file, then import it into Cloudflare
The importer takes the file as-is, which is exactly why it must be edited first. Everything address-related in an export still points at the old host.
- Cloudflare dashboard → the domain → DNS → Records
- Update A and AAAA records to the new server before importing, not after
- Strip NS and SOA lines — they describe the old zone's authority
- Choose replace rather than append on a zone that already has provider defaults
- Import and Export sit on the DNS Records page and use BIND format
- The importer offers a Proxy imported DNS records toggle — leave it off unless you want everything behind the proxy immediately
- CNAME, DNAME, MX, NS, PTR and SRV values must be fully qualified with a trailing period
- $ORIGIN, $TTL and $GENERATE are supported; $INCLUDE is not
- The zone file limit is 256 KiB
BIND lines the importer acceptsexample.com. 3600 IN A 203.0.113.10 www.example.com. 3600 IN CNAME example.com. example.com. 3600 IN MX 10 mx1.mailprovider.com. example.com. 3600 IN TXT "v=spf1 include:mailprovider.com ~all" - 4At Cloudflare
Read the zone back before cutting over
This is the rehearsal the ordering allows. Compare every record against your source with nothing live depending on the answer.
- MX priorities came across as numbers, not merged into the hostname
- Long DKIM values are intact rather than truncated
- Exactly one SPF record
- Watch for wildcard records catching subdomains you forgot
- 5On your computer
Verify from outside your own browser
Your browser and your ISP's resolver both cache, and both will tell you what you want to hear.
Check the answers the internet getsdig @8.8.8.8 example.com A +short dig @8.8.8.8 example.com MX +short dig @8.8.8.8 example.com TXT +short
Best practice
The habits that make this go smoothly, independent of which providers are involved.
- Recreate MX, SPF, DKIM and DMARC before anything else — email failures are silent and expensive
- Never import an exported zone without first updating its address records
- Lower TTLs a day ahead so a mistake is correctable in minutes
- Diff the new zone against the old one line by line before cutting over
- Keep the old zone intact until the move has settled; it is your instant rollback
- Build and verify the whole zone at Cloudflare before changing nameservers
What goes wrong
The failures that actually happen when Cloudflare is the destination.
Losing MX records is the classic outage
Can cause downtimeNothing warns you. The website looks perfect, and inbound mail starts bouncing at the moment nameservers change. Senders get a rejection you never see, and you find out days later when someone mentions they emailed you. Confirm MX before cutover, every time.
Import appends unless you tell it not to
Can cause delaysOn a domain that already has default records, appending leaves two answers for the same name and resolution becomes unpredictable. Clear the defaults or choose replace, and read what is there before deciding.
An unedited export points at your old host
Can cause downtimeThe most common import mistake. The zone loads perfectly, the site works, and it is still being served from the provider you are leaving — until you cancel that account.
A complete-looking zone can be doing nothing
Can cause delaysCloudflare stores records before delegation, so the editor can show a full, correct zone that is entirely inactive. Do not read a tidy record list as proof the migration is done.
DKIM values get truncated
Can cause delaysDKIM public keys exceed the 255-character limit for a single TXT string and must be split into quoted chunks. Pasting through a UI that does not handle the split silently produces an invalid key, and your mail starts failing authentication.
Where are you coming from?
Most of this job depends on the destination. These are the bits that depend on where you are coming from.
Coming from a provider that exports zone files
Best case for Cloudflare: export, edit the address records, import at Cloudflare dashboard → the domain → DNS → Records. Keep the original export untouched as your reference copy.
Coming from a provider with no export
Build the inventory by hand and be systematic. At least Cloudflare lets you enter it all before delegating, so you can check your work.
Coming from Cloudflare
Check which records are proxied. A proxied record's public answer is Cloudflare's address, not your origin — so copying what you see in DNS lookups rather than what is in the dashboard gives you the wrong values.
Common questions
Does Cloudflare import zone files?
Yes, in BIND format, in bulk. Edit the address records first — an unmodified export still points at your previous host.
Can I add records at Cloudflare before pointing my domain here?
Yes. Cloudflare saves them and keeps them inactive until the nameservers change, which lets you build and verify the whole zone in advance.
Do I actually need to move my DNS at all?
Often not. If you only want the website served from a different server, editing one A record where your DNS already lives is smaller and safer — every record you do not touch cannot break. Move the zone only when you genuinely want Cloudflare managing DNS.
How long until the change takes effect?
Cloudflare documents usually minutes to a few hours once nameservers update for changes. Records inside a zone that is already authoritative apply much faster, governed by the TTL you set; a nameserver change is the slow one, because the delegation TTL belongs to the TLD registry.
Reference documentation
Provider interfaces change. When these steps and the official documentation disagree, the documentation wins.
The same job at other providers
Move your DNS records to Bluehost
You cannot build the zone until you delegate to it
Move your DNS records to GoDaddy
You can build the zone before delegating to it
Move your DNS records to SiteGround
You cannot build the zone until you delegate to it
Move your DNS records to Hostinger
You can build the zone before delegating to it
Want this done for you?
I move sites onto Cloudflare regularly — files, database, DNS and the registrar — with the old provider kept as a rollback until it has settled.