Email DNS Migration

The Problem

Switching DNS providers (or nameservers) is exactly when email breaks silently — one missed TXT record and SPF fails, one missed MX record and mail stops arriving, often for hours before anyone notices.

About this problem

DNS migrations are exactly when email tends to break silently — every email-related record (MX, SPF, DKIM, DMARC, sometimes autodiscover) has to be recreated exactly at the new provider, and missing even one means mail starts failing hours later, often before anyone notices the cause.

This comes up specifically when changing DNS providers or nameservers for reasons unrelated to email itself — a website migration, consolidating DNS management, or switching registrars — where email is a dependency that's easy to overlook.

What's Included

• Full audit and export of every email-related record at the old provider
• Recreating every record exactly (MX, SPF, DKIM, DMARC, autodiscover if used)
• Low-TTL cutover planning to minimise propagation risk
• Post-migration verification that mail is flowing and authenticating correctly

What's NOT Included

• DNS migration for non-email records (website, subdomains) unless included separately
• Changing domain registrar
• Fixing issues caused by the new DNS provider's own platform limitations

How It Works

1. Fully audit and export every email-related DNS record from the current provider before any change.
2. Recreate each record exactly at the new provider: MX, SPF, DKIM, DMARC, and autodiscover/autoconfig if used.
3. Lower TTLs in advance where possible to reduce propagation risk during cutover.
4. Switch nameservers or DNS provider at the planned time.
5. Verify every record resolves correctly at the new provider and that mail authenticates and flows normally.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

Will changing DNS providers break my email?

Only if email-related records aren't recreated exactly — MX, SPF, DKIM and DMARC all live in DNS, so a provider switch has to carry every one of them over correctly, not just the website's records.

How long does an email DNS migration take?

The record changes themselves take minutes; safe practice is lowering TTLs beforehand and allowing a short overlap window to confirm everything resolves correctly before fully cutting over.

What's the biggest risk when migrating DNS for email?

Missing a record — a forgotten DKIM selector or a dropped MX record is the most common cause of mail silently failing for hours after a migration.

Do I need to pause sending email during a DNS migration?

Not if done properly with low TTLs and careful record recreation — the goal is zero interruption, with verification happening before and after cutover rather than during a pause.

Can I migrate just the website's DNS and leave email DNS alone?

Only if email-related records stay with a different, unaffected DNS zone — if everything moves together, email records need the same careful handling as the website's.

How do I know the migration worked for email specifically?

By sending live test mail through every system that uses the domain and confirming it authenticates (SPF/DKIM/DMARC all pass) and is delivered — not just that the records resolve.