Move DNS to a new provider
Moving DNS means copying every record exactly and switching nameservers without a gap. Find the records and features that don't export cleanly, handle DNSSEC, and switch in a safe order.
Official sources last reviewed · How we review
Build your personalized plan
A few questions, revealed as they become relevant. Your answers stay in this browser.
Start with the basics
We never ask for phone numbers, card numbers, passwords or codes. Names of providers or nicknames are enough.
Your plan so far
17things this change touches
- critical4
- high9
- moderate3
- low1
Updates as you answer. Every item will explain why it’s there.
What could break
In a typical dns provider plan, these are the most serious things to get right.
Export every record from the current provider
Critical · Website & DNS
Records you never knew about (verification tokens, DKIM keys, old subdomains) silently disappear when the nameservers change.
Email records: MX, SPF, DKIM selectors and DMARC
Critical · Email delivery
A missing MX or DKIM record means bounced or spam-filtered email that's hard to trace.
Recreate the zone at the new provider
Critical · Website & DNS
Any missing or mistyped record breaks the service behind it at the moment nameservers change.
DNSSEC: avoid a validation outage
Critical · Website & DNS
A DS record that doesn't match the new provider's keys makes validating resolvers return errors, so the domain disappears for a large share of users.
Compare old and new answers before switching
Critical · Website & DNS
Differences you don't catch become outages the moment the delegation changes.
Change the nameservers at the registrar
Critical · Website & DNS
A typo in a nameserver name, or one old nameserver left in the list, gives inconsistent answers.
Certificates renewed with DNS validation
Critical · Integrations & APIs
Renewals fail quietly against the old provider, and certificates expire weeks later, taking sites or APIs offline.
Check email deliverability after the move
Critical · Email delivery
Bounces or spam-foldering can run for days unnoticed.
Verification records for other services
High · Website & DNS
A service can quietly unverify your domain weeks later, disabling email, single sign-on or a custom domain.
Less common records: CAA, SRV, AAAA, wildcards and deep subdomains
High · Website & DNS
Certificate renewals can be refused, IPv6 visitors can hit a dead address, or calling and chat clients can stop connecting.
Before and after the change
Before you change it
- Export every record from the current provider
- Email records: MX, SPF, DKIM selectors and DMARC
- Verification records for other services
- Less common records: CAA, SRV, AAAA, wildcards and deep subdomains
- Freeze DNS changes during the migration
- Check you can change nameservers at the registrar
- Registrar features that rely on its DNS
- Lower TTLs before the switch
- Write down a rollback plan
- Recreate the zone at the new provider
- Apex NS records point at the new provider
- Terraform, OctoDNS or other infrastructure as code
After the change
- Change the nameservers at the registrar
- Watch the overlap period
- Certificates renewed with DNS validation
- Secure the new DNS provider account
- DNS and uptime monitoring
- Check email deliverability after the move
- Test every hostname and certificate
- Retire the old zone after a safe overlap
- Remove dangling delegations and records
- Raise TTLs again once stable
Your own plan adds or removes items based on your answers, and explains why each one is there.
The safe order
Doing things in the right sequence is what keeps you from getting locked out halfway through.
Before the change
Step 1: Export and inventory every record
Get a complete copy of the zone, including the records nobody remembers adding.
- Export every record from the current provider (critical risk)
- Email records: MX, SPF, DKIM selectors and DMARC (critical risk)
- Verification records for other services (high risk)
- Less common records: CAA, SRV, AAAA, wildcards and deep subdomains (high risk)
- and 1 more
Step 2: Prepare the registrar, TTLs and rollback
Make sure you can switch nameservers, shorten caching, and know how to undo the change.
- Check you can change nameservers at the registrar (high risk)
- Registrar features that rely on its DNS (high risk)
- Lower TTLs before the switch (high risk)
- Write down a rollback plan (moderate risk)
Step 3: Recreate the zone at the new provider
Import the records, fix what the import missed, and bring any infrastructure-as-code along.
- Recreate the zone at the new provider (critical risk)
- Apex NS records point at the new provider (high risk)
- Terraform, OctoDNS or other infrastructure as code (high risk)
- Subdomains delegated to other nameservers (high risk)
Step 4: Translate provider-specific records and features
Rebuild ALIAS records, traffic routing and proxy settings that don't come across in a zone file.
- Decide proxy settings record by record (high risk)
Step 5: Plan the DNSSEC handover
Remove or migrate the DS record so validating resolvers never see mismatched keys.
- DNSSEC: avoid a validation outage (critical risk)
Step 6: Compare old and new answers
Query both providers directly and resolve every difference before switching.
- Compare old and new answers before switching (critical risk)
During the change
Step 7: Switch the nameservers and watch the overlap
Change the nameservers at the registrar, then keep both providers identical while caches expire.
- Change the nameservers at the registrar (critical risk)
- Watch the overlap period (high risk)
Step 8: Point automation at the new provider
Move dynamic DNS, certificate renewals and scripts to the new provider's API as the switch happens.
- Certificates renewed with DNS validation (critical risk)
Immediately after
Step 9: Secure and monitor the new provider
Lock down access and API tokens, and add monitoring.
- Secure the new DNS provider account (high risk)
- DNS and uptime monitoring (moderate risk)
Verify
Step 10: Verify email, websites and certificates
Test what depends on DNS, not just the records themselves.
- Check email deliverability after the move (critical risk)
- Test every hostname and certificate (high risk)
Clean up
Step 11: Retire the old zone safely
After the overlap, delete the old zone, remove dangling records and raise TTLs.
- Retire the old zone after a safe overlap (high risk)
- Remove dangling delegations and records (high risk)
- Raise TTLs again once stable (low risk)
Why this change needs a plan
Your DNS provider answers every lookup for your domain: where the website is, where email goes, and which services you've verified. Changing provider means copying all of that exactly, then changing the nameservers at your registrar.
What could break: records that didn't come across (DKIM selectors and verification tokens are the usual suspects), provider-specific features like ALIAS records, proxying and traffic routing, DNSSEC if the DS record doesn't match the new provider, and automation that still calls the old provider's API.
The safe approach is to export everything, rebuild the zone, compare answers from both providers record by record, and only then switch, keeping the old zone untouched until the overlap is over.
Why it matters
DNS sits underneath your website, email, apps and certificates. A single missing record or mismatched DNSSEC key can take all of them offline at once, and the outage may only affect some users, which makes it slow to spot.
What makes it risky
Risk is highest with DNSSEC turned on, records that use provider-specific features, email on the domain, and automation that writes to DNS. Large zones with many hand-made records also raise the chance of missing something.
Common mistakes
- Copying records by hand from the dashboard and missing DKIM selectors or verification TXT records.
- Switching nameservers with DNSSEC on and the old provider's DS record still at the registry.
- Deleting the old zone on the day of the switch, before resolvers have stopped using it.
- Forgetting certificate renewals and dynamic DNS clients that use the old provider's API.
- Moving off a proxying provider without updating an origin firewall that only allows its IP ranges.
- Leaving an old nameserver in the list at the registrar alongside the new ones.
Frequently asked questions
How long does it take to change DNS providers?
Most of the time goes into preparation. The registrar usually publishes the nameserver change within minutes to hours, but resolvers can keep using the old nameservers for the NS record's TTL, which is often up to two days for .com. Keep both providers identical for at least that long.
Will my email stop working when I change DNS providers?
Not if MX, SPF, DKIM and DMARC records are recreated exactly before the switch. DKIM selectors are the most common gap, because they can't be discovered by querying DNS, so take them from the provider's export or dashboard.
Do I need to turn off DNSSEC to change DNS providers?
Usually, unless both providers support a multi-signer migration. Remove the DS record at the registrar, wait at least a day, switch nameservers, then enable DNSSEC at the new provider and publish its DS record.
Can I use two DNS providers at the same time?
During the overlap, both providers serve the zone, so keep them identical. A permanent multi-provider setup is possible but needs records kept in sync (often with a tool like OctoDNS) and careful handling of DNSSEC.
What's the difference between changing DNS provider and changing registrar?
The registrar is where the domain is registered and renewed; the DNS provider answers lookups for it. You can change either without the other. Changing DNS provider means changing the nameservers at your registrar.
Will changing DNS providers affect SEO?
Not if every record is the same and the site stays up. Search engines see the same site at the same addresses; only an outage during the move would affect crawling.