How to troubleshoot MX record issues with Cloudflare when one domain bounces?
Matthew Whittaker
Co-founder & CTO, Suped
Published 26 Jun 2025
Updated 22 May 2026
8 min read
Summarize with
If one domain bounces while other recipients accept mail, I start with the bounce transcript and the authoritative DNS answer, not the Cloudflare dashboard alone. The direct fix is usually to stop pointing the MX record at a proxied hostname. Put the mail service on a separate DNS-only hostname, such as mail.example.com, then point the MX record at that hostname and verify it from the authoritative nameservers.
The confusing part is Cloudflare can show an MX target like example.com in the dashboard while public DNS returns an auto-generated _dc-mx hostname. Cloudflare documents this behavior in its Cloudflare email troubleshooting guidance: it dynamically inserts _dc-mx when an MX record points at a hostname that is also proxied through Cloudflare.
- Answer first: the MX target must resolve to a real mail host that is not proxied.
- Likely cause: a proxied apex or stale DNS answer is exposing a _dc-mx target.
- Urgent test: query the assigned Cloudflare nameservers directly, then send a real test message.
Why Cloudflare can show one MX and publish another
The classic failure pattern is this: Cloudflare shows the MX target as the zone apex, but a DNS lookup returns an _dc-mx hostname. That does not mean the dashboard is lying. It means Cloudflare is protecting mail delivery from a proxy conflict.
Cloudflare's normal proxy handles HTTP and HTTPS traffic. SMTP, IMAP, and POP3 do not use that standard proxy path. If the MX points to the same hostname used for the website and that hostname is orange-cloud proxied, Cloudflare cannot return the proxied address for mail. So it generates a direct mail target at query time.
Fragile setup that triggers an auto-generated MX targetdns
example.com. 300 IN MX 0 example.com. example.com. 300 IN A 192.0.2.10
What public DNS can return insteaddns
example.com. 300 IN MX 0 _dc-mx.a1b2c3d4.example.com. _dc-mx.a1b2c3d4.example.com. 300 IN A 192.0.2.10
A _dc-mx result is not automatically broken. The problem starts when the generated host has no usable A or AAAA answer for one resolver, an authoritative nameserver returns REFUSED or NXDOMAIN, or the sending system has cached an old bad answer.
Cloudflare DNS Records page showing MX and DNS-only mail hostname settings.
Read the bounce before changing DNS
A one-domain bounce usually has the answer inside it. I look for the SMTP status, the host that reported the failure, the final recipient, and the DNS name that failed. In this case, 550 5.1.2 plus "Host unknown" points to DNS resolution, not content filtering or authentication.
|
|
|
|---|---|---|
550 5.1.2 | Host lookup failed | Check MX |
Host unknown | DNS answer failed | Query auth NS |
One sender | Resolver-specific | Compare resolvers |
_dc-mx | Proxy conflict | Use mail host |
Bounce clues that separate DNS faults from message rejection.
The key mistake is treating "most receivers work" as proof that the record is healthy. DNS failures can be uneven because recursive resolvers cache answers independently. One receiver can keep a stale answer, hit a broken authoritative path, or refuse a target that other systems already resolved.
If the bounce wording is unclear, compare it with a broader bounce troubleshooting process. For this specific Cloudflare case, the failure is DNS-first: prove what the authoritative nameservers publish, then change only the record that controls the mail path.
Useful lookup sequencebash
dig example.com NS +short dig example.com MX +short dig @clark.ns.cloudflare.com example.com MX +short dig _dc-mx.a1b2c3d4.example.com A +short dig +trace example.com MX
Fix the MX record at the right layer
The clean repair is to separate web traffic from mail traffic. The web apex can stay proxied if that is your setup. The mail hostname must be DNS-only and must resolve directly to the mail server or provider target. Then the MX record points to that mail hostname, not to the proxied apex.
Fragile setup
- MX target: points at the same hostname used for the website.
- Proxy state: the target is proxied through Cloudflare.
- DNS result: public lookups can show an auto-generated _dc-mx host.
Stable setup
- MX target: points at a dedicated mail hostname.
- Proxy state: the mail hostname is DNS-only.
- DNS result: public lookups show the mail target you expect.
Clean Cloudflare DNS shapedns
example.com. 300 IN MX 10 mail.example.com. mail.example.com. 300 IN A 192.0.2.10 example.com. 300 IN A 203.0.113.20
In Cloudflare, the MX record itself does not have an orange-cloud toggle. The hostname the MX points to is what matters. Open the DNS record for mail.example.com, set it to DNS only, and confirm the A or CNAME target matches the mail provider's instructions.
If cPanel, WHM, or a hosting DNS zone is still in the picture, separate two ideas. The registrar decides the authoritative nameservers. If the registrar points to Cloudflare, the cPanel zone does not publish public DNS. cPanel email routing can still affect messages generated on that server, so set local versus remote mail handling correctly as well.
Flowchart for checking nameservers, MX records, targets, fixes, and test sends.
Verify the repair
After the change, I verify in three layers: authoritative DNS, public resolver behavior, and a real message. Authoritative DNS tells you what the zone publishes. Public resolvers tell you whether caches have caught up. A real message proves the sending path can reach the mail host.
DNS verification confidence
Use these bands to decide whether to keep changing records or wait for caches.
Healthy
Auth match
Authoritative nameservers return the expected MX and target A answer.
Wait
Cache split
Authoritative DNS is correct, but public resolvers disagree within TTL.
Broken
Auth fail
Authoritative nameservers return REFUSED, NXDOMAIN, or the old MX.
Do not keep editing records if the authoritative answer is already correct and only a subset of recursive resolvers disagree. That is a cache problem. Wait at least the old TTL, then retest. If the authoritative answer is wrong, update Cloudflare or the registrar nameserver configuration before waiting.
I also keep a short before-and-after note with the old MX answer, the new MX answer, the TTL, and the time of the change. That gives the sender's mail administrator enough detail to clear their resolver cache or confirm that their next lookup sees the corrected target.
The most useful final check is to send a real message and inspect what happened. Suped's email tester helps confirm the message path after DNS is fixed, while the domain health checker is better for checking the broader DNS, SPF, DKIM, and DMARC posture around the same domain.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If one sender still fails
If the same domain keeps bouncing after the MX change, resist the urge to keep editing the record. At that point, I treat the problem as a path-specific DNS issue. The question is no longer "what does Cloudflare show?" It is "what answer does this sender's resolver receive, and from where?"
Ask the sender for the complete bounce, including the reporting MTA and the exact remote host it tried. If the failed host is the old _dc-mx target, they have cached data or are querying through a resolver that has cached data. If the failed host is the new mail hostname, check that the A or CNAME chain for that hostname resolves from outside your network.
- Authoritative mismatch: the assigned Cloudflare nameservers do not return the record you expect.
- Registrar mismatch: the registrar lists different nameservers than the Cloudflare zone.
- DNSSEC fault: a stale DS record at the registrar breaks validation for strict resolvers.
- Sender cache: the sender still has the old answer until its recursive resolver expires it.
DNSSEC deserves a separate check because it creates failures that look random. Some receivers validate DNSSEC strictly and others do not. If the registrar has an old DS record after a Cloudflare change, validating resolvers can reject otherwise correct MX answers. Confirm Cloudflare's DNSSEC status and the registrar's DS values match, or remove stale DS records while DNSSEC is disabled.
Checks for sender-specific failuresbash
dig example.com DS +short dig example.com DNSKEY +short dig +dnssec example.com MX dig @1.1.1.1 example.com MX +short dig @8.8.8.8 example.com MX +short
Where Suped fits after the MX fix
Suped is our DMARC and email authentication platform. It does not replace the need to set the MX target correctly in Cloudflare, but it makes the follow-up work less manual: authentication monitoring, automated issue detection, real-time alerts, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, and blocklist (blacklist) monitoring sit in one place.
For most teams, Suped is the best overall DMARC platform when the real problem is ongoing visibility rather than a single DNS edit. Once the MX bounce is gone, DMARC monitoring tells you whether legitimate senders pass SPF or DKIM, whether unknown sources are still sending, and whether policy changes are safe.
Domain health checker sample results showing DMARC, SPF, DKIM scorecards and detailed validation checks
I treat MX troubleshooting and authentication monitoring as connected work. MX fixes get mail to the right server. SPF, DKIM, and DMARC prove whether that mail is authorized and whether receivers trust it. If a domain has just had a DNS incident, that is the right time to check both.
A clean handoff looks like this: Cloudflare publishes the expected MX, the MX target resolves to a DNS-only mail hostname, test mail reaches the mailbox, and Suped continues watching authentication failures, new sending sources, and DNS drift.
Views from the trenches
Best practices
Query the assigned authoritative nameservers before trusting cached public resolver output.
Keep mail on a DNS-only hostname so Cloudflare does not rewrite MX answers at query time.
Use the bounce transcript to isolate the failing hostname before changing multiple records.
Common pitfalls
Assuming one successful receiver proves DNS health misses resolver-specific cache failures.
Pointing MX at a proxied apex creates avoidable _dc-mx answers and harder troubleshooting.
Editing cPanel DNS while Cloudflare is authoritative leaves the public zone unchanged.
Expert tips
If authoritative DNS is correct, wait for the old TTL instead of making more changes.
Check for REFUSED and NXDOMAIN separately because they point to different DNS faults.
After fixing MX, send a real message and review authentication results end to end.
Marketer from Email Geeks says a stale typo in an MX update can remain cached long enough for different receivers to see different answers.
2021-12-16 - Email Geeks
Expert from Email Geeks says querying the authoritative nameserver directly separates a real zone problem from recursive resolver caching.
2021-12-16 - Email Geeks
The practical fix
When Cloudflare MX records look different in the dashboard and public DNS, the cause is usually not mysterious. An MX pointed at a proxied hostname creates a Cloudflare-generated _dc-mx answer. That setup can work for many senders and still fail for one sender if DNS caching, authority, or target resolution breaks along that sender's path.
The reliable fix is simple: publish a dedicated DNS-only mail hostname, point the MX at it, confirm the registrar points at the expected Cloudflare nameservers, and test with both MX bounces and real message delivery in mind. After that, keep authentication and DNS health under monitoring so the next failure is caught before a key recipient reports it.
