The records you will see in a migration quote
A zone file is the list of DNS records for your domain. A migration touches a small part of it, and most outages come from changing a record that was never meant to move. The definitions below follow Cloudflare's record reference and the DNS standards.
Cloudflare defines an A record as mapping a domain name to an IP address, a CNAME as mapping a name to another canonical name, an MX record as required to deliver email to a mail server, a TXT record as a way to enter text into DNS, an NS record as indicating which server should be used for authoritative DNS, and a CAA record as specifying which certificate authorities may issue certificates for the domain.
| Record | What it does | Changes at a web-host cutover? |
|---|---|---|
| A / AAAA | Points a name at an IPv4 / IPv6 address | Yes, for the web names you are moving |
| CNAME | Makes one name an alias of another name | Yes, if www or a subdomain aliases the old host |
| MX | Tells senders which servers accept your email | No, unless you are also moving email |
| TXT (SPF, DMARC, verification) | Holds text: mail authorization, policies, ownership proofs | No, except adding the new host to SPF if it will send mail |
| TXT or CNAME for DKIM | Publishes the public key that signs your mail | No |
| CAA | Lists which certificate authorities may issue certificates | Check only: the new host's certificate authority must be allowed |
| NS | Names the servers that answer for your zone | Only if you change DNS provider |
| DS | Links the parent zone to your DNSSEC signing key | Only if you change DNS provider with DNSSEC on, and then first |
| TTL (a field, not a record) | How long a cached answer may be kept | Lower it in advance on the records you will change |
A, AAAA and CNAME: the records that actually move
When the site moves, its address moves. If the bare domain (example.com) has an A record pointing at the old server, you replace that IP with the new host's IP. If the old host had IPv6 and you leave a stale AAAA record behind, visitors on IPv6 networks will still reach the old server, so either update it or delete it.
A CNAME is an alias. Managed hosts often ask you to point www at a hostname they control rather than at an IP. RFC 1034 says that if a CNAME is present at a name, no other data should be present there. That is why you cannot put a CNAME on the bare domain alongside its MX and TXT records in a standard zone; some DNS providers offer their own features for this, such as the CNAME flattening Cloudflare describes, so check your provider's documentation.
Practical rule: change only the names the web host serves (usually @ and www), and nothing that a mail, newsletter or verification service gave you.
NS and DS: the records that can take the whole domain offline
NS records decide who answers for your domain. If you change nameservers to a new DNS provider, every record must already exist at the new provider, or names that are missing will stop resolving. Cloudflare warns that its quick scan is not guaranteed to find all existing records and that activating a domain without the correct records can cause DNS_PROBE_FINISHED_NXDOMAIN errors. It also notes registrars can take up to 24 hours to apply a nameserver change.
DS records belong to DNSSEC. RFC 4034 explains that the DS record refers to a DNSKEY by storing its key tag, algorithm and a digest, and that it appears only on the parent side of the delegation; in practice you manage it at the registrar. If the DS at the registrar points at the old provider's key, validating resolvers fail the lookup. Cloudflare's troubleshooting guide shows this as SERVFAIL from dig, with valid answers returned only when validation is disabled using +cd.
Cloudflare's setup guide is explicit: if DNSSEC is active, turn it off at the registrar before replacing nameservers, then re-enable it with the new provider once the domain is active. When disabling, Cloudflare advises waiting at least 1.5 times the DS TTL before removing DNSKEY records; with a 24-hour DS TTL, that is 36 hours.
Worked example: before and after zone for a course site with email
The site below runs WordPress at the old host, sends staff email through a hosted mailbox provider, and sends newsletters through a separate platform. DNS stays at the same provider; only the web host changes. Addresses and hostnames are placeholders.
| Name | Type | Before | After | Why |
|---|---|---|---|---|
| @ | A | 192.0.2.10 (old host), TTL 3600 | 198.51.100.20 (new host), TTL 300 | Web address moves; TTL lowered a day ahead |
| @ | AAAA | Old host IPv6 | New host IPv6, or delete if the new host has none | A stale AAAA sends IPv6 users to the old server |
| www | CNAME | example.com | example.com, or the hostname the new host specifies | Follow the new host's instructions exactly |
| @ | MX | Mailbox provider's servers | Unchanged | Email is not moving |
| @ | TXT (SPF) | v=spf1 include:mailbox-provider include:newsletter ~all | Same, plus the new host only if WordPress will send mail from it | One SPF record only; edit, never add a second |
| selector._domainkey | TXT or CNAME (DKIM) | Provider key | Unchanged | Deleting it breaks signing for that sender |
| _dmarc | TXT | v=DMARC1; p=none; rua=... | Unchanged | Policy is about mail, not the web host |
| @ | TXT (verification) | Search console or other ownership tokens | Unchanged | Removing them can unverify accounts |
| @ | CAA | Allowed certificate authorities | Unchanged, or add the new host's CA | Otherwise the new certificate cannot be issued |
| @ | NS | Current DNS provider | Unchanged | DNS provider is not moving |
TTL: the timer on every answer
RFC 1034 defines TTL as how long a record can be cached before it should be discarded. Cloudflare puts the trade-off plainly: longer TTLs speed up lookups but make updates take longer to go into effect. Its Auto TTL is 300 seconds, and for unproxied records you can choose between 60 seconds (30 on Enterprise) and 1 day.
Lower the TTL only on records you will change, and do it at least one full old-TTL before cutover so caches pick up the short value. Leave MX and TXT TTLs alone. After the move is verified, raise TTLs again.
Cutover checklist for DNS
- Export the current zone and keep it as the rollback copy.
- Mark every record as move, keep or check before the window.
- Lower TTL on the A, AAAA and CNAME records you will change at least one old-TTL in advance.
- Confirm CAA allows the certificate authority the new host uses.
- If changing DNS providers with DNSSEC on, remove or update the DS at the registrar first.
- Never add a second SPF record; merge any new sender into the existing one.
- After cutover, query the changed names and an unchanged MX record to confirm both.
Questions before you decide
Do I need to change MX records when I move my website?
Not if your email stays where it is. MX records tell senders which servers accept your mail, so they only change when you move email. Changing web hosting means changing the A, AAAA or CNAME records for the web names.
Why can't I put a CNAME on my bare domain?
RFC 1034 says that if a CNAME is present at a name, no other data should be present. The bare domain normally carries MX, TXT and NS records, so a standard CNAME cannot sit there. Some providers offer features such as Cloudflare's CNAME flattening; check your provider's docs.
What happens if I change nameservers with DNSSEC still on?
Validating resolvers can fail with SERVFAIL because the DS record at the registrar no longer matches the new provider's key. Cloudflare says to turn off DNSSEC at the registrar before replacing nameservers and warns the domain can otherwise become unreachable.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Cloudflare: DNS record types Accessed 30 Oct 2026
- Cloudflare: Time to Live (TTL) Accessed 30 Oct 2026
- Cloudflare: full setup and changing nameservers Accessed 30 Oct 2026
- Cloudflare: DNSSEC troubleshooting Accessed 30 Oct 2026
- RFC 1034: Domain names, concepts and facilities Accessed 30 Oct 2026
- RFC 4034: Resource records for the DNS security extensions Accessed 30 Oct 2026
- RFC 7208: Sender Policy Framework Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.