摘要

  • MX 记录让邮件地址中的域成为稳定身份，而不再等同于应当连接的那台机器。域可以公布另一台或多台邮件交换机，用户不必跟着服务器改地址。
  • 共同规则很薄：发送端查询 MX，先试数值较小的 preference，把相同数值当作同级，按照自己在列表中的位置截断回路，并在本地安排重试。交换机自身的 MX 不会自动构成责任链。
  • 这种间接层带来运营权力，却不是主权真相。权威 DNS 的控制者能改向来信，缓存让变更不同步，多条 MX 也可能共用同一故障；记录本身既不认证机构，也不加密邮件。

地址曾经也是主机名

RFC 974 用一个已经失效的常识开场：如果邮件写给 LOKI.BBN.COM 上的邮箱，发送程序通常可以直接连接 LOKI.BBN.COM 的 SMTP，把信交过去。地址右侧同时充当公共身份和执行投递的主机。

但这从来不是没有例外的世界。某些 UUCP 和 CSNET 主机并未直接连入互联网，远端 mailer 靠本地配置把邮件转给中继；RFC 974 举出的例子是 CSNET-RELAY.ARPA。1982 年的 RFC 821 已经定义 SMTP 中继、网关与源路由。MX 没有凭空发明存储转发，也没有让一张此前只能直连的网络突然学会备份。

真正扩大的，是例外的维护成本。路径写在各地发送机的配置文件里，目的方就无法通过改一处公开状态，让所有独立 mailer 逐步得知新路径。域名成为稳定地址以后，地址本身回答不了一个运营问题：今天到底由哪台主机接收这个域的邮件？

从两种角色到一组有序候选

RFC 882 与 RFC 883 的早期 DNS 用带类型的资源记录保存信息。邮件路由最初有 MD 与 MF 两种记录：一个表示 mail destination，另一个表示 mail forwarder。它们把“直接目的地”和“转发者”写成固定角色，却不容易表达多台候选和更细的次序。

1986 年 1 月的 RFC 973 用 MX 取代二者。一条 Mail Exchanger 记录包含一个无符号 16 位 preference 和一个交换机主机名。数值小的先试；相同数值表示相同优先级。

这不是数据库字段清理。MD/MF 先给机器分角色，MX 则为一个域公布一组有序的接收者。直接主机、中继和备份都可以放进同一机制，目的域无需让每个发送方安装专用例外。RFC 1035 后来保留了这种紧凑表示：preference 后接 exchange 域名。

共同层没有写完整路径、健康状况或合同。它只给出足够让发送端自行行动的数据。

身份留下，机器可以搬走

RFC 974 的关键句是：域名通常是主机，但不总是。mailer 不能再把邮箱中的域直接当作 SMTP 主机，必须先问 DNS。DNS 可以指向完全不同的机器，也可以返回多个选择。

这让一个组织的邮件身份拥有不同于服务器的寿命。用户仍使用同一域名，运营者却可以替换硬件、迁移机房、引入过滤网关、增加备份或外包收信服务。远端发送者不必理解内部搬迁，只需得到当前 MX，并解析其地址。

这种分离不证明身份天然安全。控制域和权威区文件的人获得了改向来信的实际控制面，错误或恶意变更都可能把邮件交给另一方。但它确实把两种本应不同寿命的事物拆开：通信者认识的公共名字，与今天为它工作的机器。

一次公布，各地分别执行

RFC 974 强烈建议 mailer 每次尝试投递时都查询 MX。目的不是向 DNS 仪式性报到，而是让已经在远端队列里的邮件也能学到新路径。主机故障后，目的域管理员改动 DNS，发送端在下一次尝试时根据各自缓存状态转向新交换机。

执行发生在发送端。它先试 preference 数值最小的目标，再依次尝试后面的可用目标。同一最低数值有多个交换机时，在宣布无法投递前应把它们都试过。RFC 5321 延续并收紧了这个规则：SMTP 客户端必须具备依次尝试和重试相关地址的能力；同级目标没有其他选择理由时应随机化，以分散负载。

preference 不是性能分数。10 比 20 先试，只因为域这样公布，并不表示 10 更近、更快、更空闲或更有权威。备份主机可能物理距离更短，但它仍在管理者规定的投递次序后面。

因此，MX 不是中央邮件路由器。共同层公布一个很小的有序集合，成千上万台独立 MTA 各自执行、排队、重试，并决定临时失败何时变成退信。

“帮助转发”不能变成无限回路

备选路径引入了新的错误：两台 mailer 可能把同一封信互相交还。RFC 974 要求本地主机在 MX 列表里寻找自己。如果自己是其中一项，它必须删除自己的记录以及 preference 数值相同或更大的记录，只能向数值更小、排在自己前面的交换机投递。

假设主交换机是 10，备份是 20。备份临时收下邮件后，可以再试 10；它不能转给另一个 20 或 30，让责任横移或返回。preference 不只是故障转移顺序，也定义了责任可以朝哪个方向移动。

RFC 974 还明确禁止另一种责任扩张：查询只针对原始目的域。发送端不能继续查询某个 MX 目标自己的 MX，再把结果当作更长的中继链。某主机为一个 relay 接收邮件，并不代表它也自动为 relay 所服务的所有域承担责任。

这个非传递规则保护的是明确同意。为某个目的域做 MX 是一项公开运营责任，不能沿 DNS 关系被悄悄继承。

缓存让系统可扩展，也让切换不同时

DNS 靠缓存扩展，所以 MX 变更不会同时到达所有发送者。RFC 974 承认，在 resolver 缓存过期之前，旧记录可能导致短暂回路或错误地判断无法投递。

理论上可以禁止缓存，让每台 mailer 每次都直接询问权威服务器。RFC 认为这不切实际，会让邮件系统成本过高。正确做法是承认异步：加入交换机前协调责任，保证查询答案完整；UDP 答案若被截断，就通过可靠的虚电路重新查询。

缓存并非挡在政策与现实之间的纯粹障碍，它本身是规模机制。运营者控制的是 TTL、旧新服务重叠期和回滚窗口，而不是一个能让全球瞬时切换的开关。记录要经过不同 resolver 和运行中的 mailer，在不同时间成为事实。

没有 MX，历史规则仍会“试试看”

1986 年为了兼容部署，RFC 974 规定：查询没有返回 MX 时，发送端假定存在一条 preference 0、指向原域本身的 MX。RFC 5321 称其为 implicit MX。发送端随后解析这个域的 A 或 AAAA，并尝试 SMTP。

它帮助尚未配置 MX 的域继续收信，却让沉默有了歧义。没有 MX 可能是旧式可用配置、遗漏，也可能是这个域根本不收邮件。发送者不能从缺席推断“没有服务”，于是会对只承载网站等用途的地址反复投递。

现代规则也强调显式数据的边界：如果 MX 已存在但全部不可用，发送端必须报错，不能无视它们再回退到域自身 A/AAAA。MX 目标必须解析出地址记录，通过 CNAME 才得到地址的目标不符合 RFC 5321 的标准范围。

一个点，终于明确表示“不收邮件”

2015 年的 RFC 7505 补上了缺失状态。一个不接受邮件的域只公布一条 preference 0 的 MX，其 exchange 是 DNS 根标签，在区文件中写作 .，并且不能同时公布其他 MX。

这个点不是坏掉的服务器，而是明确的无服务声明。发送方无需回退到 A/AAAA，也不必像 RFC 描述的常见行为那样重试大约一周；它可以立即失败，让寄信人还有机会改正地址，同时节省队列和网络资源。

Null MX 比 RFC 974 晚了 29 年，不能倒写成 1986 年已有的功能。它作为修正才有意义：早期兼容规则把“不参与”和“尚未配置”混成沉默，新的显式状态让域运营者终于能清楚拒绝这一服务。

它也不是 SMTP 的 null reverse-path。把 null MX 用在仍要作为邮件退信地址的域上，可能让接收方拒绝其邮件。

间接层不是无辜层

用户地址不变，管理员却能换掉整套接收系统，这是 MX 的力量，也是风险。掌握权威 DNS 的人可以改向之后的所有来信。多个 MX 名称也未必是独立冗余：它们可能共用供应商、机房、网络、管理账号或过滤政策。

备份 MX 可以在故障时排队，但也扩展了能看见邮件内容和元数据的参与者。DNSSEC 可以保护记录没有被途中篡改，却不能证明接收机构的法律身份、内部处理或最终保密性。SMTP 成功只说明某个交换机在协议边界接受了责任，不证明最终邮箱已存储或用户已阅读。

MX 的正当性更窄：它说明一个域当前希望互联网 mailer 把责任交给谁、按什么顺序，以及后来补充的“这里没有邮件服务”。这些信息足以协调独立系统，却不足以把 DNS 管理者塑造成身份与真相的主权者。

最小而有用的邮件地图

MX 让三种寿命各自独立：地址可以长久，服务器可以替换，缓存里的路由知识按计划过期。通信者无需参加每次迁移，正因为身份与机器之间只保留了一条可更新映射。

共同层很薄：目的域、交换机、preference、TTL，以及回路和回退规则。队列、重试节奏、传输安全、内部邮箱位置和商业关系仍由各运营者掌握。

邮件地址因此比服务器活得更久，并非 DNS 找到了它永恒的家，而是架构让“家”成为明确且可替换的当前状态。公共记录只描述足够让本地代码行动的事实，不再把机器当成身份本身。

来源与证据边界

SMTP 与早期域地址背景见 RFC 821、RFC 882 和 RFC 883。MD/MF 改为 MX 见 RFC 973。1986 年路由算法、缓存取舍、回路规则与非传递责任见 RFC 974。

记录格式见 RFC 1035，主机要求与修正见 RFC 1123。成熟 SMTP 查询、implicit MX 与同级选择见 RFC 5321。明确无服务状态见 RFC 7505。

这些文档属于不同协议时期。后期规则用于说明成熟与修正，不倒推成 1986 年 mailer 已有的要求；规范之外的运营后果均作为有边界的推论，而非所有部署的统计事实。