Moving DNS Providers Without Breaking Your Website or Email

Moving DNS providers should change who answers for your domain, while leaving the website, email, and other services behaving as they did before. The failures usually come from something the migration missed: a DKIM selector, an IPv6 address, a delegated subdomain, or a DNSSEC record at the registrar.

A useful migration plan starts with a complete inventory and finishes with evidence that the new answers work.

Separate DNS hosting from domain registration

Your registrar controls the domain registration and its delegation. Your DNS provider serves the zone. They may be the same company, but changing one doesn't necessarily require changing the other.

For a normal DNS hosting migration, create the zone at the new provider and update the nameservers through the registrar. Keep a registrar transfer or a website hosting move as a separate task unless you have a specific reason to combine them.

That separation makes an unexpected result easier to trace: the application stays put while the source of its DNS answers changes.

Inventory more than the website

Export the existing zone or obtain a complete record list through the provider's dashboard or API. Querying a few familiar names won't discover every hostname.

Include:

• A and AAAA records for the apex and subdomains.
• CNAMEs, including custom domains and delegated DKIM selectors.
• MX records and their priorities.
• TXT records for SPF, DKIM, DMARC, and service verification.
• CAA and SRV records.
• Wildcards and subdomain delegations.
• Any additional record types your services use.

Record provider-specific behavior separately. ALIAS and ANAME records, proxy settings, traffic policies, and health-based routing may not survive a plain zone-file export.

Keep a dated copy of the original configuration and identify who can restore it.

This is also the moment to put the old zone under monitoring if it isn't already. OneDollarDNS's provider import or zone-file import turns every hostname in the zone into a monitored host, including the DKIM selectors and verification records nobody remembers. That gives you a recorded baseline of what the old provider served before anything moves. The import doesn't copy records to the new provider; it gives you something to check the new provider against.

Prepare TTLs ahead of the change

Lower relevant TTLs while the old configuration is still live, then allow the previous cache lifetimes to expire. Changing a TTL at the moment of migration doesn't shorten answers that resolvers already cached.

Also distinguish record TTLs from delegation TTLs. A five-minute A record does not mean every resolver will discover new nameservers in five minutes. Parent-side NS and DS records have their own cache lifetimes, set by the TLD rather than by you: in .com, delegation NS records carry a two-day TTL and DS records a one-day TTL. Your registrar can't shorten those.

What you can usually lower is the TTL on the NS records inside the old zone itself. Some resolvers prefer that copy over the parent's, so lowering it a day or two ahead helps them pick up the new nameservers sooner.

The TTL guide explains the timing. Write the actual values into your migration plan instead of assuming a universal propagation window.

Decide how DNSSEC will cross the boundary

If the domain uses DNSSEC, changing nameservers without a compatible signing plan can leave the parent DS record pointing at the old provider's key. Validating resolvers may then reject the new answers.

There are two broad approaches. Providers that support a coordinated signed migration can maintain validation throughout; Cloudflare documents one DNSSEC migration workflow. Otherwise, a migration may include a temporary unsigned interval.

For that second approach, the order matters:

1. Remove the DS record at the registrar, while the old provider is still signing.
2. Wait for the old DS TTL to expire (a day in .com, plus whatever time the registry takes to publish the removal).
3. Change the nameservers to the new provider.
4. Once the new delegation is stable, enable signing at the new provider and publish its DS record using the provider's instructions.

Don't reverse that order. If resolvers still have the old DS record cached when they start reaching unsigned or differently signed answers, validation fails and the domain goes dark for every user of a validating resolver. DNSSEC basics explain the chain of trust behind this requirement.

Test the new servers before changing delegation

Once the new zone is populated, query each assigned nameserver directly:

dig @ns1.new-provider.example example.com A +norecurse
dig @ns1.new-provider.example example.com AAAA +norecurse
dig @ns1.new-provider.example example.com MX +norecurse
dig @ns1.new-provider.example example.com TXT +norecurse
dig @ns1.new-provider.example _dmarc.example.com TXT +norecurse

These are placeholders: substitute the assigned server and your own domain. Repeat for every new nameserver and for the hostnames in your inventory.

Compare intended values and behavior, rather than requiring identical SOA records or provider-assigned nameserver names. Test CNAME targets and delegated subdomains too.

If a new provider won't serve the zone until activation, identify that restriction before choosing the cutover window and use its supported preflight checks.

Change delegation and keep both zones available

Update the nameservers at the registrar. Freeze unrelated DNS edits during the transition, or make necessary changes at both providers while either can still receive queries.

Verify the path and the cached views:

dig +trace example.com NS
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com MX

Then test the actual services: load the site, exercise a critical application path, and send mail in both directions. Matching records are necessary, but service tests catch mistakes that a visual comparison misses.

A test message only proves the senders you tried. A missed DKIM selector for a marketing platform or ticketing system won't show up until that system sends. If you publish a DMARC record with a rua address, aggregate reports cover every source sending as your domain, and MyDMARC turns them into a readable view of which sources started failing SPF or DKIM after the cutover. Reports typically arrive within a day.

AWS's DNS migration guide gives a provider-specific example of the preparation, delegation, and observation stages.

Define rollback before you need it

Keep the old zone and account active through the relevant delegation cache window and until verification is complete. Reverting nameservers is another cached change, so it isn't an instant undo.

A missing record may be quickest to fix on the new provider. A broader provider problem may justify returning to the old delegation. Either decision must account for DNSSEC and for users still reaching both sets of servers.

How DNS monitoring fits in

The most common migration failure is a record that never made it across, and it's the hardest one to spot by eye. If OneDollarDNS was monitoring the zone before the move, it does the comparison for you. Once the new delegation takes effect, it checks the same hosts against the new provider's nameservers. Any record that didn't come across shows up as a removal, and any value that came across differently shows up as a change, each with the old value beside it. You'll also get an alert for the NS change itself, which confirms the cutover is live.

During the transition, Frequent Monitoring can check your most important hosts every five minutes instead of hourly, and resolver comparison shows how far the new answers have spread through public caches.

Monitoring doesn't replace querying every nameserver, testing mail delivery, or keeping the old configuration available until the transition has finished. It does make sure a missing record gets noticed in hours rather than when a customer reports it.