How to change DNS without breaking your website or email

The one rule: capture before you change

DNS is the list of records that tells the internet where your domain’s website, email and other services live. Most DNS damage isn’t done by people making a wrong change. It’s done by people making the right change and, while they’re in there, deleting or replacing records they didn’t recognise. So the rule is: do not change anything until you have a complete copy of what exists now. Everything else in this guide follows from it.

If you don’t yet know where your DNS is managed, or which service hosts the site, run the diagnostic guide first and come back with its record filled in.

Step 1: Find the authoritative DNS provider

The authoritative DNS provider is the service whose nameservers the domain lists. Look the domain up at lookup.icann.org and read the nameservers. If they contain the registrar’s name, DNS is managed at the registrar. If they end in .ns.cloudflare.com, it’s Cloudflare. If they’re Vercel’s or Netlify’s, it’s that host. Sign in there and open the DNS records for the domain.

Step 2: Capture every existing record

If the provider has an export button, use it; Cloudflare, for example, exports the whole zone as a text file. If not, screenshot every page of records so that each record’s four parts are readable: type, name (the host, such as @, www or _dmarc), value (what it points at), and TTL (how long it may be cached). Note the date.

Then, separately, use a public lookup tool such as Google’s Dig to query the A, AAAA, CNAME, MX, TXT and NS types for the bare domain and for www. This confirms the records you captured are the ones the world actually sees, and catches a case where the panel you’re looking at isn’t the authoritative one.

What the record types mean

A name can’t have a CNAME and any other record at the same time, which is why the bare domain usually has A records while www has a CNAME. Some providers offer a flattened or ALIAS record at the root that behaves like a CNAME; hosts that ask for one will say so.

Step 3: Work out what each record supports

Go through your capture and label every record. Most fall into one of these groups:

• Website. The A and AAAA records at the bare domain and the CNAME at www. Their values name the host. If you can’t tell, the recognition table in the diagnostic guide helps.
• Email. The MX records, the SPF TXT record at the bare domain, DKIM records under _domainkey, and the DMARC TXT record at _dmarc. Also any CNAME or TXT records your email sending service asked for.
• Verification. TXT records such as google-site-verification=… or MS=ms…. They prove to a service that you control the domain. Google’s own instruction is not to remove its record even after verification succeeds, because it’s re-checked.
• Subdomains and services. Records at names like app, shop, blog, mail or calendar, pointing at other hosts or tools.
• Unknown. Anything you can’t place. Leave it.

The email records, a little more closely

Email is the thing most often broken by a website change, because its records sit in the same list and look unrelated. There are four pieces:

• MX records say where incoming mail goes. Google Workspace uses smtp.google.com (older setups use names starting aspmx); Microsoft 365 uses a name ending .mail.protection.outlook.com. If these change or vanish, mail to your domain bounces.
• SPF is a TXT record at the bare domain that starts v=spf1 and lists which services may send mail as your domain. A domain should have exactly one SPF record; two is an error that can cause your mail to be rejected. If a new service needs to send mail, it’s added inside the existing record, not as a second one.
• DKIM is a signature. It lives as a TXT record (Google) or a CNAME record (Microsoft) at a name like selector._domainkey, one per sending service. Removing it makes that service’s mail look forged.
• DMARC is a TXT record at _dmarc starting v=DMARC1 that tells receivers what to do with mail that fails SPF and DKIM. With a strict policy in place and SPF or DKIM broken, your mail goes to spam or is rejected.

None of these has anything to do with where the website is. A website move should leave all four untouched.

Step 4: Change records, or change nameservers?

Most tasks need a change to individual records, not to the nameservers. Moving the website to a new host means editing the A or AAAA record at the bare domain and the CNAME at www to the values the new host gives you. That’s two or three records. It does not mean wiping the zone, and it does not mean moving DNS to the new host. Vercel’s own documentation says it plainly: changing only the website’s A or CNAME record at your current DNS provider does not require moving the rest of your records. The host move guide puts this change at the end of a sequence that has the new site tested before you make it, and connecting a domain without breaking email deals with what each host’s domain screen asks for.

You need a nameserver change only when the task is specifically to move DNS management to a different provider: for example, because the new registrar requires its nameservers, because a developer needs access you can’t give at the current provider, or because you want Cloudflare in front of the site. A nameserver change replaces every record at once with whatever the new provider holds, which is why it has its own section below. If a host “offers” to take over your DNS during setup, you can decline and add the records it asks for instead.

Step 5: Make the smallest necessary change

1. Get the exact records the new service needs, as type, name and value. Hosts show these on the domain screen when you add a domain to a project.
2. If the records you’re about to change have a long TTL, lower it to a few minutes a day or two ahead, and wait for the old TTL to pass before making the real change. Cloudflare’s migration guidance suggests 300 seconds. It shortens the period when some visitors see the old site and some the new.
3. Edit the records that point at the old host to the new values. Edit rather than delete and re-add where the panel allows it.
4. Don’t touch anything else. Not the MX, not the TXT records, not the subdomains, not the NS records.
5. Save, and write down what you changed and when, next to your capture.

Step 6: Allow for propagation

DNS propagation is the period after a change during which some people still see the old answer. It isn’t the change spreading; it’s caches expiring. Every record’s TTL tells other servers how long they may remember it, so a record with a five-minute TTL updates quickly for most people and a record with a one-day TTL can take a day. Nameserver changes go through the registry and are slower: Cloudflare says to allow up to 24 hours, Vercel up to 48. During this window, check from more than one place, such as your phone on mobile data as well as your computer, and use a public lookup tool, which shows the current authoritative answer rather than your own cache. If the change doesn’t seem to take, the guide to a website not showing after a DNS change separates waiting from a record that will never work.

Step 7: Verify everything, not just the website

The sending test matters most and is skipped most. Broken SPF or DKIM doesn’t bounce mail; it quietly sends it to spam, and you won’t hear about it for weeks.

If you genuinely need to change nameservers

A nameserver change hands the whole domain to a different DNS provider. From the moment it takes effect, the old records are invisible and the new provider’s records are the only ones that exist. So the new provider must hold the complete zone before the switch, not after.

1. Add the domain at the new DNS provider. Don’t change the nameservers yet.
2. If the provider scans or imports your existing records, let it, then compare its list with your capture line by line. Cloudflare’s documentation says its scan is not guaranteed to find every record; Vercel and Netlify both tell you to copy your MX and verification records across yourself before switching. Add anything missing by hand.
3. If the provider doesn’t import, recreate every record from your capture: every A, AAAA, CNAME, MX, TXT and subdomain. All of them, including the ones you don’t understand.
4. Check the new provider’s copy with its own preview or with a lookup tool that lets you query a specific nameserver, if you have one.
5. Only now change the nameservers at the registrar to the new provider’s, copying the names exactly.
6. Allow up to a day, then run the full verification checklist above.
7. Leave the old provider’s records in place for a few weeks. They cost nothing and they’re your rollback.

If the nameserver change is part of a registrar transfer, the transfer guide places this at the right point in that sequence.

Checklist

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• DNS record types · Cloudflare
• Record TTL · Cloudflare
• DNS best practices: lower TTLs before a migration · Cloudflare
• Import and export DNS records · Cloudflare
• Full DNS setup: change your nameservers · Cloudflare
• Adding a custom domain · Vercel
• Managing DNS records · Vercel
• Set up Netlify DNS · Netlify
• Set up SPF · Google Workspace Admin Help
• Set up DKIM · Google Workspace Admin Help
• Set up DMARC · Google Workspace Admin Help
• Set up MX records for Google Workspace · Google Workspace Admin Help
• Create DNS records at any DNS hosting provider · Microsoft 365
• Verify your site ownership · Google Search Console Help
• Sender Policy Framework (SPF), RFC 7208 §3.2 · IETF
• Dig (DNS lookup) · Google Admin Toolbox
• ICANN Lookup · ICANN