网站正常，邮件客户端却连不上：邮件主机名不能走普通 Cloudflare 代理

域名接入 Cloudflare 后，网站能打开，Thunderbird 或 Outlook 却连接 SMTP、IMAP 失败，甚至在检查密码时一直等待。先查看客户端使用的邮件主机名解析到哪里：普通 Cloudflare HTTP 代理不能转发这些邮件协议，橙云代理的 mail.example.com 可能把客户端引向错误入口。

这篇针对使用独立邮件服务器或邮件服务商、DNS 在 Cloudflare 管理的部署。明确配置了 Spectrum 等其他传输产品的情况，需要按其方案检查，不能与普通网站代理混用。

MX 是 DNS only，不代表目标主机也正确

MX 告诉外部服务器邮件投递到哪个主机；邮件客户端配置里的收发服务器名称，又可能与 MX 不同。两条路径都要核对。

以下是只读查询示例，域名需要替换：

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

将结果与邮件服务商提供的主机名和地址比较。MX 本身始终是 DNS only，但它指向的名称如果最终返回普通 Cloudflare 代理地址，邮件连接仍可能走错位置。客户端使用的名称也要单独查，不能只检查 MX。

如果 mail 是指向网站根域的 CNAME，而根域走橙云代理，仅把这条 CNAME 的代理状态改为 DNS only，也不等于它最终就能得到真实邮件服务器。应沿实际名称链检查最终地址，确认目标确实用于邮件。

IPv4 正确、IPv6 仍指向错误主机，也可能让不同网络或客户端得到不同结果。检查已有 AAAA 是否为服务商认可且可用的邮件地址，不能凭一次 IPv4 连接成功就结束。

按邮件服务商配置修正邮件入口

如果服务商要求自行配置 mail.example.com，将它的 A、AAAA 设置为实际邮件服务器地址，并保持 DNS only。MX 再按服务商要求指向正确邮件接收主机，优先级和域名均使用已确认值。

下面仅展示结构关系，地址是文档占位值：

A    mail          192.0.2.25       DNS only
MX   example.com   mail.example.com DNS only

它不是适用于所有服务商的现成记录。有些托管邮件要求 MX 直接指向其服务域名，客户端也使用服务商的统一主机名；这时不要擅自新增自己的 mail 地址来替代它们。

不要从一次 PTR 查询猜出应长期使用的邮件入口，也不要为了修邮件把网站根域一起取消代理。网站和邮件可以采用不同主机名与处理路径。

添加 SRV 记录不会让普通 Cloudflare 网站代理自动转发 SMTP 或 IMAP。客户端是否使用服务发现，与实际 TCP 连接能否到达邮件服务是不同事项，不能用更多记录掩盖错误目标。

DNS 修好后，把 TLS 和账户错误分开

名称解析已经指向正确邮件服务，但仍无法连接时，继续确认服务商指定的端口、TLS 模式和访问限制。自动识别到一个配置，不代表它适用于当前邮箱；使用服务商给出的明确设置重新核对。

证书主机名不匹配时，使用服务商支持且受证书覆盖的邮件主机名，或由服务器管理员正确配置证书。不要取消证书验证或忽略告警来让客户端登录。网页 HTTPS 正常也不能证明邮件端口使用的是同一张证书。

连接和 TLS 建立后仍提示认证失败，再核对用户名格式、密码和所需的应用凭据。DNS 不会修复真正的认证错误。外部邮件仍有退信，则读取退信中的投递原因，不能一直围绕客户端密码排查。

变更只覆盖确认过的邮件记录

修改前保存原记录、代理状态及服务商要求。已经启用 Cloudflare Email Routing 的域名，还要检查托管的 MX 是否符合当前收件方案，不要把两套邮件服务的 MX 混在一起。SPF、DKIM、DMARC 等认证记录也不要作为本次连接故障的通用清理对象。

DNS only 会公开实际目标地址。若邮件与网站共用同一台主机，应同时检查原有的网络访问策略；不能既要求邮件直接连接真实地址，又假设这个地址仍被网站代理隐藏。

验收应确认权威及实际使用的解析器都返回预期目标，客户端完成合格的 TLS 与登录，实际发送、收取测试邮件也正常。旧解析缓存可能暂时保留原地址；先确认发布结果正确，再按已有 TTL 观察。

需要恢复时，按保存的配置还原正确邮件服务入口和客户端设置，保留仍有效的邮箱数据。把邮件名称重新打开普通橙云代理可能再次引入原故障，不能把“恢复图标颜色”当作恢复服务。