DMARC 用 p=none 还是 p=reject：分三步收紧

先把边界说清楚。三条记录怎么配那篇讲的是 DMARC 记录长什么样、p 和 rua 怎么填，那部分不重复。这篇处理的是填完之后的事：什么条件下能从这一档挪到下一档，以及挪错了怎么退回来。

多数公司卡在同一个地方——记录配上了，p=none，然后就一直放着。理由通常是「先观察观察」。观察了半年，一份报告没打开过，域名照样能被别人拿去伪造。这不是观察期，这是没开始。

三档是时间表，不是选择题

p 的取值决定了收件方对「验证失败」的信怎么处理。三档不是三个可选项，而是三个阶段，每一档都在回答一个具体问题。

关键差别在后果。none 和 quarantine 都是可逆的——进垃圾箱的信还能捞出来，客户找不到可以打电话。 reject 不可逆，信在收件方那一侧就被吞掉了，你这边只看到一封退信，客户那边什么都不知道。

所以顺序不能跳。跳过 none 直接上 reject 的公司，通常在第三天开始接到「客户说没收到报价单」的电话，然后慌了，把记录一删——连报告一起没了，等于回到零。

rua 报告：一天几十封 XML，只看四个字段

rua 指向的信箱每天会收到各邮件服务商回传的聚合报告，附件是 .xml.gz。第一次打开会劝退：一层层嵌套的标签，一封里几十条记录。

其实只需要看四个字段。剩下的都是元数据。

读法上有个诀窍：不要一封一封看，按 IP 汇总。把一周的报告全部解压，把 source_ip 和 count 提出来累加，按总量排序。排在前面、你又认不出来的 IP，就是这一轮要处理的对象。手工做这件事可以用脚本，量大的公司一般交给第三方 DMARC 分析服务。

有个细节第一次配就会踩：rua 填的邮箱如果在另一个域名下，报告根本不会来。DMARC 规定跨域收报告需要对方域名发一条授权记录，也就是在报告接收域名下加一条 _report._dmarc.接收域名 的 TXT，值是 v=DMARC1。没有这条授权，多数服务商会静默不回传，你只会看到「报告怎么一封都没有」，然后误以为配置失败。稳妥做法是 rua 直接用当前域名的邮箱。

报告体积也要有预期：一天几十封、解压后几百 KB 到几 MB 是常态，取决于发信量。别用个人邮箱收，容易被塞满，也容易把报告当垃圾邮件清掉。

none 阶段：判据是陌生 IP 连续七天为零

这一档最容易变成无限期。给一个能结束的条件，比说「观察一段时间」有用。

具体做法：

1. 先列已知发信源。企业邮箱服务商、官网表单通知、CRM、ERP、客服工单、EDM 平台、财务对账、招聘系统。逐个问 IT 和业务部门，问两件事：走哪个服务发、出口 IP 或 include 地址是什么。
2. 再拿报告对。报告里出现的 IP 减去已知清单，剩下的就是「陌生 IP」。每一个都要查清：是某个部门自己买的 SaaS，还是有人在冒用你的域名。
3. 查清之后分两类处理。自家的，补进 SPF（有 include 就加 include，有固定 IP 就写 ip4:）或给它配 DKIM；冒充的，什么都不用做，收紧策略之后它自然被拦。
4. 等到连续七天没有新 IP 出现。这个判据的意思是：一周的周期覆盖了月末对账、周报、促销群发这些低频发信，还没冒出新来源，说明清单基本齐了。

七天是个经验值，不是标准。业务有季节性（比如外贸在展会前后集中群发）的，把这个窗口拉长到覆盖一个完整业务周期再判断。

补 SPF 的时候要留个心：加 include 会消耗查表次数，上限是 10 次。报告里挖出来的发信源可能有三四个，全塞进 SPF 很容易顶穿上限，整条记录判 permerror，比不加更糟。查表次数怎么数、超了怎么压，SPF 记录配置错误那篇有完整算法。顶不住的时候，把营销类发信拆到子域名去，别硬塞主域名。

quarantine：用 pct 分批，别一次全量

从 none 改到 quarantine 的那一刻，所有验证失败的信开始进垃圾箱。如果清单里有漏的，漏掉的那一批当天就开始掉。

pct 参数解决的就是这个。pct 是「对失败邮件应用策略的百分比」，写 pct=25，等于只有四分之一的失败邮件按隔离处理，其余仍按只观察处理。放量的节奏可以是 25 → 50 → 100，每一档停三到五天，看两件事：报告里 disposition 变成 quarantine 的记录有没有集中在某个你不认识的 IP 上；业务侧有没有人反馈「邮件没收到」。

一个容易误解的点：pct 调低不等于策略失效，报告照常全量回传。所以放量期间数据不会断，这一点比直接降 p 好——降 p 会把处理动作整体退回去，pct 只影响比例。

还有一个参数值得同时设：fo（失败报告选项）。它控制什么时候给你发失败明细。多数大厂不发这类明细报告（涉及原文隐私），设了也收不到，别指望它。要定位具体哪封信失败，还是靠自己在测试信里看 Authentication-Results，方法见 DKIM 验证失败怎么查。

reject 之前，先过转发和子域名两关

这两关不过，reject 一定出事，而且出事的方式很隐蔽。

第一关：转发链路。客户收到你的报价单，转发给同事——这一跳会破验证。破哪一项，取决于转发方式：只改信封发件人、正文和头部不动的转发，DKIM 通常还能过，DMARC 靠 DKIM 对齐通过；邮件列表那种会在标题前加 [列表名]、在正文尾部加退订说明的，主题和正文哈希都变了，DKIM 直接废，SPF 又因为转发服务器 IP 不在白名单而 fail，两项全破，reject 下必被拒。

这个问题没有干净的解法。ARC 是一种缓解机制，让转发方把原始验证结果封进去，收件方可以选择采信，但支持程度各家不一，不能当成保证。能做的只有两件：把自己的邮件列表类发信挪到独立子域名，别跟一对一业务邮件共用一套策略；以及在上 reject 之前，先问一圈客户侧有没有用邮件列表或工单系统代转。

第二关：子域名。默认情况下，主域名的 p 会连带作用于所有子域名。你的主域名上了 reject，notice.example.com、mail.example.com 一起进入拒收状态——而这些子域名很可能只配了 SPF，没配 DKIM，之前一直靠宽松策略混着过。

处理办法是显式声明 sp（子域名策略），把它单独设得松一档，等子域名的 SPF/DKIM 补齐了再收紧：

v=DMARC1; p=reject; sp=quarantine; pct=100; rua=mailto:dmarc@你的域名

这一行里 sp=quarantine 的意思是：主域名拒收，子域名先隔离。等子域名那几条 DKIM 记录都验过了，再删掉 sp，让它跟随主域名。

收紧之后误杀自己的信，怎么退回来

一定会遇到，提前想好动作比事后慌强。

第一步不是删记录，是降 pct。把 pct 从 100 改成 10，等于只对一成的失败邮件执行拒收，九成恢复投递，业务当天就能缓过来，而报告和保护都还在。删记录是下下策：删掉之后不但没有保护，rua 报告也一起停了，你就彻底失去了观察手段，下次再收紧还是两眼一抹黑。

如果降 pct 还不够（说明问题面很广），再退到 p=quarantine。别一步退到 none。

第二步是找出被误杀的是谁。降级之后看报告，disposition 为 reject 的那批记录里，source_ip 是哪个、header_from 是什么。多数情况是三种：某个业务部门自己接的短信/邮件平台、老的自建邮局、还有子域名上漏配 DKIM 的系统。

第三步才是补配置，然后把 pct 慢慢放回去。放回去的节奏和上来时一样，25 → 50 → 100。别一次跳回 100。

还有个时间账要记住：改 DMARC 记录同样受 TTL 影响。降级不是即时的，各家收件方缓存过期时间不同，从几分钟到几小时都有可能。紧急情况下，先按「至少一小时」预期，别指望改完五分钟就恢复。等缓存这件事的逻辑和 MX 记录多久生效是一套。

最后说一句实话：DMARC 的价值不在记录本身，在报告有没有人看。记录填上去十分钟的事，报告每周看一次、把陌生 IP 清掉，才是真正在做防护。配了不看的公司，和没配的区别只在于——被冒充的时候，你有一堆没打开过的 XML 可以证明自己早就知道。