You just moved your website to a new host, updated your nameservers, or changed your DNS provider — and suddenly your email stops working. Messages bounce, contacts say they never received your replies, and your inbox goes silent. This is one of the most common and most frustrating side effects of a DNS change, and it happens for very specific, fixable reasons. This guide breaks down exactly what goes wrong with email after a DNS change, how to diagnose it in minutes, and how to restore mail flow without waiting helplessly for propagation to sort itself out.
Why Email Breaks After a DNS Change
Email delivery depends almost entirely on DNS. When someone sends you a message, their mail server performs a DNS lookup for your domain's MX records (Mail Exchanger records). Those MX records point to your mail server's hostname, which itself must resolve via an A or CNAME record. If anything in that chain is missing, incorrect, or still propagating, mail will bounce or disappear.
Here are the specific reasons email breaks after a DNS change:
- MX records were not migrated. When you point your domain to new nameservers, the new DNS zone starts blank or from a template. If your registrar or new DNS host did not pre-populate your MX records, they simply do not exist yet.
- MX records point to the wrong hostname. Many hosts use generic mail server hostnames like mail.yourdomain.com or smtp.yourdomain.com. If those A records were not added to the new zone, the MX record is effectively broken.
- Old TTL values are caching bad data. If your previous MX record had a high TTL (say 86400 seconds / 24 hours), remote mail servers will keep trying the old server for up to that duration, even after you've made changes.
- SPF, DKIM, and DMARC records are missing. These TXT records authenticate outbound mail. Losing them does not stop delivery immediately, but it causes messages to be flagged as spam or rejected by strict receivers.
- Nameserver propagation is incomplete. Some resolvers around the world may still be serving your old zone, causing inconsistent mail delivery depending on where the sending server's resolver is located.
Step 1: Check Whether Your MX Records Actually Exist
The first thing to do is verify what MX records are currently published for your domain. Do not assume the migration carried them over — verify it.
On Linux or macOS, run:
On Windows, open Command Prompt and run:
If you get no output, or you see an error like NXDOMAIN or no answer, your MX records are missing entirely. If you see records but the hostnames look unfamiliar or wrong, that is also a problem.
A healthy MX response looks like this:
The numbers (10, 20) are priority values — lower means higher priority. If your mail provider is Google Workspace, you should see entries like aspmx.l.google.com. For Microsoft 365, you will see something like yourdomain-com.mail.protection.outlook.com.
Step 2: Verify the MX Hostname Resolves
Having an MX record is not enough. The hostname the MX record points to must also resolve to an IP address. If your MX record says mail.yourdomain.com but there is no A record for that hostname, mail servers will connect nowhere.
If this returns nothing, log in to your DNS provider's control panel and add the missing A record. For most shared hosting setups, that IP address should be the same IP as your mail server — your host's support team can confirm the correct value if you are unsure.
Step 3: Add or Restore Missing MX Records
Log in to wherever your domain's DNS is now managed. This is not necessarily your domain registrar — it is whichever service controls your nameservers. Common locations include Cloudflare, cPanel (through your host), Route 53, or your registrar's DNS panel.
Add your MX record with the following values (adjust to match your mail provider):
- Type: MX
- Name / Host: @ (or leave blank — this represents the root domain)
- Value / Points to: your mail server hostname (e.g., mail.yourdomain.com or aspmx.l.google.com)
- Priority: 10 (or as specified by your mail provider)
- TTL: 300 (5 minutes, so future changes propagate quickly)
If you use Google Workspace, you need all five MX records Google specifies. If you use Microsoft 365, the single MX record provided in the Microsoft 365 admin center is sufficient, but you also need the Autodiscover CNAME and SPF TXT record.
Step 4: Restore SPF, DKIM, and DMARC Records
Once MX is sorted, check your authentication records. These are TXT records, and they are frequently lost during DNS migrations.
Check for SPF:
A valid SPF record looks like:
Or for Microsoft 365:
Check for DKIM. DKIM records live on a subdomain, typically in the format selector._domainkey.yourdomain.com. The selector name depends on your mail provider — Google uses google, and many ESPs use custom selectors. Contact your provider or check your old DNS export to find the right selector.
Check for DMARC:
A minimal DMARC record looks like:
Add any missing records through your DNS control panel as TXT records on the appropriate hostnames.
Step 5: Test Mail Flow End-to-End
Do not just assume the fix worked — test it. Send a test message from an external account (Gmail, Outlook.com) to your domain and verify it arrives. Then send one from your domain to that external account and check that it lands in the inbox, not spam.
For a more structured test, use MXToolbox's SMTP diagnostic or run a manual SMTP test from the command line:
If port 25 is blocked on your network (common on residential ISPs), try port 587 instead. A successful connection will show a banner from your mail server confirming it is alive and accepting connections.
You can also use the DNS Lookup tool to query MX, TXT, and A records for your domain in one place and confirm everything resolves correctly before assuming mail is fixed.
Step 6: Deal With Bounces During Propagation
If mail is bouncing right now, the sending server is logging those failures. Most legitimate senders (especially large providers) will retry delivery for up to 72 hours. This means that once your MX records are correct and propagated, queued messages from the past day or two will usually deliver automatically on the next retry cycle.
To confirm your fix has propagated globally, use the DNS Propagation Checker and select MX as the record type. Once all or most locations return the correct record, delivery should normalize within the hour.
If you have urgent messages stuck on a sender's server, contact that sender and ask them to confirm their mail server's queue status. For inbound mail to your own server, check your mail server's logs for deferred message queues.
Common Mistakes That Make This Worse
- Setting a high TTL on the new MX record. Always set TTL to 300 (5 minutes) during and immediately after a DNS migration. You can raise it later once everything is stable.
- Forgetting that Cloudflare proxies MX records incorrectly. MX record hostnames must not be proxied through Cloudflare (the orange cloud must be grey / DNS-only). Proxying a mail hostname breaks SMTP entirely.
- Migrating nameservers without exporting the old zone first. Always export a zone file or manually document every DNS record before switching nameservers. Most registrars and DNS providers have an export button.
- Using CNAME for the root domain MX target. MX records must point to a hostname that has an A record, not a CNAME. Using a CNAME as an MX target violates RFC standards and causes unpredictable failures.
- Assuming the new host will auto-configure mail DNS. Many web hosts will configure their own A and CNAME records when you point nameservers to them, but they will not automatically add third-party MX records for services like Google Workspace or Microsoft 365.
Special Case: Email Hosted at a Different Provider Than the Website
This is one of the most common scenarios and the most common source of breakage. Your website is hosted at Provider A, but your email runs through Google Workspace or Microsoft 365. When you point your nameservers to Provider A, their zone template adds their own MX records pointing to their mail servers — overwriting your existing Google or Microsoft configuration.
The fix is straightforward: after pointing nameservers, log in to Provider A's DNS panel and delete their default MX records. Then add the correct MX records for your actual mail provider. Do not touch anything else in the zone unless you know what it does.
How to Prevent This From Happening Again
- Before any DNS change, export your full zone file. Store it in a text file with the date in the filename.
- Lower TTLs for all critical records (MX, A, TXT) to 300 at least 24 hours before the migration, so old records expire quickly after the change.
- Stage the migration: point nameservers first, verify all records in the new zone are correct, then confirm mail flow before considering the migration complete.
- After migration, test MX, SPF, DKIM, and DMARC before announcing success to anyone.
- Raise TTLs back to 3600 or 86400 once everything is stable and confirmed working.
Summary
Email failures after a DNS change almost always come down to missing or incorrect MX records, missing A records for mail hostnames, or lost SPF and DKIM records. The fix is systematic: verify with dig or nslookup, add what is missing, test delivery, and monitor propagation. The whole process can take under 30 minutes once you know what to look for — the hard part is resisting the urge to make additional changes while propagation is still completing, which only creates more confusion. Make the correct change once, verify it, and wait.