邮件 DNS 记录：MX、SPF、DKIM 与 DMARC

邮件依赖多种 DNS 记录，它们各司其职。MX 记录告诉发送方的邮件系统，应把发往某个域名的入站邮件投递到哪里。SPF 以 TXT 数据发布一项策略，说明哪些发送系统获得了授权。DKIM 使用发布在 DNS 中的公钥，让收件方能够验证加密签名；DMARC 则告诉接收方，如何处理未通过对齐检查的邮件，以及可以把报告发往何处。这些机制相辅相成：一条正确的 MX 记录并不能为出站邮件提供身份验证，一条有效的 SPF 记录也不能配置入站投递。

入站路由始于 MX

发送方邮件服务器会查询收件人域名的 MX 记录，得到一个或多个带优先级数值的邮件交换服务器主机名。当有多个目标可选时，优先级数值较小者优先，不过投递系统可能会应用重试和可用性逻辑。这些目标主机名随后还需要各自完成地址解析。如果域名没有 MX 记录，邮件行为可能回退到其他 DNS 规则，但依赖这种隐式回退，通常不如直接发布预期的配置来得清晰。请对照邮件服务商当前的设置说明核对 MX 的值，并确认邮件所用的根域名准确无误。

SPF 以 TXT 记录的形式发布在相应的域名下，并针对发起连接的发送方进行评估。它有查询次数限制和语法规则，所以把多段相互独立的 SPF 字符串复制到不同的 TXT 记录中，可能引发 permerror。DKIM 记录通常发布在发送方提供的、带选择器的专用名称之下，缺少选择器会导致签名无法验证。DMARC 使用 _dmarc 之下的约定名称，可以先从监控模式起步，再考虑采用更严格的策略。请不要自行编造取值，应从每一个获准代表该域名发信的邮件平台处获取。

为什么邮件身份验证需要对齐

DMARC 会根据所配置的对齐模式，检查邮件中可见的 From 域名，是否与通过 SPF 或 DKIM 验证的域名对齐。这有助于接收方区分对域名的授权使用，与仅仅声称来自该域名的邮件。如果通过验证的信封发件人与可见的 From 域名不对齐，域名可能通过 SPF 却无法通过 DMARC；如果发布的密钥缺失或有误，DKIM 签名也可能验证失败。邮件平台往往会同时使用多个发送服务，所以在收紧策略之前，应当先盘点所有合法的发送来源。

• 在编辑 SPF 之前，先列出所有为该域名发信的系统。
• 发布服务商签发的 DKIM 选择器，并核实选择器名称准确无误。
• 根据您监控工作的准备情况，选择合适的策略来启动 DMARC 报告。
• 在服务商迁移之后，检查 MX 优先级以及目标地址的解析。
• 在调整为强制执行之前，先查看汇总报告，并调查其中未知的发送方。

迁移之后核实记录

更换邮件服务商时，请先导出旧的 DNS 配置，再把新的 MX、SPF、DKIM 和 DMARC 记录与新服务商的设置清单逐项比对。有些服务商除邮件记录之外，还要求添加域名验证用的 TXT 记录。旧的发送系统只在仍有合法流量时才保持授权，经过监控之后，再谨慎地移除过时的授权。由于 DNS TTL 缓存的存在，并非所有接收方都会立即看到变更。请确认公网应答，并向有代表性的收件系统发送测试邮件，但要记住，投递结果还取决于信誉、内容和收件方的过滤策略。

DNS 查询可以显示这些记录是否在公网可见，但它本身并不能证明一封邮件一定会进入收件箱。MX 记录指南和 SPF、DKIM 与 DMARC 详解分别介绍了各个机制。请使用 DNS 检查工具检查具体的名称和类型，再通过发送受控的测试邮件并查看服务商日志来验证。在清单中把路由和身份验证分开处理，会让邮件变更安全得多。

变更邮件 DNS 之前先建立清单

许多组织的合法发送方不止一个：邮箱服务商、营销平台、工单系统、财务应用和监控服务，都可能以同一个域名的名义发信。请建立一份清单，列出每家供应商、发送域名、SPF 要求、DKIM 选择器和负责人。同时确认每家供应商使用的是可见的 From 域名，还是被委派的子域名。这份清单是制定安全的 DMARC 策略的基础，因为报告常常会揭示出邮件主管理员原本不知道存在的系统。请对照供应商当前的文档和一封真实的测试邮件进行核实，并且只有在团队确认其流量已不再需要之后，才移除过时的发送方。