Exact error diagnosisReviewed 2026-08-07By HostWithShery technical editorial

Email Stopped Working After Moving DNS to Cloudflare

The website can continue working while mail fails if MX and mail-authentication records were not copied to the new DNS zone.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

Email Health Check

This page is preconfigured with the Email Health Check that best matches this problem.

No accountPublic evidence only
Live public check

Checks MX routing plus SPF, DKIM discovery, DMARC, BIMI, MTA-STS and TLS-RPT public signals.

No account · Public configuration only
On this page

What this error means

The website can continue working while mail fails if MX and mail-authentication records were not copied to the new DNS zone. The browser or proxy message describes the symptom, not necessarily the root cause. HostWithShery therefore checks the business-email DNS and mail authentication evidence that can be observed publicly before recommending a configuration change.

Most likely causes

These are the first explanations to test because each can produce this exact symptom. Treat them as hypotheses until the matching public evidence is present.

  • Missing MX recordsRead the public MX priorities and targets, then verify that each target itself resolves. A visible MX record is not enough if its mail hostname is broken.
  • Missing SPF/DKIM/DMARCInspect the single public v=spf1 policy, validate its terms and count DNS-query-causing mechanisms; duplicate policies or excessive lookups can invalidate SPF.
  • Mail hostname accidentally proxiedVerify mail hostname accidentally proxied from the public Internet and compare it with the value the responsible provider says should be live.

What to check on your domain

Use the embedded scan to compare the failing layer with adjacent layers that can produce the same visible error. This prevents a DNS change from being used to “fix” a TLS problem, or an SSL-mode change from masking an origin failure.

  • Missing MX recordsRead the public MX priorities and targets, then verify that each target itself resolves. A visible MX record is not enough if its mail hostname is broken.
  • Missing SPF/DKIM/DMARCInspect the single public v=spf1 policy, validate its terms and count DNS-query-causing mechanisms; duplicate policies or excessive lookups can invalidate SPF.
  • Mail hostname accidentally proxiedVerify mail hostname accidentally proxied from the public Internet and compare it with the value the responsible provider says should be live.
  • Restore the mail provider recordsVerify restore the mail provider records from the public Internet and compare it with the value the responsible provider says should be live.
  • Set mail-only hostnames to DNS-only where requiredVerify set mail-only hostnames to DNS-only where required from the public Internet and compare it with the value the responsible provider says should be live.

Fixes in the recommended order

Change the smallest confirmed layer first. Preserve working DNS and mail records, document the current value, apply one repair, and then retest before moving to the next possibility.

  • 1. Restore the mail provider records. Confirm the public result after this step before making another unrelated change.
  • 2. Set mail-only hostnames to DNS-only where required. Confirm the public result after this step before making another unrelated change.
  • 3. Run the email health check again. Confirm the public result after this step before making another unrelated change.

How to confirm the repair

The public MX/authentication records should match the intended mail provider, required hostnames should resolve, and the relevant SPF/DKIM/DMARC check should no longer show the original failure.

If the error remains

Capture the checked hostname, exact timestamp, final DNS addresses, redirect/TLS result and the failing public status before escalating. That evidence gives a hosting or provider support team something testable instead of only the browser message. If results differ by resolver or network, include those differences rather than assuming the failure is universal.

What not to change

Do not replace nameservers, delete unrelated mail records, disable security controls, remove IPv6 blindly or purge the entire configuration merely because this message appears. Diagnose the failing layer first; broad changes can turn one isolated fault into several independent faults.

Technical references

These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.