Email can stop working after a DNS change because the active DNS zone may no longer point incoming mail to the right provider—or may be missing records that authenticate outgoing mail. First identify which DNS service is authoritative, then compare its live records with the current email provider’s instructions. The right fix depends on whether you changed nameservers, moved DNS hosting, edited MX records, or migrated email.
Why a DNS change can break email
A domain’s website and email use DNS for different purposes. A nameserver change can make the internet consult a different DNS zone; if that zone lacks the mail records from the old host, email may fail even while the website works. Records still visible in the previous DNS provider’s dashboard have no effect if that provider is no longer authoritative.
MX records direct incoming mail. SPF, DKIM, and DMARC instead help receiving systems assess whether outgoing mail is authenticated and how to handle authentication failures. A missing or incorrect record can therefore affect one direction of email without affecting the other.
Diagnose the symptom before changing records
- No new incoming messages: Check the live MX records and whether they point to the intended provider.
- Outgoing messages bounce or land in spam: Check SPF, DKIM, and DMARC against your provider’s current instructions.
- A mail app cannot connect: Check the provider’s mail-server settings and whether the mail hostname resolves directly to that provider.
- A provider says the domain is not verified: Check the specific verification record it requests; this may be different from the records that route email.
Check the active DNS zone and live MX records
- Find the authoritative DNS provider. Check which nameservers are currently set for the domain. Make any repairs at the DNS provider those nameservers identify—not solely in the old host’s dashboard.
- Query public MX records. For example, Cloudflare documents the command
dig example.com mx +short; replaceexample.comwith your domain. You can also use a DNS lookup tool. - Compare every live MX target and priority with the exact values in your current email provider’s admin console or setup instructions. Don’t copy an example value from another provider or account. Cloudflare recommends checking the public MX answer against the provider’s expected records: Cloudflare’s email troubleshooting guide. Microsoft says to use the domain-specific MX value shown in Microsoft 365 admin center: Microsoft’s domain-connection instructions.
- Look for missing, stale, or competing MX entries. Old mail-provider records may still be present, or a managed email-routing feature may conflict with the provider meant to receive mail. Remove or replace records only after confirming the intended mail setup.
As examples—not universal settings—Cloudflare’s Google Workspace guide lists five MX records: aspmx.l.google.com at priority 1; alt1.aspmx.l.google.com and alt2.aspmx.l.google.com at priority 5; and alt3.aspmx.l.google.com and alt4.aspmx.l.google.com at priority 10. Cloudflare’s troubleshooting guide shows Microsoft 365’s pattern as <your-domain>.mail.protection.outlook.com at priority 0, but directs administrators to confirm their exact value with the provider. Use the live instructions for your account: Cloudflare troubleshooting and Cloudflare’s Google Workspace DNS guide.
#1 Best Overall
Check mail hostnames and routing conflicts
If a mail client cannot connect, check the provider’s required server names and the DNS records for those hostnames. Cloudflare’s standard HTTP proxy does not support SMTP, IMAP, or POP3, so mail hostnames and MX targets must resolve as DNS-only rather than through the standard proxy. Cloudflare also warns that its Email Routing MX records can conflict with another provider’s MX records. Its Google Workspace setup instructions say Google’s MX records cannot coexist with Cloudflare Email Routing: Cloudflare’s Google Workspace DNS guide.
Repair authentication if outgoing mail fails
SPF: authorize all legitimate senders in one record
SPF identifies which services are allowed to send mail for your domain. Publish only one TXT record beginning with v=spf1; if several services send mail, combine their authorized senders in that single record instead of adding a second SPF record. Multiple SPF records can cause authentication failure. SPF also has a limit of 10 DNS lookups; exceeding it can cause a permerror. See Google’s SPF troubleshooting guidance and Microsoft’s SPF setup guidance.
Rank #2
For a domain that sends only through Google Workspace, Google’s example is v=spf1 include:_spf.google.com ~all. If other services send on your behalf, this example is incomplete: include those senders in the same SPF record according to their instructions. Microsoft shows v=spf1 include:spf.protection.outlook.com -all for its documented Microsoft 365 setup. Neither value should be copied blindly to a domain with a different or mixed sending setup. See Cloudflare’s Google Workspace DNS guide and Microsoft’s domain-connection instructions.
DKIM and DMARC: check the provider’s exact records
DKIM lets a receiving system verify a signature on a message; DMARC sets a policy and reporting instructions for messages that fail SPF or DKIM checks. Look up the DKIM selector and record and the DMARC record required for your domain in the provider’s current admin console. A missing or incorrect authentication record may contribute to rejection, spam placement, or inconsistent delivery, but these records do not direct incoming mail. Microsoft lists DKIM CNAME records as optional in its documented domain-connection flow; that does not establish that DKIM is unnecessary for every setup. See Cloudflare’s Google Workspace DNS guide and Microsoft’s domain-connection instructions.
Recommended Free Tools
If email stopped working after an email migration
Changing MX records sends new incoming messages to the destination provider once the change is visible to senders. It does not move old messages from the former provider. Microsoft advises setting up users and mailboxes before changing MX, so the destination is ready when new mail begins arriving. Plan any transfer of existing messages separately. See Microsoft’s domain-connection instructions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Allow for DNS caching, then verify the result
Resolvers may continue using cached DNS answers for a time after records change. Cloudflare says Google Workspace DNS propagation can take up to 48 hours; Google says SPF changes may take 24–48 hours to take effect globally. These are provider guidance windows, not guarantees for every DNS change. Check the public answer again rather than relying only on elapsed time: Cloudflare’s Google Workspace DNS guide and Google’s SPF troubleshooting guidance.
Rank #4
If the live records match your provider’s instructions but email still fails, keep the exact bounce message or mail-client error and contact your email administrator or provider. The error text and current public DNS answers help distinguish a routing problem from authentication, account, or connection issues; Cloudflare likewise recommends escalating unresolved email problems: Cloudflare’s email troubleshooting guide.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
