A working website does not establish that domain email is configured correctly. Compare the domain’s MX answer with the current mail provider’s instructions, then check the hostname the mail client actually uses. Cloudflare’s standard HTTP proxy does not carry SMTP, IMAP or POP3; an MX record is always DNS-only, but its mail target must also resolve through the intended DNS-only path. Keep the website’s proxy setting separate and use the provider’s error or bounce details to decide what to investigate next.
First separate connection failure from message delivery
Start with the symptom rather than changing the domain’s DNS settings as a group. A mail client that cannot connect to its server presents a different question from a client that connects but receives a delivery error. Record the actual server hostname configured for the affected connection and the specific error or bounce. Those details give the mail administrator something concrete to compare with the provider’s instructions.
Cloudflare documents SMTP, IMAP and POP3 as protocols that do not work through its standard HTTP proxy. That makes the path used by the mail hostname relevant to a connection problem. It does not establish that proxying caused every email failure after a DNS move. The mail provider may still need to investigate server configuration or message delivery.
This guide concerns the standard HTTP proxy. It does not describe a separately configured Spectrum deployment, and it is not a test of the reader’s mailbox, credentials or DNS. Use the checks below to identify the relevant evidence and owner before applying a change.
Read the MX answer and follow its target
Compare the domain’s resolved MX answer with the records currently required by the mail provider. Also compare that result with the Cloudflare DNS records page. An absent answer or an unexpected destination is a reason to reconcile the provider’s expected configuration with the authoritative DNS records. It is not a reason to copy an example value from an unrelated hosting guide.
Continue by identifying the hostname to which the MX record points. Cloudflare states that the MX record itself is always DNS-only, but the hostname it points to must also resolve to a DNS-only target. An MX row that looks correct therefore does not complete the investigation of the destination path.
There is another ownership boundary to check: an NS-delegated mail subdomain. Cloudflare explains that NS records can delegate a subdomain to another DNS provider. In that case, the mail server records for the delegated name are managed by the external provider. Editing an unrelated address record in the parent zone does not demonstrate that the delegated mail hostname has been corrected.
Keep three pieces of evidence distinct: the provider’s expected MX values, the answer being resolved, and the authoritative owner of the destination’s address records. A mismatch belongs with the administrator who manages the relevant zone or mail service.
Inspect the hostname used by the mail client
Next, compare the exact SMTP, IMAP or POP hostname configured in the client with the mail provider’s instructions. Do not assume that checking only the MX destination also checked every hostname the client uses. The question is whether the actual connection is following an intended mail path or a path configured for the HTTP proxy.
Cloudflare’s proxy-status documentation distinguishes the record types. A, AAAA and CNAME records used for IP address resolution can be proxied; other types, including MX and TXT, remain DNS-only. This is a description of record capabilities. It does not mean that the MX row has an orange-cloud switch to turn off, or that every address record on the website should be changed.
Use this completed decision table to match the observation to its next owner. Each row calls for evidence before a configuration change.
| Observed situation | Read-only evidence to compare | Next owner / decision |
|---|---|---|
| No MX answer or an unexpected destination | Authoritative MX answer versus current mail-provider setup | Mail administrator: reconcile provider values; do not delete records by guesswork |
| Expected MX, but the mail client cannot connect | Exact SMTP/IMAP/POP hostname and its address or CNAME proxy path | Administrator: assess whether a provider-confirmed mail-only DNS target is needed |
| Mail target under an NS-delegated child | Child zone’s authoritative provider and address records | Delegated-zone owner: inspect the records there, rather than an unrelated parent row |
| Client connects, but messages bounce or are filtered | Specific error or bounce and provider-confirmed authentication requirements | Mail provider or administrator: distinguish delivery checks from proxy diagnosis |
| Proxied website works | Which hostname serves web traffic and which serves mail | Keep web proxy decisions separate; do not grey-cloud the whole site as a blanket fix |
The table does not prescribe universal MX, address or authentication values. It directs each question to the configuration that the relevant provider actually supports. An administrator can then assess the evidence without treating a working website as proof that email is configured correctly.
What this diagnosis does and does not change
Scope any proposed correction to the provider-confirmed mail hostname and the zone that owns it. Do not turn the entire website to DNS-only simply because mail stopped working. For web records, Cloudflare documents that DNS-only exposes the origin IP address and means those requests do not receive its HTTP optimization, caching, protection or HTTP/HTTPS analytics.
That web-traffic consequence is separate from the requirement for mail traffic to follow an appropriate non-HTTP-proxy path. Preserve the distinction when discussing a fix: which hostname is being investigated, which protocol uses it, and which provider has confirmed the intended record?
No setting is changed by the checks in this article. There are no generic MX or SPF values to paste, no credentials to submit here, and no promise that changing a DNS record will restore lost messages or guarantee inbox delivery. If the evidence identifies a mismatch, the mail administrator still needs to decide the correction using the current provider instructions.
Completion evidence and escalation
There are separate outcomes to verify. First, does DNS match the current mail provider’s expected configuration? Second, can the client connection be assessed using its actual hostname and error? Third, if a connection works but delivery still fails, what does the specific bounce or delivery error show?
Do not collapse those outcomes into “email fixed” after inspecting a DNS row. Cloudflare directs operators to the mail administrator or mail provider with the specific error or bounce so that DNS resolution, mail-server configuration and message delivery can be distinguished.
For escalation, collect the hostname used by the client, the relevant MX destination, the authoritative provider for any delegated child, and the error or bounce category. These are the facts the responsible administrator needs to decide which part of the configuration to examine. They are not evidence that a change has already been made or that a test message has arrived.
Why is the MX row already grey-clouded?
Cloudflare documents MX and TXT records as always DNS-only. The mail hostname’s address or CNAME path still needs attention, because the standard HTTP proxy does not carry the mail protocols covered here. An already DNS-only MX record does not by itself resolve that second question.
Should I turn off Cloudflare for the entire website?
This diagnosis is limited to mail hostnames. DNS-only web records expose the origin address and lose the Cloudflare HTTP services described above for those requests. A site-wide proxy change is not the default step for a mail problem; compare the mail provider’s expected path first.
Does correct DNS guarantee successful delivery?
No. The specific error or bounce still matters. Cloudflare’s troubleshooting guidance separates DNS resolution, mail-server configuration and message delivery, and directs that investigation to the mail provider or administrator. This article does not confirm the reader’s account state or a delivery result.
For the source-specific troubleshooting steps and proxy boundaries, use the two official documents: