摘要

  • 在一份热门域名样本中，Google Workspace 与 Microsoft 365 合计承接了 38.6% 的 MX 域名；这是域名占比，不是邮箱、邮件数量或全球流量占比。
  • 集中度只是共同暴露面的信号。真正的韧性取决于机构能否在经过演练的时间内迁移路由、认证、管理身份与留存邮件。

电子邮件基础设施的集中化并不需要查看供应商内部数据。许多变化都写在公开 DNS 里。Internet Society Pulse 在 8 月 25 日重新发布的一项测量显示：在 2026 年 7 月 18 日的样本快照中，Google Workspace 占发布 MX 记录域名的 21.8%，Microsoft 365 占 16.8%，两者合计 38.6%。排名其后的已识别服务商 Proofpoint 只有 1.9%。与此同时，被归类为自托管的比例从 2016 年的 44.6% 降至 22.4%，而且仅此前 30 天又下降了 0.5 个百分点。

这个差距说明大量机构已经把同一种关键功能交给很少几家平台，但它并不能直接证明一次故障会让 38.6% 的全球邮件消失。

这项测量看见了什么

MX 记录指定一个域名通过哪个邮件传输系统接收邮件。分析流程读取优先级数值最低的 MX 主机名，用开放的服务商词典识别它，同时分析 SPF 与 DMARC。一次典型的日度运行大约发现 65.9 万个带 MX 的域名和 61.8 万个带 SPF 的域名。

数据来源具有较好的可追溯性。OpenINTEL 至少每天测量一次当前的 Tranco 前一百万域名列表，并在其他 DNS 记录之外保存 MX 答案。Tranco 则把四个来源排名在 30 天内加以汇总，并保存可引用的列表标识。研究者因此可以明确自己观察的是哪一个样本，而不是把“前一百万”当成固定不变的互联网总体。

分母仍然必须说清楚。38.6% 指的是这份热门域名样本中发布 MX 的域名，并不是全世界 38.6% 的用户、邮箱、邮件或收入。Tranco 的不同来源采用不同采集方式，样本对美国和欧洲的热门网站有所偏重。识别流程也有盲区：客户自定义的主机名、分析器未展开的 CNAME、被压平为 IP 段的 SPF，或者白标网关，都可能掩盖底层服务商。因此所谓长尾既包含真正的分散，也包含尚未识别的集中。

改一个 MX 远远不够

邮件迁移需要协调多套状态。机构要预置新的 DKIM 密钥，修改 SPF，维持 DMARC 对齐，迁移用户与群组，导出历史邮件，重建保留规则，重新连接发送邮件的应用，并确保紧急恢复账号不依赖原服务。切换期间，旧服务商可能仍保存排队邮件，新服务商则已经开始接收。DNS 的 TTL 只是其中一只时钟。

SMTP 的存储转发机制也使风险不等于即时中断。接收端短暂不可用时，发送服务器通常会排队并重试。因此，一次短故障不必然造成邮件丢失。实际影响取决于持续时间、发送方重试上限、过滤行为、管理员能否登录，以及机构能否在队列过期前恢复接收能力。

两家服务商的高占比仍然很重要，因为它形成宽广的共同边界：一次平台故障、一项过滤规则或一项账号控制决定，可能同时影响许多机构。但 MX 份额没有告诉我们其中多少机构保留独立的管理员身份、近期导出、备用收信路径或完整切换演练。

自托管不是自动答案

自托管下降也反映了现实选择。大型服务商能够共同承担反滥用、可用性工程、认证工具与值守成本，许多机构不愿自行复制这些能力。一个名义上独立的小型邮件服务器，可能只依赖一名管理员、一条上游链路和一份从未恢复过的备份，韧性反而更低。

真正有意义的区分不是“云端还是自建”，而是“依赖是否可逆”。机构可以使用大型平台，同时把域名控制、紧急身份、可导出的历史记录与切换计划放在同一故障边界之外；也可以在自托管环境中完全没有退出路径。所有权标签不能替代恢复证据。

这项测量已经把集中度变成了可见事实。下一步应当测量的，是每个域名恢复或迁移完整邮件能力所需的时间与完整度。

资料来源