Custom Domain Email Broke After DNS Migration — Fix

Quick answer: Check your MX records — they almost always disappear during migration. Add them back, set priority correctly, and wait for DNS propagation (up to 48 hours, but usually 30 min).

Here's the deal: You moved your DNS hosting from one provider to another — maybe from GoDaddy to Cloudflare, or from your old host to Route53. You updated nameservers. The website works. But email? Dead. No new messages. Or worse, you can send but not receive.

The culprit here is almost always missing or misordered MX records. DNS migration tools often copy A records, CNAMEs, and NS records, but drop MX records. Or they copy them but with wrong priority numbers. Email servers are picky about MX priority — get it wrong and mail gets rejected or delivered to the wrong server.

This happens most often with Google Workspace (formerly G Suite) and Microsoft 365. Their MX records are specific. One wrong character and it fails silently.

Step 1: Find Your Missing MX Records

First, figure out what MX records your old DNS had. If you still have access to the old provider's control panel, log in and look. If not, use a DNS history tool like SecurityTrails or check your email provider's docs.

For example, Google Workspace MX records look like this:

1 @ ASPMX.L.GOOGLE.COM
5 @ ALT1.ASPMX.L.GOOGLE.COM
5 @ ALT2.ASPMX.L.GOOGLE.COM
10 @ ALT3.ASPMX.L.GOOGLE.COM
10 @ ALT4.ASPMX.L.GOOGLE.COM

Microsoft 365 is similar but with different hostnames and priority settings.

Step 2: Add MX Records to Your New DNS Provider

Log into your new DNS management panel. Add each MX record exactly as it was. The key fields:

• Name/Host: Usually @ (or blank, depending on provider) — this means the root domain.
• Priority: Lower number wins. Priority 1 is primary, 5 is backup, etc.
• Value: The mail server hostname. Must match your email provider's docs exactly.
• TTL: Set to 300 seconds (5 minutes) for now. Change to 3600 or higher later.

Don't copy the TTL from the old provider if it was set to 86400 (24 hours) — that'll slow down propagation if you need to tweak later.

Step 3: Verify the MX Records Are Correct

Use a DNS lookup tool from outside your network. Open a terminal and run:

nslookup -type=mx yourdomain.com

Or use an online checker like MXToolbox. You should see exactly 5 records for Google Workspace, 4 for Microsoft 365 basics. If you see fewer, you missed some.

Step 4: Wait for Propagation

DNS changes aren't instant. Usually takes 30 minutes to 2 hours for most ISPs. If your old TTL was set to 86400 seconds, could take up to 24 hours. Check propagation with a global DNS checker.

During this time, email might work intermittently. That's normal. Don't panic.

Alternative Fix: If Email Still Broken After 48 Hours

If it's been two days and still no email, check these:

• SPF record missing: Add a TXT record for SPF. For Google Workspace, it's v=spf1 include:_spf.google.com ~all.
• DKIM not set up: Google and Microsoft both require DKIM keys for reliable delivery. Generate a key pair in your email admin panel, add the public key as a TXT record.
• DMARC policy too strict: If you set DMARC to p=reject and your SPF/DKIM aren't perfect, email gets rejected. Start with p=none.

Also check if your old DNS provider still has the zone active. Some providers keep the zone alive after migration, causing conflicts. Delete the old zone if possible.

Prevention Tip for Next Time

Before you migrate DNS, take a screenshot of all DNS records. Not just MX — all of them. Export the zone file if your provider supports it. That way you have the exact values.

Also, lower the TTL on all records to 300 seconds a few days before migration. This way changes propagate fast. Raise them back to 3600 or 86400 after everything's stable.

If you're migrating between major providers like Cloudflare to AWS, use their built-in import tools — they usually handle MX records correctly, but always double-check.

One last thing: If you're using a third-party email service like Zoho or ProtonMail, their MX records are different. Look them up in their documentation. Don't guess — I've seen people use generic Google MX records with Zoho and wonder why email bounces.

That's it. Fix the MX records, wait a bit, and email comes back. If I had a dollar for every time this was the fix, I'd retire.