Domain Migration Without Breaking Email

Moving domains between registrars or hosts shouldn't break email, but it does. All the time. Here's the step-by-step process I use to migrate domains without users getting "550 mailbox not found" errors or wondering why they can't receive messages.

Before You Touch Anything

Document Current State

Take screenshots and notes of everything. You'll thank yourself later.

At current registrar:

• Domain expiration date
• Current nameservers
• Registrar lock status (transfer lock)
• WHOIS privacy status
• Any email forwarding at registrar level

At current DNS host:

; Run these and save the output
dig example.com ANY
dig example.com MX
dig example.com TXT
dig _dmarc.example.com TXT
dig mail._domainkey.example.com TXT
dig selector1._domainkey.example.com CNAME

Or use a GUI tool and screenshot everything. The records you MUST document:

• A records - Main site, subdomains
• MX records - Where email goes
• SPF record - Who can send email
• DKIM records - Email authentication
• DMARC record - Email policy
• Any CNAME records - Especially autodiscover, mail

At email provider (if separate):

• Verify domain ownership method (DNS TXT record, etc.)
• Check any provider-specific DNS requirements

Lower TTL Values

24-48 hours before migration, lower TTL on critical records:

; Lower these to 300 seconds (5 minutes)
example.com.        300 IN A       x.x.x.x
example.com.        300 IN MX  10  mail.example.com.
example.com.        300 IN TXT     "v=spf1 include:..."
mail.example.com.   300 IN A       x.x.x.x
autodiscover        300 IN CNAME   autodiscover.outlook.com.

This ensures that when you make changes, propagation happens quickly. Default TTLs of 86400 (24 hours) mean some DNS servers will hold old records for a full day.

Migration Scenarios

Scenario 1: Changing Registrars Only (Keeping DNS Host)

The safest migration. You're just moving who you pay for the domain.

Steps:

1. Unlock domain at current registrar
2. Get EPP/authorization code from current registrar
3. Initiate transfer at new registrar (enter auth code)
4. Approve transfer via email (check admin contact email)
5. Wait for transfer (5-7 days typical)
6. Verify nameservers stayed the same after transfer
7. Lock domain at new registrar

Email impact: None. DNS doesn't change.

Common mistake: Auto-renewing at old registrar right before transfer. The transfer includes a 1-year registration, and the old registrar may not refund the overlap.

Scenario 2: Changing DNS Hosts (Same or New Registrar)

This is where email breaks if you're not careful.

Steps:

1. Create all records at new DNS host first Before changing nameservers, replicate your entire zone:

; At new DNS host, create these records
@       300 IN A       x.x.x.x
@       300 IN MX  10  mail.example.com.
@       300 IN MX  20  mail2.example.com.
@       300 IN TXT     "v=spf1 include:_spf.google.com ~all"
mail    300 IN A       x.x.x.x
www     300 IN CNAME   example.com.
; All DKIM records
; DMARC record
; Everything else

2. Verify records at new DNS host Most DNS hosts let you query records before they're live:

dig @ns1.newhost.com example.com MX

Confirm all records return correct values.

3. Change nameservers at registrar Update nameservers to point to new DNS host:

ns1.newhost.com
ns2.newhost.com

4. Monitor propagation Check multiple DNS servers:

dig @8.8.8.8 example.com MX
dig @1.1.1.1 example.com MX
dig @208.67.222.222 example.com MX

Or use whatsmydns.net for visual propagation check.

5. Verify email flow Send test emails in both directions immediately.

Email impact: Should be zero if records are identical. During propagation (minutes to hours), different servers may resolve to old vs new DNS, but both have the same records, so it works either way.

Common mistake: Forgetting to copy MX records or SPF records to new host before changing nameservers. Results in bounced email.

Scenario 3: Full Migration (New Registrar and New DNS Host)

Combine scenarios 1 and 2, but do them separately:

1. First, migrate DNS to new host (as above)
2. Wait 24-48 hours, verify everything works
3. Then transfer registrar

Don't do both simultaneously. If something breaks, you won't know if it's the registrar transfer or DNS change.

The MX Record Rule

MX records must resolve to something.

This sounds obvious, but I see this mistake constantly:

; WRONG - MX points to CNAME
example.com.    MX  10  mail.example.com.
mail.example.com.   CNAME   something.mailprovider.com.

; RIGHT - MX points to A record
example.com.    MX  10  mail.example.com.
mail.example.com.   A       x.x.x.x

; ALSO RIGHT - MX points directly to provider
example.com.    MX  10  mail.example.com.googlemail.com.

RFC says MX should not point to CNAME. Some servers tolerate it; others reject mail. Don't risk it.

SPF Record Migration Checklist

SPF tells receiving servers who's allowed to send email for your domain. Get it wrong and your email goes to spam.

Verify includes are correct:

; Microsoft 365
v=spf1 include:spf.protection.outlook.com ~all

; Google Workspace
v=spf1 include:_spf.google.com ~all

; Multiple senders
v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:servers.mcsv.net ~all

Check the lookup limit:

SPF has a 10 DNS lookup limit. If your SPF record chains too many includes, it silently fails.

Test with: mxtoolbox.com/spf.aspx

Only one SPF record:

You can only have ONE TXT record starting with v=spf1. Multiple SPF records = both are invalid.

DKIM Records Migration

DKIM records are CNAME or TXT records that look like:

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.

Or:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

Do not modify DKIM values. Copy them exactly. The public key in that record must match the private key your email provider uses. If they don't match, DKIM fails.

Find your DKIM selectors:

• Microsoft 365: selector1 and selector2
• Google Workspace: google (default)
• Other providers: Check their documentation

DMARC Record Migration

DMARC goes at _dmarc.example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Copy it exactly. The only time to modify is if:

• You're changing the reporting email address
• You're intentionally tightening or loosening policy

Post-Migration Verification

Run these checks after nameservers have propagated:

MX record resolves:

dig example.com MX +short
# Should return your mail server with priority

SPF is valid:

dig example.com TXT | grep spf
# Should return one v=spf1 record
# Check at mxtoolbox.com for lookup count

DKIM passes:

Send test email to [email protected] or use mail-tester.com

DMARC exists:

dig _dmarc.example.com TXT +short

Send/receive test:

• Send from domain to external address (Gmail works)
• Send from external to domain
• Check headers for DKIM/SPF pass

Emergency Rollback

If email breaks post-migration:

1. Change nameservers back to old DNS host The old records are probably still there. Point back and wait for propagation.
2. Or fix records at new host If you know what's wrong (missing MX, wrong SPF), fixing forward is often faster than rolling back.
3. Check if old host deleted records Some DNS hosts delete zone data when nameservers point away. If so, you'll need to recreate from your documentation.
4. Extend TTL for stability once fixed Once working, set TTLs back to reasonable values (3600-86400) to reduce load and increase caching.

Quick Reference Timeline

1-2 weeks before:

• Document all DNS records
• Verify you have registrar credentials
• Check domain expiration date

24-48 hours before:

• Lower TTL to 300 on critical records
• Create all records at new DNS host (if changing)

Migration day:

• Verify new DNS records are correct
• Change nameservers (or initiate transfer)
• Monitor propagation
• Test email immediately

24 hours after:

• Verify all records resolved correctly
• Send/receive email tests
• Check DKIM/SPF/DMARC passing

1 week after:

• Reset TTL to normal values (3600+)
• Remove old DNS zone if no longer needed
• Document new configuration

The Golden Rule

Never delete old DNS records until new ones are working.

Every email disaster I've seen in domain migration came from deleting records at the old host before confirming the new host is serving traffic. Don't be that person.

Plan it, document it, test it, migrate it. In that order.