Why are my emails bouncing after a DNS change?

Emails usually bounce after a DNS change because a mail-related record was lost or altered in the move. The most common causes are MX records that weren't recreated at the new DNS provider, an MX record pointing at a hostname that no longer resolves, an SPF record that was deleted or merged incorrectly, missing DKIM keys, and a DMARC policy that now rejects your own mail because SPF and DKIM fail. To fix it, read the bounce message to see whether it's incoming or outgoing mail failing, compare your current MX, SPF, DKIM and DMARC records with what your email provider requires, and restore anything missing.

The trigger is often something that seems unrelated to email, such as moving a website to a new host or switching nameservers to a CDN. Website records get copied carefully, while the TXT and MX records that keep email working are forgotten. This guide shows you how to read the bounce, which records to check, the commands to check them, and how to make future DNS changes without breaking mail.

Step 1: Read the Bounce Message

A bounce (also called a non-delivery report, or NDR) contains a status code and a short explanation. It tells you which direction is failing and roughly why.

Incoming Mail Is Bouncing

If people who email you get bounces, the sending server couldn't deliver to your domain. DNS-related messages look like these:

Host or domain name not found. Name service error for name=example.com type=AAAA: Host not found

connect to example.com[198.51.100.20]:25: Connection refused

connect to mail.example.com[192.0.2.25]:25: Connection timed out

The first means senders can't find a mail server for your domain at all. The second is a sign that there's no MX record and senders have fallen back to your website's address (more on that below). The third means they found a mail server, but it's an old or wrong one that isn't accepting mail.

Outgoing Mail Is Bouncing

If mail you send is rejected, the receiving server distrusts your domain. Authentication failures look like these:

550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy.

550 5.7.509 Access denied, sending domain example.com does not pass DMARC verification and has a DMARC policy of reject.

550 5.7.1 SPF check failed

The first is from Gmail and the second from Outlook.com. Both mean your SPF and DKIM checks failed and your DMARC policy told the receiver to reject the message.

Bounce or Delay?

Mail servers retry temporary failures for several days before giving up. A 4xx code, or a message saying delivery "has been delayed", means the sender is still trying. A 5xx code is a permanent failure. If you fix DNS quickly, delayed messages are usually delivered on the next retry.

Step 2: Check Your MX Records

MX records tell other mail servers where to deliver email for your domain. Query them:

dig example.com MX +short

A healthy result for Google Workspace looks like this:

1 smtp.google.com.

And for Microsoft 365:

0 example-com.mail.protection.outlook.com.

If you get no output at all, your domain has no MX records, and incoming mail will fail.

Missing MX Records After Changing Nameservers

This is the single most common cause. When you move your nameservers, for example to a CDN or a new web host, the new provider only serves the records you've added there. Some providers scan and import existing records automatically, but scans often miss records, and some providers import nothing.

Confirm which provider is serving your domain:

dig example.com NS +short

When a domain has no MX record, sending servers don't simply give up. The email standards tell them to fall back to the domain's A or AAAA record and try delivering there, which is called the implicit MX. For most domains that address is the web server, which doesn't accept mail on port 25. Senders then get "connection refused" or time out, retry for a while, and eventually bounce the message.

Log in to the provider that's serving your domain and add the MX records exactly as your email provider specifies. If you still have access to the old DNS provider, compare its zone with the new one line by line.

The MX Target Must Resolve

The hostname in an MX record must have an A or AAAA record. If you moved your website and deleted or changed records along the way, the mail hostname may have gone with them:

dig mail.example.com A +short
dig mail.example.com AAAA +short

If the MX points at mail.example.com and that name no longer resolves, senders can't deliver.

MX Records Must Not Point at an IP Address or a CNAME

An MX record must contain a hostname, not an IP address. And according to the DNS standards, that hostname must not be a CNAME. Some sending servers tolerate a CNAME, but many don't. If your new DNS provider made you enter the record differently, check it:

dig mail.example.com CNAME +short

If that returns a value, point the MX directly at the final hostname instead.

Stale MX Records Pointing at the Old Server

If you moved email to a new provider at the same time, senders with a cached copy of the old MX record keep delivering to the old server until the TTL expires. That mail may be accepted by the old server, so it doesn't bounce, but it doesn't arrive in your new mailbox either. Keep the old mailbox active for a few days and check it for stragglers.

Step 3: Check SPF

SPF lists the servers allowed to send mail as your domain. Query it:

dig example.com TXT +short | grep spf1

"v=spf1 include:_spf.google.com -all"

Problems that commonly appear after a DNS change:

1. The SPF record is missing: It didn't get copied to the new DNS provider.
2. There are now two SPF records: Your new host added its own SPF record next to yours. Two v=spf1 records cause SPF to fail with a permanent error. Merge them into one.
3. The new web host isn't included: If your website sends mail itself, such as contact forms or order confirmations, its servers need to be in SPF.
4. Too many lookups: Merging records can push you over SPF's limit of 10 DNS lookups.

Here's an example of merging two records into one:

; Wrong: two SPF records
example.com.  TXT  "v=spf1 include:_spf.google.com -all"
example.com.  TXT  "v=spf1 include:spf.newhost.example ~all"

; Right: one merged record
example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.newhost.example -all"

Step 4: Check DKIM

DKIM public keys live under a selector at <selector>._domainkey.<domain>. The selector depends on your email provider. Common ones include google for Google Workspace and selector1 and selector2 for Microsoft 365:

dig google._domainkey.example.com TXT +short
dig selector1._domainkey.example.com CNAME +short
dig selector2._domainkey.example.com CNAME +short

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

If these return nothing, recreate them from your email provider's admin console. Two things to watch for:

• Long keys split incorrectly: A 2048-bit DKIM key is longer than the 255-character limit for a single TXT string. Some DNS panels split it automatically, others need you to split it into quoted chunks. A corrupted key fails verification.
• CNAME-based keys: Microsoft 365 and many sending services publish DKIM as CNAME records pointing to their own keys. If you've copied them as TXT records, or the CNAME target has a typo, DKIM fails.

You can find the selector used in any message you've sent by viewing its headers and looking for s= in the DKIM-Signature header.

Step 5: Check DMARC

DMARC is what turns SPF and DKIM failures into bounces. Check your policy:

dig _dmarc.example.com TXT +short

"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

With p=reject, any message where neither SPF nor DKIM passes and aligns with your From domain is rejected. Before the DNS change, your records passed. After it, a missing DKIM key or broken SPF record means your own legitimate mail now fails DMARC and bounces.

The right fix is to restore SPF and DKIM. If you need breathing room while you do, you can temporarily relax the policy:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Put it back to quarantine or reject once your DMARC reports show everything passing again.

Step 6: Check MTA-STS and TLS Reporting

If your domain uses MTA-STS, sending servers that support it check a policy file listing your allowed mail servers. You'll have a TXT record at _mta-sts.example.com and a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt:

dig _mta-sts.example.com TXT +short
curl -s https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Two DNS changes can break this:

• Changing MX without updating the policy: In enforce mode, senders refuse to deliver to an MX host that isn't listed. Mail is queued and eventually bounces.
• Moving the website and losing the mta-sts subdomain: If the policy file is no longer reachable over HTTPS with a valid certificate, senders that have cached a policy keep using it until its max_age expires, while new senders can't fetch it.

When changing mail providers, update the policy file's mx lines first, then change the record's id value so senders fetch the new policy.

Step 7: Check Reverse DNS for Self-Hosted Mail

If you run your own mail server and changed hosting providers or IP addresses, the new IP needs a matching PTR record (reverse DNS). Many receiving servers reject or heavily penalise mail from IPs without one:

dig -x 203.0.113.25 +short

mail.example.com.

PTR records are set by whoever owns the IP address, usually your hosting or cloud provider, not in your domain's DNS zone. The hostname it returns should also resolve back to the same IP.

A Quick Health Check Script

This script runs the main checks in one go. Change the domain and DKIM selectors to match yours:

#!/usr/bin/env bash
domain="example.com"
selectors=("google" "selector1" "selector2")

echo "== Nameservers";  dig +short "$domain" NS
echo "== MX";           dig +short "$domain" MX
for mx in $(dig +short "$domain" MX | awk '{print $2}'); do
  echo "   $mx -> $(dig +short "$mx" A | paste -sd' ' -) $(dig +short "$mx" AAAA | paste -sd' ' -)"
done
echo "== SPF";          dig +short "$domain" TXT | grep -i "v=spf1" || echo "   none"
spf_count=$(dig +short "$domain" TXT | grep -ci "v=spf1")
[ "$spf_count" -gt 1 ] && echo "   WARNING: $spf_count SPF records found"
dmarc=$(dig +short "_dmarc.$domain" TXT)
echo "== DMARC";        echo "${dmarc:-   none}"
for s in "${selectors[@]}"; do
  rec=$(dig +short "$s._domainkey.$domain" TXT)
  [ -n "$rec" ] && echo "== DKIM $s: found" || echo "== DKIM $s: not found"
done
echo "== MTA-STS";      dig +short "_mta-sts.$domain" TXT

== Nameservers
ns1.example.net.
ns2.example.net.
== MX
== SPF
   none
== DMARC
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
== DKIM google: not found
== DKIM selector1: not found
== DKIM selector2: not found
== MTA-STS

That output is a typical post-migration picture: DMARC was copied across, but the MX, SPF and DKIM records weren't. Incoming mail fails because there's no MX, and outgoing mail fails because DMARC is set to reject and nothing passes.

How to Change DNS Without Breaking Email

1. Export your zone first: Most DNS providers let you download a zone file. Keep it as your reference.
2. Recreate every record at the new provider before switching nameservers: Pay particular attention to MX, TXT (SPF, DMARC and verification records), DKIM selectors, SRV records, and autodiscover CNAMEs used by Outlook.
3. Compare old and new zones: Query the new provider's nameservers directly, before switching, to confirm they return the same answers:

dig @ns1.newprovider.example example.com MX +short
dig @ns1.newprovider.example example.com TXT +short

4. Lower TTLs in advance if you're also moving mail to a new provider, so stale MX records clear quickly.
5. Watch DMARC reports and bounces for a few days afterwards.

---

FAQ: Emails Bouncing After a DNS Change

---

Conclusion

When email starts bouncing after a DNS change, the cause is almost always a mail record that didn't make the move. Read the bounce first to see whether incoming or outgoing mail is failing, then check MX records and their targets for incoming mail, and SPF, DKIM and DMARC for outgoing mail. If you use MTA-STS or run your own mail server, check the policy file and reverse DNS too.

The best protection is preparation. Export your zone before any change, recreate every record at the new provider and query its nameservers directly before switching, and keep an eye on bounces and DMARC reports for a few days afterwards. That way your website can move freely without your email going with it.