DMARC 报告：理解 XML、DNS 与策略

设置 DMARC 后，可能收到 Google、Microsoft 或 Yahoo 的 XML 附件。这时值得问：DMARC 报告与协议本身有什么区别？

DMARC 是域名认证、策略和报告协议，DNS 记录发布其配置。报告则来自参与报告的接收方，反映邮件验证后的观察结果。设置与实际反馈不是同一回事。

搭建邮箱可先参考创建自有域名邮箱。转发影响认证时，可阅读将域名邮件转发到 Gmail。这里重点介绍设置后的报告分析。

XML 起初可能难以理解。报告有时在发布后不久到达，但不保证一天后收到，也不保证所有接收方提供。混淆记录、策略、报告地址与失败数据，可能让你在尚未找到原因时修改错误的 DNS。

下面说明报告与 DNS 记录的区别及关键字段。区分转发、配置问题和可能的滥用，还需要其他验证。

什么是 DMARC 报告

它是接收邮件系统发往配置目标的反馈文件。聚合报告总结观察到的流量、SPF、DKIM、对齐和策略处理，但不覆盖所有邮件。

报告本身不是策略。支持报告的接收方验证使用你的 From 的邮件，并可以向 rua 发送汇总。RFC 7489 定义了用于理解认证、所需修复和策略影响的聚合反馈，提供报告是可选行为。

DMARC 报告与 DMARC 记录

协议使用 DNS 中发布的配置，报告则描述某个接收方对真实邮件的观察结果。

修复取决于具体原因。错误记录可能妨碍预期策略的解析。DNS 正确时，失败仍可能来自正常配置错误、转发或未经授权发信。

报告包含哪些内容

聚合数据按来源和结果分组。关键字段包括 IP、邮件数、SPF、DKIM、对齐与报告的处理方式。

XML 中应区分 auth_results 的原始认证结果与 policy_evaluated 中考虑对齐后的 SPF、DKIM 结果。至少一项通过且与 From 对齐，DMARC 就可以通过。Disposition 描述接收方处理，不单独证明认证成功。

一次 SPF 失败不表示所有邮件都坏了。DKIM 通过且对齐时，DMARC 仍可以通过。

建议按以下顺序分析：

1. 核对源 IP 和报告组织。
2. 判断数量。一封邮件与 20,000 封需要不同调查，单封也可能是关键业务。
3. 查看 disposition：none、quarantine 或 reject。None 不证明 DMARC 通过，也不一定对应观察策略。
4. 结合 XML 所属部分，同时分析 SPF 与 DKIM。
5. 核对与实际 From 的对齐。

聚合报告与逐邮件失败报告

通常所说的报告是经 rua 请求的汇总。ruf 失败报告可能针对单封邮件，支持较少，也可能包含敏感信息。

聚合观察可使用有人管理的 rua 目标。限制访问，外部目标还可能需要 DNS 授权。Google 发件人指南说明适用认证要求与可能限制。报告补充运维调查，而不替代真实邮件测试。

如何发布带报告地址的记录

在 _dmarc 发布 TXT，选择适合的策略和有人管理的目标。发信未充分验证时，可以先观察再请求限制。

以下示例使用可选的严格对齐，不是所有环境通用的安全初始配置。严格模式要求精确域名匹配，宽松模式比较组织域名：

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

下一条替代方案已经请求限制。核对清单、日志并测试低频重要流程后，再用它替换原记录：

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

排查剩余失败后，才可考虑 reject。报告中没有发现异常，不代表已覆盖所有来源，也应准备出现问题时恢复旧配置。

可以查询已发布的 DNS 值：

dig TXT _dmarc.example.com +short

TrekMail 向导可以显示需要的 MX、SPF、DKIM、DMARC，并检测 DNS 冲突，但不自动证明所有发信渠道正常。添加域名和邮件进入垃圾邮件的资料可补充真实测试。

避免对报告作出过早判断

结合其他数据区分预期转发变化和未核实来源。未知基础设施不自动等于冒用。

报告提示频率和接收处理。处理方式不是信任判断，也不证明各接收方都同样执行域名策略。

为什么转发让报告难以理解

转发时下一个接收方看到的是转发服务器 IP，所以原本正常的邮件也可能 SPF 失败。

不要随意将消费邮箱或 ISP 中继 IP 加入 SPF。SPF 检查真实信封域名的授权。只有签名有效、与 From 对齐，而且签名覆盖的数据在规范化规则下保留，DKIM 才能继续提供通过依据。

SRS 可帮助改写信封的 SPF，但不自动恢复原始 From 对齐。ARC 可以支持本地例外，不把 DMARC fail 变成 pass。详见邮件转发设置与修复。

什么时候报告足以支持 DNS 修改

先确认正常发信来源和实际原因，再修改 DNS。报告中的单次失败不直接决定正确修复。

可调查的具体情况：

1. 实际信封域名的 SPF 未授权正在使用的出站服务商。
2. DKIM 未与 From 对齐，且没有其他通过并对齐的认证结果。
3. 应用使用不再匹配当前配置的旧 SMTP 路径。
4. 记录缺少 rua、语法无效，或策略阶段与已验证发信不符。

Gmail 或 Outlook 转发 IP 的 SPF 失败不支持自动 DNS 授权。

集中界面可以帮助整理注册商、XML 和五家外部发信服务。TrekMail 可按套餐集中域名、DNS、邮箱、迁移及自备或托管 SMTP。IMAP 与 SMTP 设置帮助测试客户端，多域名邮箱托管说明管理模式。DNS 状态不替代完整发信验证。

是否需要手动阅读每份报告

小规模域名初期可能适合手动分析。规模更大时，可以使用分析工具和有人管理的目标，同时检查访问和隐私。

一个域名只有少数来源时，可在部署阶段手动阅读收到的报告。十个域名会增加工作，五十个更明显。分析器和有记录的发信渠道可以整理数据，但不保证每日收到完整报告。

预期数据可能显示通过且对齐的来源、转发变化以及报告的限制处理，却不证明覆盖所有发信或每个失败都是滥用。

合理的报告工作流程

发布、观察、核对发信源、修复对齐，再通过测试考虑限制。报告是线索，不是唯一的实施依据。

1. 发布 p=none 并使用有人管理的报告地址；本地过滤仍适用。
2. 收集数天可用报告，不期待每个接收方都提供，并单独测试低频流程。
3. 将失败调查为已知正常来源、转发影响或尚未确认的可能滥用。
4. 先修复正常配置，结合有效对齐 DKIM 检查转发，而非直接忽略。
5. 根据清单、日志与关键测试考虑 quarantine，再考虑 reject，每次替换唯一策略。

新增工具需要适用 SPF、DKIM 和 Return-Path。SPF 为真实信封域名授权发信服务器，嵌套的 DNS 机制和修饰符也计入求值限制。跟踪域名本身不改 Return-Path，服务商配置需要启用并用真实邮件验证。

TrekMail 与一致的 DNS 管理

TrekMail 不替代 DMARC，但可集中域名管理。DNS 发布与逐渠道验证仍然必要。

按套餐可提供自有域名、IMAP 邮箱、catch-all、转发、IMAP 导入及自备或托管 SMTP。代理机构可以使用集中管理和共享存储，同时考虑资源与功能上限。IMAP 复制邮件，不替代 MX 和应用切换。

应比较统一管理与现有按用户计费方案的成本和流程，同时核对转发规则及发信清单；统一管理不保证节省费用。TrekMail 付费套餐价格参考为每月 $3.50 起，Nano 有无需银行卡的免费选项，付费套餐提供 14 天试用。当前条件见 TrekMail 价格。

DMARC 报告总结

报告通过参与接收方的反馈补充配置，不替代 DNS，也只反映具体系统观察到的流量。

DMARC 是协议，DNS 记录发布设置，报告则为诊断和策略验证提供数据。应结合系统清单、日志和邮件测试调查正常偏差与可能滥用。投递与接收决定仍是不同问题。