How to migrate DNS between providers without downtime?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

You've decided to move DNS providers. Maybe your current one is slow, has a clunky interface, or is missing features you need. Whatever the reason, the goal is the same: get fully switched over without anything breaking, especially your email authentication records.

Here's how to do it properly, with timing that actually works.

About a week before: lower your TTL

Every DNS record has a TTL (Time to Live), which tells the internet how long to cache that record before checking for updates. If your TTL is set to 86400 seconds (24 hours), any change you make won't fully propagate for up to a day. That's a long window for things to go wrong.

Log into your current DNS provider and lower the TTL on every record to 300 seconds (5 minutes). Then wait for the old TTL to expire before moving on. If your records were cached at 86400 seconds, you need to wait at least 24 hours after lowering the value before the shorter TTL takes effect everywhere.

A few days before: document every single record

Export or manually copy every record in your current DNS zone. That means A records, CNAME records, MX records, and every TXT record. Pay special attention to your email authentication records, because these are where people make mistakes during migrations.

Your SPF record is a TXT record on your root domain (usually @). Your DKIM records are TXT records with selector-specific names like selector1._domainkey.yourdomain.com. Your DMARC record is a TXT record at _dmarc.yourdomain.com. If any of these are missing or miscopied at the new provider, your emails can start failing authentication as soon as the nameservers switch.

Copy the full record value for each one, not just the key parts. One missing character in an SPF record breaks the whole thing.

The day before: set up the new zone

Create your zone at the new DNS provider and copy every record across exactly. Most providers let you import a zone file if your current provider supports export. If not, you're doing it manually, which is fine, just slow.

So once everything is entered, verify it directly. You can query the new provider's nameservers specifically (before the cutover) to confirm the records resolve correctly. Tools like dig or our free SPF checker let you spot issues before the switch happens, not after.

Cutover day: change the nameservers

This is the actual migration moment. Log into your domain registrar and update the nameservers to point to your new DNS provider. The registrar is separate from your DNS host in most setups (if that's a new concept, here's the distinction).

Because you lowered your TTL earlier, propagation will be fast. Most resolvers will pick up the new nameservers within 5-30 minutes. But propagation isn't instant globally, so both providers will be serving records for a short overlap period. That's expected and fine. Don't shut down the old zone yet.

Monitor your email sending during this window. Watch for bounce messages, authentication failures, or delivery errors. Keep your old zone alive and intact until you're confident the switch is complete.

After the migration: check, raise TTL, then decommission

So once propagation looks complete (usually 1-2 hours with a 300s TTL), run a full check of your records using an external tool. Check SPF, DKIM, and DMARC specifically. Then raise your TTL back to a sensible value. 3600 seconds (1 hour) is reasonable for most setups. 86400 is fine for stable records you rarely touch.

Only decommission the old DNS zone after you're satisfied everything is working. Give it at least 24-48 hours before deleting anything.

The most common email-specific mistake

People copy their DKIM records incorrectly. The record name matters just as much as the value. If your DKIM selector at your old provider was google._domainkey but you enter it as google._domainkey.yourdomain.com at the new provider (with the domain appended), you'll end up with a double-qualified name that doesn't resolve. Check the format your new provider expects before entering anything.

If you hit authentication issues after migrating, our free SPF checker and DKIM lookup tool can show you what's actually resolving at the new provider. And if things go sideways mid-migration, our SOS hotline is free.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Get a custom migration plan

I'm migrating DNS from current provider to new provider and want zero downtime. My domain is domain. Can you give me a day-by-day plan including TTL timing, and flag any risks specific to my email authentication records (SPF, DKIM, DMARC)? Also tell me what to check after the nameserver switch to confirm everything is working.

Edit the yellow boxes, then send to the AI of your choice.