用AI分析DMARC报告：Claude修复SPF与DKIM

一句话结论：当服务台平台、开票工具或邮件简报服务以你的域名发信，却没有完成认证和对齐时，收件服务器可能把邮件放进垃圾箱甚至直接拒收，而你公司内部谁也看不到任何报错。DMARC 聚合报告就是"谁在以你的域名发信、结果通过与否"的完整记录。用 AI 做 DMARC 报告分析时，把这份 XML 连同当前的 SPF 和 DMARC 记录一起贴给 Claude，它可以把每个发信来源归入"我们的且通过""我们的但失败""不认识的"三类，并起草 DNS 修改清单。Claude 只能看到你贴给它的内容，它也可能出错，它给出的每一条记录在发布之前都应该用 DNS 查询核对一遍。

设想一家 80 人的香港专业服务公司，由办公室经理兼管 IT。公司使用 Microsoft 365 和 Exchange Online，域名（这里称为 example.com）多年来一直稳定。过去一个季度新增了三样东西：一个以 support@example.com 回复客户的 Zendesk 服务台，一批以财务团队名义发出的 Xero 发票，以及由市场协调员负责的 Mailchimp 邮件简报。

然后投诉来了。一位客户说她从没收到工单的回复。另一位说发票提醒"又进了垃圾邮件文件夹"。服务台显示每封邮件都已发送，Xero 显示发票已送达，Mailchimp 显示发送正常。没有退信，所以从内部看不出任何问题。

Microsoft 365 迁移之后，上一位顾问为 example.com 发布了一条采用隔离策略的 DMARC 记录，并设置了 rua 地址，此后每天的 XML 报告一直堆在一个共享邮箱里。没人打开过，因为用文本编辑器根本读不懂。

为什么合法邮件会认证失败（以及为什么总是在新增发信工具之后）

收件服务器不会信任邮件上显示的 From: 地址，因为任何人都可以随便写。它们检查的是：发信服务器是否被允许代表该域名发信，以及邮件是否带有能证明内容未被改动的签名。新增的、以你域名发信的工具，只有在有人专门配置之后才能通过这些检查，而供应商的默认配置往往是以供应商自己的域名，而不是你的域名来认证邮件。

这个默认配置就是常见的故障点。邮件是真的，发信人也是你的，但在收件方看来，它和陌生人冒用 example.com 发信没有区别。如果你的 DMARC 策略要求收件方对失败的邮件隔离或拒收，它们就会照做。发信方的后台显示"已发送"，收件人却永远看不到。

用大白话讲清 SPF、DKIM 和 DMARC 对齐

SPF 说明哪些服务器可以发信。它是一条 DNS 记录，列出被允许代表某个域名发信的服务器，检查对象是信封发件人（也叫 return-path 或退信地址），而不是人们看到的 From: 地址。它证明发信服务器被允许，但不能证明内容没被改动，邮件被转发时它还常常失效。

DKIM 说明邮件带有签名。发信系统会加上一个与 d= 标签中所指域名绑定的加密签名，收件方用该域名 DNS 里的公钥来验证。它证明邮件在传输中没有被改动，但签名域名可以是发信方控制的任何域名，包括供应商自己的域名。

DMARC 要求 From: 域名必须对得上。只要 SPF 或 DKIM 通过，并且通过的那个域名与 From: 域名对齐，邮件就通过 DMARC。用 d=vendor.com 签名的服务台能通过 DKIM，但这个域名不是你的，所以不对齐，DMARC 也就不通过。DMARC 还会公布你的策略以及接收报告的地址。

关于这三类记录在香港环境下的通用入门，请看我们的香港企业 SPF、DKIM 和 DMARC 指南。

把 DMARC 聚合报告变成通俗易懂的诊断

聚合报告是收件方每天对"声称来自你域名的邮件"所做的统计。它是机器可读的 XML，最初由 RFC 7489 定义，2026 年 DMARC 修订后改由 RFC 9990 定义，所以一直没人去读。

XML 里到底有什么

每份报告都会写明发送报告的机构（例如大型邮箱服务商）、覆盖的日期范围，以及它看到的已发布的 DMARC 策略。接下来是按发信 IP 地址列出的一行行数据：邮件数量、收件方如何处理、DKIM 和 SPF 是否通过，以及这些检查认证的是哪些域名。

里面没有邮件正文，也没有主题行。你能拿到的是发信 IP 地址和你的域名，这属于运营数据而不是通信内容，不过你仍应核对自己的隐私政策如何对待 IP 地址。取证报告（单独的 ruf 类型）可能包含单封邮件的部分内容，那是另一回事。

把来源分为"我们的且通过""我们的但失败""不认识的"三类的提示词

在这个流程里，Claude 不会查询你实际生效的 DNS，也不会读取你的邮箱，所以一切都要由你提供。贴上报告 XML 或表格导出，再加上当前的 SPF 和 DMARC TXT 值，然后问："这是 example.com 的 DMARC 聚合报告以及当前的 SPF 和 DMARC 记录。请把每个发信 IP 分成三组：我们的且通过 DMARC、我们的但未通过 DMARC、不认识的。对每个失败的来源，请说明是 SPF 还是 DKIM 失败、通过的域名是否与 example.com 对齐，以及最可能的修复办法。凡是这份数据看不出来的，请标为未知，不要猜测。"

实际案例——以你的域名发信、却没有 DKIM 密钥的服务台平台

1. 收集一周的报告和两条记录。从 rua 邮箱取出报告，并用 nslookup -type=txt 或 Resolve-DnsName 之类的工具查出 example.com 和 _dmarc.example.com 当前的 TXT 记录，然后贴上这些值。切勿贴出注册商或 DNS 的登录信息。

2. 运行分组提示词。模拟的结果如下（IP 地址用文档保留地址段代替真实地址）：192.0.2.10 发送了 1,140 封邮件，SPF 和 DKIM 均对齐并通过，这是 Exchange Online，状态健康。198.51.100.61 发送了 205 封邮件，DKIM 对齐并通过，这是 Mailchimp 邮件简报，市场部最初发送时就配置正确了。

3. 读懂失败的那一行。198.51.100.24 发送了 312 封邮件，未通过 DMARC。SPF 通过了，但通过的是供应商的退信域名。DKIM 也通过了，但签名是 d=helpdesk-vendor.example.net。两者通过的都不是 example.com，所以都不对齐，隔离策略随之生效。这就是服务台，也解释了为什么回复丢了。

4. 查看不认识的来源。203.0.113.77 发送了 38 封邮件，两项检查都失败。Claude 把它标为不认识。不要为了让它通过而把它加进 SPF。先问清楚谁可能以这个域名发信：被遗忘的 CRM、复印机的扫描发邮件功能，还是有人在冒用你的域名。弄清之后再决定。

5. 注意报告没有解释的部分。Xero 的发票提醒没有作为失败来源出现，所以"进了垃圾邮件"的投诉可能另有原因，例如邮件内容、收件人自己的过滤规则，或者某个不发送报告的收件方。

6. 修复服务台。打开供应商关于认证自定义发信域名的文档。它会给你 DKIM 记录（通常是 CNAME），往往还有自定义的 return-path 或退信域名，让 SPF 也能对齐。发布这些记录，每一条都用查询确认，然后在供应商后台打开验证。Exchange Online 是另一回事：它的自定义域名 DKIM 是在 Microsoft Defender 门户中通过发布两条 CNAME 记录（selector1 和 selector2）来启用的，具体路径请查阅 Microsoft 的最新文档。

7. 用下一批报告重新运行提示词。报告通常每天到达，所以改动往往一两天内就会体现，但各收件方不同，没有任何保证。服务台这个来源应该移到"我们的且通过"。如果没有，就把新的那一行贴回去，问问还有什么没对齐。

修复时不要把别的东西弄坏

SPF 的 10 次 DNS 查询上限，以及多加一个供应商如何悄悄弄坏记录

RFC 7208 规定一次 SPF 检查最多只能有 10 次 DNS 查询。会触发查询的机制，即 include、a、mx、ptr、exists 和 redirect，都会计入，包括每个被引用供应商自己记录里的查询。ip4、ip6 和 all 则不计入。一旦超过 10 次，收件方会返回永久错误，很多收件方会把它当作 SPF 失败。

Microsoft 365 的 include 只占一次查询，但每个供应商的 include 至少再占一次，有些供应商还在自己的记录里嵌套更多 include，所以服务台和邮件简报服务加起来可能增加好几次。昨天还正常的记录，今天可能就失败了，而表面上什么都没变。你可以让 Claude 估算查询次数，但要用专门的 SPF 检查工具核实，因为 include 是层层嵌套的，语言模型可能数错。

分阶段把 DMARC 从 p=none 提升到隔离再到拒收

策略有三个档位。p=none 只监控，不采取任何动作。p=quarantine 要求收件方把失败的邮件视为可疑，通常放进垃圾箱。旧的指南会用 pct 标签逐步推进，但 2026 年的 DMARC 修订（RFC 9989）已删除 pct，改为新增 t=y 测试标志，所以在依赖其中任何一个之前，先确认收件方和你的工具是否支持。p=reject 要求收件方直接拒收失败的邮件。往上提升是目标，因为只有强制执行才能挡住伪造邮件，但每一步都应该在报告干净之后再走。

每一步都要观察：你自己的来源是否还有失败的，"不认识的"清单是否在缩短。只要还有合法系统没有对齐，就不要提升到拒收，因为发票就是这样永久消失的。在本例中，公司已经处于隔离档位，所以首要任务是修好失败的来源，而不是收紧任何东西。

Claude 辅助诊断 vs 专用 DMARC 监控服务 vs 凭感觉改 DNS

Claude 辅助诊断。适合一次性的排查或少量报告：几分钟内把 XML 变成通俗的分组和修改清单，不需要新增订阅。它不会收集报告，看不到你实际生效的 DNS，除非你再次贴上报告，否则不会保留你域名的历史记录，还可能数错 SPF 查询次数。正确用法：作为首次诊断，并向负责 DNS 的人做讲解。
专用 DMARC 监控服务。为长期运维设计：替你接收报告，把众多收件方合并成一个看板，持续跟踪各来源，并在有新来源开始发信时提醒你。它是持续的开支，仍然需要有人判断每个来源是什么。正确用法：强制执行之后，在发信方清单不断变化时作为常设视图。
凭感觉改 DNS。快、免费，也是这个领域大多数故障的起因：因为某篇博客这样说就加一条 include，照抄别家公司的记录，或者直接跳到拒收。正确用法：没有。

把事情做对——不要粘贴注册商或 DNS 凭据，以及明年谁来负责这些记录

永远不要把凭据给 Claude。它只需要报告 XML 和两条 TXT 字符串，不需要别的。注册商或 DNS 托管商的登录信息、API 令牌或管理员密码，都不应该出现在对话里。DNS 的改动要自己动手，并让第二个人一起核对。

发布之前先核实。Claude 对供应商的记录名称、selector 格式或查询次数，可能很有把握地给出错误答案。把它提出的每一条记录对照供应商的最新文档检查，改完之后再用查询确认实际生效的内容。把旧记录记在笔记里，这样几分钟内就能回退。

确定明年由谁来负责这些记录。认证永远没有"完成"的一天，因为每个以你域名发信的新 SaaS 工具都会增加一个来源，记录也会随之漂移。要明确：谁来审阅报告，哪个团队在注册新的发信工具之前必须先通知谁，办公室经理离职后谁掌握 DNS 权限。能修改 DNS 和邮件设置的管理员账号，也应当启用 MFA，因为账号一旦被攻破，攻击者就能自己发布记录。

决定 Claude 应当如何融入你的邮件诊断，并围绕它写好提示词和复核步骤，属于 AI+ Support 的工作。我们管理型IT外包服务的每个方案都包含 DMARC 监控；我们的管理型邮件安全服务提供针对冒用发件人和身份仿冒的防护，与强制执行的 DMARC 策略相辅相成；具体的 DNS 改动和邮件流修复由我们的 IT 支持团队负责。同一问题的另一个方向，即收到可疑邮件，请看用 Claude 标记钓鱼邮件；同一个租户内的更多 Claude 应用，请看 Claude 与 Microsoft 365 邮件自动化。

常见问题

Google 和 Microsoft 现在要求批量发信方必须有 DMARC 吗？

对大型发信方来说是的。Google 和 Yahoo 的批量发信方要求从 2024 年 2 月开始实施；Google 的门槛是每天向个人 Gmail 账户发送 5,000 封或更多邮件。要求内容包括 SPF、DKIM、至少为 p=none 的 DMARC 策略、对齐，以及营销邮件的一键退订，Google 后来又转向更严格的执行，包括拒收。Microsoft 从 2025 年 5 月起，对超过该发信量的发信方向 Outlook.com、Hotmail 和 Live 应用了类似规则。具体的门槛和日期请查阅这两家公司的最新页面。很多中小企业每天发送不到 5,000 封，但认证仍然会影响邮件的落点。

可以直接上 p=reject 吗？

可以发布，但没有证据就很冒险。如果任何合法系统，例如服务台、开票工具或被遗忘的扫描仪，尚未对齐，reject 会让收件方丢弃它的邮件。先停留在 p=none 或隔离档位，直到报告显示你自己的每个来源都已通过，等这种状态保持一段时间之后，再提升到拒收。

DMARC 报告包含个人数据吗？

聚合报告包含发信 IP 地址、邮件数量、通过或失败的结果和你的域名，没有邮件正文和主题行。这在很大程度上是运营数据，但在某些法域里 IP 地址可能属于个人数据，所以应当像对待其他日志一样对待它们。

为什么加了 SPF include 之后邮件还是失败？

通常是因为问题根本不在 SPF。只要 SPF 或 DKIM 通过并且对齐，DMARC 就通过。只有当供应商的 return-path 域名同样是你的域名时，include 才有用，这往往需要供应商的自定义退信域名设置。另一个原因是超过了 10 次查询上限，这会让整条记录变成错误，所以每次新增之后都要重新计数。