术语 · DMARC 检查

如何对应用邮件进行 DMARC 检查？

DMARC 检查应分别验证四件事：能在 DNS 中发现有效的策略；策略的必需标签能被正确解析；在真实邮件上，至少有一个经过验证的 SPF 或 DKIM 标识符与可见 From 域名对齐；以及在强制执行之前，所有合法的应用发件方都已纳入考虑。查询 _dmarc 名称，检查记录内容，然后查看受控发送邮件的身份验证结果。DMARC 通过只能证明域名的使用经过授权；它不能证明邮件已送达或进入收件箱。

把 DMARC 检查当作四项测试，而不是一次查询

有用的检查包含四个层次。第一，发现适用于该邮件作者域名的策略。第二，将 TXT 记录作为 DMARC 策略进行校验，而不是接受 DNS 返回的任意文本。第三，在实际邮件上测试标识符对齐：经 SPF 验证的 MAIL FROM 域名或经验证的 DKIM 签名域名，必须与可见 From 邮件头中的域名对齐。第四，确认运营层面的覆盖：通过使用该域名的每个合法应用、服务商、区域和邮件类别进行发送。DNS 查询显示正常，只覆盖了前两层的一部分。它无法说明服务商是否使用预期的域名签名、自定义退信路径是否生效、转发是否改变了 SPF 行为，也无法说明某个被遗漏的系统能否在强制执行策略下正常工作。

查询正确的 DNS 名称并遵循策略发现流程

从 RFC5322 From 邮件头中的确切域名开始，这个域名通常称为作者域名。查询 _dmarc 加上该域名的 TXT 记录。对于来自 alerts@notify.example.test 的邮件，应从 _dmarc.notify.example.test 开始，而不是网站主机、MX 主机或退信路径域名。RFC 9989 定义的策略发现不止一次查询：如果作者域名没有有效记录，收件方可以沿 DNS 树向上查找适用的组织域或公共后缀策略。子域的处理方式可能来自 sp、np 或 p 标签，具体取决于存在哪些标签以及策略在何处被找到。这意味着检查工具应同时报告查询的名称和它实际选中的策略域名。仅仅显示“找到记录”的结果，可能会掩盖继承错误，或掩盖一条改变预期处理方式的显式子域策略。

在解读策略之前先校验记录结构

DMARC 策略记录使用标签值语法。根据 RFC 9989，v=DMARC1 为必填项、区分大小写且必须最先出现；有效的 p 标签提供请求的评估策略。常见策略值为 none、quarantine 和 reject。可选标签说明报告目标、子域名行为以及严格或宽松的 SPF 和 DKIM 对齐。不要悄然修复拼错的标签、缺少的 p 值、重复或冲突的记录、无效分隔符，或带有 DNS 服务商引号伪影的复制值。将永久评估错误视为需要修正的结果，而不是 DMARC 通过或失败。还应区分暂时性 DNS 查询错误与格式错误的记录。通过受控路径重试暂时解析器故障，但在能可靠查询权威 DNS 前，不要声称该域名没有策略。

在真实邮件上检查 SPF 和 DKIM 对齐

DMARC 是针对邮件的身份验证结果进行评估的，而不是孤立地看 DNS 配置。对于 SPF，比较经过验证的 MAIL FROM 域名与可见 From 域名。对于 DKIM，比较每个验证成功的签名的 d= 域名与可见 From 域名。宽松对齐接受组织域相同的域名；严格对齐则要求域名完全相同。只要至少有一个经过验证的标识符通过了其底层机制并且对齐，邮件就会通过。例如，服务商的退信路径可以让 SPF 以服务商的域名通过，但仍与 billing.example.test 不对齐。如果 DKIM 以 d=example.test 验证通过，且采用宽松对齐，该邮件仍然可以通过 DMARC。请从受控的收件账户中获取原始 Authentication-Results 邮件头，但要结合上下文解读，因为它报告的是执行评估的收件方的结果，并且可能包含多个跳点或多个签名。

准确解读 pass、fail、none 和 error 结果

DMARC 通过意味着策略记录适用，且已验证的 SPF 或 DKIM 标识符与作者域名对齐。失败意味着策略适用，但不存在已验证且对齐的标识符。None 意味着未发现适用策略。Permerror 和 temperror 表示 DMARC 评估期间出错；具有 DNS 错误的邮件不能视为 DMARC 通过或失败。这些结果并不说明邮箱服务商将邮件放在何处。RFC 9989 明确将通过限定为已验证域名所有者授权了该使用；它并不声明邮件安全、受欢迎、信誉良好或值得进入收件箱。在诊断和控制台中，将服务商受理、收件服务器受理、DMARC 结果、投诉信号和观察到的位置保留为独立字段。

在强制执行之前梳理所有合法发件方

盘点所有在 From 中使用该域名的系统：生产应用、身份验证邮件、账单通知、客服工具、营销平台、监控告警、CRM 工作流、区域账户和应急系统。针对每一条邮件流，记录可见 From 域名、MAIL FROM 域名、DKIM d= 域名和选择器、服务商账户、负责人、邮件类别和预期发送量。通过正常的生产路径发送受控邮件，同时验证身份验证和对齐。DMARC 汇总报告可以揭示哪些来源在使用该域名，但需要解读，其中也可能包含转发流量或未经授权的流量。在清单尚不完整时先从监控开始，然后修复未对齐的合法邮件流，再请求收件方进行更严格的处理。不要只为了让某一个应用显示正常就修改共享的组织级策略，也不要仅凭一封测试邮件就进入强制执行。

诊断常见的应用邮件故障

如果找不到策略，请先核实 DNS 区域和记录名称，再修改记录值。如果记录存在永久性错误，请将其精简为一条有效策略，并检查标签顺序和语法。如果 DKIM 失败，请检查预期的选择器是否存在、服务商是否真的对测试邮件进行了签名、正文或已签名的邮件头是否在传输中被修改，以及验证通过的 d= 域名是否对齐。如果 SPF 通过但 DMARC 失败，请比较 MAIL FROM 域名与可见 From 域名，而不要认为只要 SPF 通过就足够。如果只有转发的邮件失败，请记住转发通常会改变信封路径，可能导致 SPF 失效，而有效且对齐的 DKIM 签名可能依然有效。如果某次上线导致邮件被拒，请保留失败邮件的邮件头和收件方响应，停止进一步提高策略级别，并修复出问题的邮件流，而不是削弱无关的身份验证控制。

有意识地应用各服务商特定的对齐规则

第三方发件方需要进行配置，将其已验证的标识符绑定到组织所控制的域名上。Amazon SES 文档说明了两种途径：用于 SPF 的对齐自定义 MAIL FROM 域名，以及对齐的 DKIM 签名域名。其默认由服务商拥有的退信路径可能通过 SPF 验证，但不与可见 From 域名对齐，因此除非配置了自定义 MAIL FROM 域名，DKIM 往往才是实际可用的对齐机制。其他服务商对退信路径、退信域名、域名身份验证和签名身份使用不同的名称。请验证实际发出的邮件，而不要以为控制台上的“已验证”标志就意味着 DMARC 已建立。当前的 Gmail 发件人指南也要求适用的流量进行身份验证和对齐，并建议启用 DMARC 报告。收件方要求和服务商功能可能会变化，因此请在上线时和事故复盘期间重新查阅其官方文档。

使用服务商证据，但不要将其视为 DMARC 裁决

SendHQ 支持已验证域名发送、投递事件、抑制记录和 Web 控制台。使用其发信域名和投递信息调查邮件流，然后从收件方的 Authentication-Results 邮件头验证 DMARC，并分开 SPF、DKIM 和对齐证据。服务商受理和投递事件不证明收件箱送达率。

记录可审计的 DMARC 检查结果

一份可长期保存的结果应包含：作者域名、查询时间、解析器、查询的 _dmarc 名称、选中的策略域名、经过规范化的确切记录、策略和对齐模式、DNS 状态，以及解析结果是语法可用、permerror 还是 temperror。为每封受控邮件添加一行记录，包括不含敏感信息的邮件标识符、发送系统、可见 From 域名、经验证的 SPF 域名及结果、验证通过的 DKIM 域名和选择器、对齐判断、最终 DMARC 结果以及收件方。原始邮件头应存放在访问受限的存储中，因为其中可能暴露地址、路由细节和内部标识符。将每项发现关联到负责人和修复日期。在 DNS TTL 过期、服务商配置变更、密钥轮换、新增邮件流或提高策略级别之后，重新检查。这些证据让检查可以复现，并防止在底层配置变更后，一张截图或工具徽章被当作永久证明。

常见问题

应该在哪里检查 DMARC 记录？

先查询 _dmarc 加上可见 From 地址中确切域名的 TXT 记录。同时找出按现行 DMARC 发现规则选中的策略域名，因为当首次查询的名称没有有效记录时，可能会适用组织域或子域策略。

找到 v=DMARC1 就代表 DMARC 通过了吗？

不代表。它只是构成有效策略记录的一部分。只有当 SPF 或 DKIM 使用与可见 From 域名对齐的域名验证通过后，邮件才会通过 DMARC。请测试一封真实邮件，并检查收件方的身份验证结果。

SPF 未对齐时 DMARC 还能通过吗？

可以。验证成功的 DKIM 签名可以提供 DMARC 所需的已对齐验证标识符。反过来也成立：当 DKIM 未通过时，对齐的 SPF 也能支撑 DMARC 通过，但只依赖一种机制会降低容错能力。

DMARC 通过能证明邮件进入收件箱吗？

不能。它只验证了该邮件对作者域名的使用经过授权。收件方在接收、拒收、隔离或归类邮件时，仍可能依据信誉、内容、收件人、滥用和本地策略等信号作出判断。

应用应该直接切换到 p=reject 吗？

通常不能，除非有清单和监控证据。映射每个合法发件人，在受控邮件中验证对齐，审查汇总报告，修复故障，并在请求更严格的处理前与域名所有者协调策略变更。

更换邮件服务商后应重新检查哪些内容？

在增加生产流量之前，请重新检查每个 From 域名发现到的策略、服务商的 MAIL FROM 和 DKIM 域名、选择器 DNS、SPF 和 DKIM 结果、宽松或严格对齐、汇总报告，以及每一类受控应用邮件。

参考来源