BIND 修改 MX 后仍收不到邮件：缺少尾点让域名重复拼接

在 BIND zone 文件中添加邮件服务商提供的 MX，保存并加载后仍收不到邮件。查询发现记录出现在 example.com.example.com.，或 MX 目标变成 mx.mail-provider.example.example.com.，应检查名称末尾是否缺少点号。

zone 文件里没有尾点的名称会按当前 $ORIGIN 扩展，适用于记录左侧的 owner，也适用于 MX 右侧的目标域名。语法合法不代表记录落在了预期名称上。这篇讨论直接维护 BIND zone 文件；DNS 面板的输入规则需要按平台单独确认。

owner 和邮件服务器目标都可能被扩展

假设当前 origin 是 example.com.，以下是错误结构示例：

$ORIGIN example.com.
example.com IN MX 10 mx.mail-provider.example

左侧的 example.com 没有尾点，实际 owner 为 example.com.example.com.；右侧目标也没有尾点，实际目标会追加当前 origin。这里的两处都可能出错，不能只给邮件服务器名称补点。

可按服务商实际给出的目标采用明确的绝对名称，以下名称仅为占位示例：

$ORIGIN example.com.
example.com. IN MX 10 mx.mail-provider.example.

在这个 origin 下，左侧也可以使用 @ 表示当前 origin。若文件中途又改变了 $ORIGIN，@ 指的也会改变；不要机械地把每个 owner 都替换成它。

MX 目标填写邮件服务器域名，不是网站 IP，也不意味着要把网站 A 记录改到邮件服务商。优先级按服务商要求配置，数字较小的目标优先；这些字段与尾点问题是不同的检查。

先检查候选 zone，再核对权威响应

以下仅是静态 zone 文件的只读检查示例，路径替换为候选文件：

named-checkzone example.com /etc/bind/db.example.com.candidate

它能检查 zone 的语法与一致性，但相对名称扩展后的结果仍可能合法，因此通过检查不能证明目标 owner 正确。对使用动态更新或 journal 的 zone，应走现有管理流程，不能绕开正在生效的数据直接编辑文件。

修正后保存原文件，按既有流程增加 SOA serial、加载目标 zone，并留意日志是否接受了这次更新。不要因为邮件未到就先重启全部 DNS 服务。

随后向实际权威服务器查询，以下 ns1.example.com 是服务器占位值：

dig @ns1.example.com example.com. MX +norecurse
dig @ns1.example.com example.com.example.com. MX +norecurse

第一项应在预期名称返回正确目标；第二项用于识别误创建的重复名称，移除错误记录后不应继续返回那套 MX。检查所有权威服务器及 SOA serial，避免主服务器修复了而其他服务器还保留旧数据。

递归缓存与邮件投递分别验收

权威数据正确后，再检查用户实际使用的递归解析器。它可能缓存旧记录，或者此前没有 MX 的否定结果；仅修改 TTL 不能缩短已经缓存的数据寿命。先确定权威发布正确，再按原缓存有效期观察，而不是笼统地等待“传播”。

MX 正确也不保证邮件服务已接受域名或创建邮箱。DNS 验收通过后，应按邮件服务商的配置核对收件域、账号及投递结果；仍有退信时读取具体退信原因，不能继续把所有故障归到尾点。

回退要恢复正确的记录集合并发布更新的 SOA serial，不能把 serial 简单改回较小的旧值。保留原 zone 和发布日志，明确哪套 MX 是恢复目标，避免回退后重新启用误拼接名称。