换了 nameserver、把 DNS 迁到 Cloudflare、跑了一次 “Quick Scan” 导入，或者勾了”用本平台管理邮件”按钮——一个小时内，发到 you@yourdomain.com 的邮件就停了。发件人那边会收到延迟退信，比如 554 5.4.4 [internal] no relevant MX records found for domain 或 550 5.1.10 RESOLVER.ADR.RecipientNotFound，也可能什么都没有（静默排队，然后被丢掉）。原因几乎都是一类：你的 MX 记录被换掉了——可能是空的、占位符、新 DNS 提供商的默认值，或者注册商停放页用的 MX。
最快的修法： 跑一句 dig MX yourdomain.com +short。如果返回空，或者主机不对，就去 dig NS yourdomain.com +short 指出的那家权威 DNS，重新加上你邮件服务商的准确 MX（见下表），验证期间把 TTL 设成 300，10–30 分钟后发一封测试邮件。本文按”是不是 MX 这层挂了”→“是哪种 MX 问题”→“怎么按服务商恢复”来走，覆盖 Google Workspace、Microsoft 365、Zoho、Fastmail、Proton 和自建。
先看退信内容——它会告诉你问题在哪一层
错误字符串能在你动 DNS 之前先缩小范围：
| 发件人看到的退信 | 含义 |
|---|---|
554 5.4.4 ... no relevant MX records / Host not found | 没有 MX（或 MX 主机解析不出来）——正是本文 |
550 5.1.1 / 550 5.1.10 RecipientNotFound / “user unknown” | MX 是通的，是那个信箱不存在。不是 DNS 问题——去邮件服务商那边查地址/账号。 |
421 / “temporarily deferred” / “will retry” | 软失败；邮件在排队重试。MX 刚出问题的第一个小时里，常常先看到这个，之后才硬退。 |
看到 550 5.1.1 说明你域名的邮件基础设施还在工作，MX 大概率没问题，你走错文章了。5.4.x 的 “no route / host not found” 才是 MX 缺失的典型特征。
先判断属于哪一种
第一条命令先确认确实是 MX 这层出了问题：
dig MX yourdomain.com +short
# 正常（Google Workspace，单条写法，2023 年 4 月起）：
# 1 smtp.google.com.
# 正常（Google Workspace，老的 5 条写法——依然有效，别去"修"它）：
# 1 aspmx.l.google.com.
# 5 alt1.aspmx.l.google.com.
# 10 alt3.aspmx.l.google.com. ...等等
# 正常（Microsoft 365）：
# 0 yourdomain-com.mail.protection.outlook.com.
# 异常：
# （空） → MX 被清空
# 10 mail.yourdomain.com. → 注册商默认值，指向一个根本不存在的主机
# 13 route1.mx.cloudflare.net. → 被 Cloudflare Email Routing 接管注意，Google 那套老的 5 条（aspmx.l.google.com 加 alt1–alt4）截至 2026 年 6 月仍然完全支持——看到它就说明是对的，别动。Google 是在 2023 年 4 月新增了单条 smtp.google.com 作为更简单的写法，并不是要取代老的那套。
情况 1：DNS 迁移时 MX 没带过来
你把 nameserver 从 Namecheap 换到 Cloudflare，但忘了把 MX 复制到新 zone 里。新的权威 DNS 没有 MX，外面查不到，邮件被直接拒收。
怎么看：dig MX yourdomain.com +short 返回空，同时 dig +short NS yourdomain.com 看到的是新 provider，但那家面板里没有 MX 行。
修复：在当前权威 DNS provider（即 dig 返回的那家）重新添加 MX，值从邮件服务商的接入文档里抄（见下表）。
情况 2：“Set defaults / Quick Scan / 推荐记录”覆盖了 MX
Cloudflare 的 “Quick Scan” 有时会把你旧 DNS 上的过期 MX 一起导进来，或者在你启用 Email Routing 的那一刻直接替换掉（它会注入 route1/route2/route3.mx.cloudflare.net）。Vercel DNS、Hover、Namecheap 都有”用我们的邮件服务”按钮，会替换 MX。GoDaddy 的 Microsoft 365 接入向导会直接覆盖你已有的 Google Workspace MX，过程中没有明确警告。
怎么看：MX 存在，但指向的是 DNS 厂商自己的邮件产品——*.mx.cloudflare.net、*.improvmx.com，或者明明没用 Zoho 却出现 mx.zoho.com。
修复：删掉自动生成的 MX，粘贴上你实际使用的服务商的正确值，保存。如果是 Cloudflare Email Routing 把域名接管了、而你又不想要它，先在 Email > Email Routing 里把 Email Routing 关掉，否则一保存它又会把自己的 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 按服务商实际改三个都空，说明那次迁移把它们一锅端了。（注意 selector 因服务商而异——Google 用 google，Microsoft 用 selector1 / selector2 这种 CNAME，Fastmail 用 fm1/fm2/fm3。）
修复：从服务商文档或最近一次 zone 导出里，把三条全部补回来。
情况 5：通配记录把邮件子域名也吃掉了
不太常见：你加了 *.yourdomain.com CNAME → your-site.netlify.app。结果 mail.yourdomain.com 或 autodiscover.yourdomain.com 解析到了你的网站托管，而不是邮件服务器，于是 SMTP/autodiscover 连到一台 web 服务器，握手失败。
怎么看：dig mail.yourdomain.com 返回的是网站 IP / 主机。
修复：给那个邮件用的子域名加一条明确的记录（指向真实邮件服务器的 A/CNAME，或服务商要求的 autodiscover CNAME）。精确名称的记录永远优先于通配，所以具体那条会胜出。
最短修复路径
按命中率排序：
- 找服务商要求的 MX。 Google Workspace、Microsoft 365、Zoho、Fastmail、Proton 都在接入文档 / 管理后台里写得很清楚，照抄优先级 + 主机名。
- 在当前权威 DNS provider 上添加 ——
dig NS yourdomain.com +short返回的那家，不是注册商（除非注册商 = DNS provider）。 - 先删掉其他所有 MX 行。 两家服务商的 MX 混在一起一定会丢信。Microsoft 在 Exchange Online 上明确只支持每个域名一条 MX。
- TTL 先设 300（5 分钟） 方便验证，确认通了再升到 3600。
- 同一次把 SPF / DKIM / DMARC 的 TXT 也补回来，如果它们也被清了。
- 10–30 分钟后测：从一个 Gmail / Outlook 账号发一封新邮件到
you@yourdomain.com，再用 mxtoolbox.com/SuperTool 确认 MX 已在全球生效。
各服务商 MX 速查（2026 年 6 月核对）
| 服务商 | MX 记录 | 说明 |
|---|---|---|
| Google Workspace（当前） | 1 smtp.google.com. | 一条。别再保留下面那套老记录。 |
| Google Workspace（老版） | 1 aspmx.l.google.com. 5 alt1.aspmx.l.google.com. 5 alt2.aspmx.l.google.com. 10 alt3.aspmx.l.google.com. 10 alt4.aspmx.l.google.com. | 依然有效。和单条二选一，不要两套都留。 |
| Microsoft 365 | 0 yourdomain-com.mail.protection.outlook.com. | tenant 前缀换成你自己的；准确值从管理后台抄。 |
| Zoho Mail | 10 mx.zoho.com. 20 mx2.zoho.com. 50 mx3.zoho.com. | TLD 随数据中心而变——.eu/.in/.com.au 等，以 Zoho Admin Console 显示的为准。 |
| Fastmail | 10 in1-smtp.messagingengine.com. 20 in2-smtp.messagingengine.com. | 只这两条。 |
| Proton Mail | 10 mail.protonmail.ch. 20 mailsec.protonmail.ch. | |
| Cloudflare Email Routing | 13 route1.mx.cloudflare.net. 37 route2.mx.cloudflare.net. 61 route3.mx.cloudflare.net. | 启用 Email Routing 时 Cloudflare 会自动加；SPF 里要 include:_spf.mx.cloudflare.net。 |
Microsoft 365 的实时值在管理后台 Settings > Domains > [你的域名] > DNS records 里，显示为 MX 的 “Points to address”。Zoho 在 Admin Console > Domains > [域名] > Email Configuration / DNS Mapping 里。
怎么确认修好了
# 1. MX 在多个公共 resolver 上都已回来
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
# 或者看 banner + STARTTLS：
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），就会发生。这部分邮件真的丢了。
所以：修好 MX → 等一天 → 大多数排队邮件会陆续到。同时告诉客户和合作方，那段时间发的可能需要重发。
预防
- 任何 DNS 迁移前先导出完整的 zone。 多数 provider 都有”导出 BIND”/“导出 zone”按钮，把原始文本存进团队文档。
- 不要在没逐行确认的情况下信任 “Quick Scan / 导入 / 设默认”。 Cloudflare 的扫描会漏掉藏在 WAF、代理后面的记录，导入看着完整其实并不全。
- 永远不要把 MX 走 Cloudflare 代理（保持灰云，不要橙云）——被代理的 MX 会让入站邮件断掉。
- 加监控。 UptimeRobot、Better Stack、mxtoolbox 都有免费 MX 监控，MX 一空或一变几分钟内就告警。
- 稳态下 MX 的 TTL 用 3600 或更高，只在迁移时短期降到 300。 给稳定的 MX 用低 TTL 只会增加查询负担。
- 把官方 MX 值连同 SPF/DKIM/DMARC 一起写进 ops 文档，任何人都能从已知良好的源头恢复。
FAQ
恢复 MX 之后多久邮件能正常？ 取决于上一次的 TTL。如果原来那条（坏掉的）MX 的 TTL 是 3600，部分 resolver 可能还会在最长一小时内返回旧答案。新发的入站邮件通常在生效后约 5 分钟内开始进来；行为规范的发件方会重试 24–72 小时，所以排队的长尾会在接下来一天里补上。
我对照文档加的 MX 一模一样，但邮件还是退。
检查结尾的点号——某些 DNS 界面里 smtp.google.com 没加尾点会被当成 smtp.google.com.yourdomain.com。确认优先级是整数而不是文本。再确认没有藏在 “Show more” 折叠下没删干净的旧 MX 行，并且只留了一家服务商的 MX 而不是两家。
Cloudflare 让我免费用他们家邮件，要切吗？
Cloudflare Email Routing 是转发器，不是信箱。适合 you@yourdomain.com → you@gmail.com 这种别名，但你不能用它从自己域名发信。如果你要的是能收能发的真信箱，留在 Google Workspace / Microsoft 365 / Zoho / Fastmail。
能不能同时指向两个邮件服务商？ 只有优先级数字最小的主机会被先尝试，溢出时才轮到下一个，所以把（比如）Google Workspace 和 Microsoft 365 的 MX 混在一起一定会让邮件分裂、丢失。选一家。规划好的迁移期间可以短暂同时挂两套，迁完干净切到单一服务商。
dig MX 返回的是正确值，但服务商面板还说”MX 未验证”。
服务商的验证探针对失败结果有 5–30 分钟缓存。点一下”Re-check”，或者等。一小时后还失败的话，用服务商自己的 resolver 查一遍——有些服务商的 DNS 基础设施比 8.8.8.8 这类公共 resolver 慢。