换了 nameserver、把 DNS 迁到 Cloudflare、点了一下”Quick Setup 导入”、或者勾选了”用本平台管理邮件”按钮——一个小时内，发到 you@yourdomain.com 的邮件就停了。发件人那边可能收到 550 5.1.1 No such user 或 554 5.4.4 Host not found 的退信，也可能什么都没有，邮件直接被静默丢弃。原因几乎都是同一类：你的 MX 记录被换掉了——可能是空的、占位符、新 DNS 提供商的默认值，或者注册商停放页用的 MX。本文按”是不是 MX 层挂了”→“是哪种 MX 问题”→“怎么按邮件服务商恢复”的顺序排查。
先判断属于哪一种
第一条命令先确认确实是 MX 这层的问题：
dig MX yourdomain.com +short
# 正常（Google Workspace）：
# 1 smtp.google.com.
# 正常（Microsoft 365）：
# 0 yourdomain-com.mail.protection.outlook.com.
# 异常：
# （空） → MX 被清空
# 10 mail.yourdomain.com. → 注册商默认值，主机根本不存在
# 1 mx.cloudflare-email.com. → 被 Cloudflare Email Routing 接管情况 1：DNS 迁移时 MX 没带过来
你把 nameserver 从 Namecheap 换到 Cloudflare，但忘了把 MX 复制到新 zone 里。新的权威 DNS 没有 MX，外面查询自然查不到，邮件被直接拒收。
怎么看：dig MX yourdomain.com +short 返回空，或者 dig +short NS yourdomain.com 看到新 provider，但新 provider 的面板里没有 MX 行。
修复：在当前权威 DNS provider（即 dig 返回的那家）重新添加 MX。值从邮件服务商的接入文档里抄。
情况 2：“Set defaults / Quick scan / 推荐记录”覆盖了 MX
Cloudflare 的 Quick Scan 有时会把你旧 DNS 上的过期 MX 一起导进来。Vercel DNS、Hover、Namecheap 都有”用我们的邮件服务”按钮，会替换 MX。GoDaddy 的 Microsoft 365 接入向导会直接覆盖你已有的 Google Workspace MX，过程中不会警告。
怎么看：MX 存在，但指向的是新 DNS 厂商自己的邮件产品（*.cloudflare-email.com、*.improvmx.com、明明没用 Zoho 却出现 mx.zoho.com）。
修复：删掉自动生成的 MX，粘贴上你实际使用的邮件服务商的正确值，保存。
情况 3：注册商停放页的 MX 又回来了
域名遇到转移或续费时被切到”parking”状态，注册商把 MX 替换成自家停放页用的 MX（mx.park.example.com 这种风格），靠退信来变现。
怎么看：MX 主机名带着注册商的品牌，而不是你邮件服务商的。
修复：删停放 MX，加回真正的 MX，同时关掉所有”parking”、“premium DNS”之类的附加功能。
情况 4：SPF / DKIM / DMARC 同时也被清了
就算 MX 是对的，如果 SPF / DKIM / DMARC 的 TXT 记录也在那次迁移里没了，邮件依然会退或者进垃圾箱：收件方看到 SPF=none、DMARC=fail，直接隔离。
怎么看：
dig TXT yourdomain.com +short | grep -i spf
dig TXT _dmarc.yourdomain.com +short
dig TXT google._domainkey.yourdomain.com +short # selector 按实际改三个都空，说明那次迁移把它们一锅端了。
修复：从服务商文档（或最近一次 zone 导出）里把三条 TXT 全部补回来。
情况 5：通配 CNAME 把邮件子域名也吃掉了
不太常见：你加了 *.yourdomain.com CNAME → your-site.netlify.app。结果 mail.yourdomain.com（某些 MX 主机名和 autodiscover 会用）解析到你的网站托管而不是邮件服务器。
怎么看：dig mail.yourdomain.com 返回的是网站 IP。SMTP 握手会因为对面是 web 服务器而失败。
修复：显式给 mail.yourdomain.com 加一条 A 记录指向真实邮件服务器，让具体记录优先于通配。
最短修复路径
按命中率排序：
- 找邮件服务商要的 MX 值 —— Google Workspace、Microsoft 365、Zoho、Fastmail、ProtonMail 都在接入文档里写得很清楚，照抄优先级 + 主机名。
- 在当前权威 DNS provider 上添加 ——
dig NS yourdomain.com +short返回的那家。除非注册商 = DNS provider，否则不要在注册商面板加。 - TTL 先设 300（5 分钟） 方便验证，确认通了再升到 3600。
- 同时把 SPF / DKIM / DMARC 一起补回来，如果它们也被清了。
- 10–30 分钟后测：从一个 Gmail / Outlook 账号发一封新邮件到
you@yourdomain.com。用 mxtoolbox.com/SuperTool 确认 MX 已经在全球生效。
各服务商 MX 速查
| 服务商 | MX 记录 |
|---|---|
| Google Workspace | 1 smtp.google.com. |
| Microsoft 365 | 0 yourdomain-com.mail.protection.outlook.com. |
| Zoho Mail | 10 mx.zoho.com. 20 mx2.zoho.com. 50 mx3.zoho.com. |
| Fastmail | 10 in1-smtp.messagingengine.com. 20 in2-smtp.messagingengine.com. |
| ProtonMail | 10 mail.protonmail.ch. 20 mailsec.protonmail.ch. |
| Cloudflare Email Routing | 在 Email Routing 仪表盘里查（每个 zone 不同，不要直接抄） |
Microsoft 365 的 tenant 前缀要换成你自己的，比如 mycompany-com.mail.protection.outlook.com.。
怎么确认修好了
# 1. MX 在全球都已经回来
dig MX yourdomain.com @8.8.8.8 +short
dig MX yourdomain.com @1.1.1.1 +short
# 2. MX 目标的 SMTP 握手正常
nc -vz smtp.google.com 25
# 或
openssl s_client -starttls smtp -connect smtp.google.com:25
# 3. 端到端：从另一个域名发一封测试邮件
# 然后看垃圾箱 + Gmail 的"显示原始邮件" → SPF/DKIM/DMARC 全部 pass如果 MX 是对的但邮件还是进垃圾箱，下一层要查的就是 SPF / DKIM / DMARC 的 TXT。
故障期间该怎么和用户说
MX 挂掉那段时间发到你域名的邮件，命运分三种：
- 硬退：发件人收到了不可送达通知。他们知道。在意的会重发。
- 软退并排队重试：靠谱的邮件服务器会重试 24–72 小时。MX 修好、TTL 过期后，队列会自动 flush，你会收到这部分延迟的邮件。
- 静默丢弃：少见，但如果 MX 返回的是一个语法合法但无法连接的主机，就会发生。这部分邮件真的丢了。
所以：修 MX → 等一天 → 大多数排队邮件会陆续到。同时通知客户和合作方，那段时间发的可能需要重发。
预防
- 任何 DNS 迁移前先导出完整的 zone 文件。 多数 provider 都有”导出 BIND”或”导出 zone”按钮，把原始文本存进团队文档。
- 不要在没逐行确认的情况下用”Quick scan / 导入 / 设默认”按钮。 Cloudflare 的扫描会漏掉藏在 WAF 后面的记录，导入看着完整其实并不全。
- 加监控。 UptimeRobot、Better Stack、
mxtoolbox都有免费 MX 监控，MX 一空或一变 5 分钟内告警。 - 稳态下 MX 的 TTL 用 3600 或更高，只在迁移时短期降到 300。 稳定的 MX 用低 TTL 只会增加查询负担。
- 把官方 MX 值连同 SPF / DKIM / DMARC 一起写进团队 ops 文档，任何人需要恢复时都能从已知良好的源头拿到。
FAQ
问：恢复 MX 之后多久邮件能恢复正常？ 答：取决于上一次 TTL。如果原来 MX 的 TTL 是 3600，收件方的 resolver 可能还会在最长 1 小时内继续返回空/错的答案。绝大多数行为规范的发件服务器会重试 24–72 小时，所以排队的邮件最终会补上。新发的入站邮件 5 分钟内就能进来，长尾要到一天后。
问：我对照文档加的 MX 看着一模一样，但邮件还是退。怎么办？
答：检查结尾的点号。某些 DNS 界面里 smtp.google.com 没加尾点会被当成 smtp.google.com.yourdomain.com。再检查优先级是整数而不是文本。最后确认有没有藏在”Show more”折叠下的旧 MX 行没删干净。
问：Cloudflare 让我免费用他们家邮件，要切吗？
答：Cloudflare Email Routing 是转发器，不是真正的信箱。适合 you@yourdomain.com → you@gmail.com 这种别名场景。如果你要的是能收发的真信箱，留在 Google Workspace / M365 / Zoho 这类托管邮件上。
问：能不能同时指向两个邮件服务商？ 答：技术上可以，但优先级最低的会被先尝试，把 Google Workspace 的 MX 和 Microsoft 365 的 MX 混在一起几乎一定会丢信。迁移要么单向切换，要么在事先规划好的重叠窗口内同时挂两套 MX，迁完立刻收一套。
问：dig MX 返回的是正确值，但邮件服务商面板还说”MX 未验证”。
答：服务商的验证探针对失败结果有 5–30 分钟缓存。点一下他们面板上的”Re-check”，或者等。一小时之后还失败的话，用服务商自己的 DNS resolver 查一遍（少数服务商用自家 DNS 基础设施，比公共 resolver 慢）。