企业邮箱安全加固的标准动作清单（进阶版）

进阶的那一步不是再加一项配置，而是把 DMARC 策略从 none 推到 reject。 按规范，p=none 表示域名所有者不要求收件方对验证失败的邮件采取任何特定动作[3]——所以三条记录都发布了却还在被冒名，通常不是记录写错，而是策略停在了不要求处置的那一档。

三条口径先记住：

基础动作——双重认证、访问策略、第三方客户端专属密码、定期改密、域名认证验收——另有一份完整清单，见企业邮箱安全加固的标准动作清单。三条记录本身怎么配、怎么验收，见大成云代配置：MX-SPF-DKIM-DMARC 一次到位不进垃圾箱。本篇假定这些都已完成，只讲把策略推上去这一件事。

进阶的起点是承认 p=none 状态下策略还没有生效

很多企业把「SPF、DKIM、DMARC 三条记录都发布了」当成邮件安全加固完成。这一步确实是必要的前置，但它离生效还差一段。

差在哪里，规范写得很直白。DMARC 的 p 标签只有三个取值：none 表示域名所有者不要求收件方对验证失败的邮件采取任何特定动作；quarantine 表示希望收件方按可疑处理，视其能力可以是投入垃圾箱、加强审查或标记可疑；reject 表示希望收件方拒收，而且拒绝应当发生在 SMTP 会话期间[3]。

所以停在 p=none 的域名，对冒用它发信的邮件没有提出任何处理要求。 记录是有的，报告也在收，但收件方按规范可以什么都不做。

有一项前置值得在动手之前复核一遍，因为它在升级之后会变成硬约束：DKIM 的签名算法与密钥长度。规范规定签名方必须使用 rsa-sha256，rsa-sha1 已不得用于签名或验签；密钥必须至少 1024 位，并且应当使用至少 2048 位，而验签方不得把小于 1024 位的签名视为有效[2]。把策略推到拒收之前，先确认自己的签名不是靠一个会被判为永久失败的算法或长度在通过。

第一个动作：把聚合报告调到能看懂

策略要往上推，依据不能是感觉，只能是报告。DMARC 的报告机制有三个参数决定你能看到什么。

报告多久来一份，由 ri 决定。 这个标签是可选的，默认值是 86400 秒，也就是一天一份[3]。多数域名不需要改它——每天一份，一周就有七个数据点，足够看出趋势。

失败报告什么时候产生，由 fo 决定。 四个取值分别是：0，所有底层认证机制都没能产生对齐的 pass 时才出报告；1，任一机制产生了非对齐 pass 的结果就出报告；d，签名求值失败就出 DKIM 报告，不论是否对齐；s，SPF 求值失败就出报告，不论是否对齐[3]。默认行为偏保守，而升级期恰恰需要更灵敏的信号，所以推进阶段值得把 fo 调得更细。

报告本身不受 pct 影响。 规范明确写了这一点：该标签不适用于 DMARC 生成的报告，所有报告都必须无阻碍地收发[3]。这是升级期能够稳定取证的前提——哪怕策略只对一部分邮件生效，报告仍然覆盖全部。

拿到报告之后，每份报告要读三件事：

要读的信息	它回答什么	放行时看它做什么
发信源 IP 与对应邮件量	有哪些服务器在用你的域名发信	确认清单里没有你不认识的来源
SPF 与 DKIM 的对齐结果	每个来源是通过还是失败	失败的那些，先判断是自己的还是冒用的
失败流量占总量的比例	升级后会影响多大范围	这个比例决定下一级能不能推

第三行是放行判据的核心。 不是「有没有失败」，而是「失败的里面有多少是自己的合法发信」——冒用流量失败是好事，自己的流量失败才是必须先修的。

动作清单：四级门禁与每一级的放行证据

把升级过程拆成四级，每一级有明确的放行条件。

级别	策略与参数	放行到下一级需要看到
第一级	p=none，fo 调细，ri 用默认	报告中全部合法发信源都已识别并通过对齐
第二级	p=quarantine，pct 从小比例起	提高比例的过程中没有新增合法流量被隔离的反馈
第三级	p=quarantine，pct=100	全量隔离下无合法邮件误隔离
第四级	p=reject，pct=100	报告中失败流量已收敛到只剩冒用来源

三点需要就近说明。

第一，pct 的正确用法是在第二、三级之间做灰度。 规范写明这个标签的用途是让域名所有者分批启用 DMARC，而不是一次全开[3]。它的默认值就是 100，所以在 p=reject 后面再写一个 pct=100 没有增加任何信息——真正有用的写法是在升到 quarantine 时把 pct 设成一个小比例，确认无误后再往上提。

第二，第一级的放行条件是「识别完整」而不是「全部通过」。 报告会列出所有用你域名发信的 IP，其中一定有冒用的。第一级要确认的是自己这一侧没有遗漏——每个自己的发信源都在认证覆盖内。冒用来源通不过，正是策略要起作用的对象。

第三，quarantine 与 reject 之间那一级不能跳。 按规范，quarantine 交给收件方的处理余地很大（垃圾箱、加强审查、标记可疑都算），而 reject 是在 SMTP 会话期间直接拒收[3]。前者出问题时邮件还在某个可找回的位置，后者出问题时邮件已经退回给发送方。先在可找回的档位上把误伤清零，再进入不可找回的档位。

每一级的观察窗口该多长，规范没有规定——它只规定了报告间隔的默认值是 86400 秒[3]。窗口长短应当按自家发信源的数量和邮件周期性来定，发信路径多、有月度营销活动的域名需要更长的观察期。

记录改动之后不会立刻生效：解析记录通常需要 10 分钟至 48 小时在全球范围内生效[7]。怎么确认已经生效，见域名配置生效要多久：DNS 传播常识。

卡住时先查两件事：查询次数和代发路径

推进到这一步卡住时，绝大多数情况不需要逐条排查所有配置。先看两件事，它们覆盖了大部分失败流量。

第一件是 SPF 的查询次数上限。 规范规定：产生 DNS 查询的项包括 include、a、mx、ptr、exists 五个机制与 redirect 修饰符，实现必须把这些项的总数限制在 10 次以内，超出则必须返回 permerror[1]。不计入这个上限的是 all、ip4、ip6 与 exp[1]。

这条限制在实际中比看起来更容易撞上，因为 include 是会嵌套的——你引用的服务商记录里还有它自己的 include，层层累加。而超限的后果不是「部分通过」，是整条 SPF 求值返回 permerror，对该域名的每一封邮件都失败。

另有两条独立限制常被忽略：每个 mx 的求值不得查询超过 10 条 A 或 AAAA 记录，超出该机制必须返回 permerror；每个 ptr 的求值超过 10 条地址记录时，第 10 条之后的必须被忽略[1]。压缩查询次数时，把 mx 换成直接写 ip4 往往比继续加 include 更稳。

顺带纠正一个常见说法：~all 并不是「留了后门」。规范定义的四个限定符是 + pass、- fail、~ softfail、? neutral[1]，~ 是一个明确的求值结果。在 DMARC 已经接管处置决定之后，SPF 用 ~ 还是 - 对 DMARC 的判定结果没有区别——真正决定拒不拒的是 p，不是 SPF 的尾巴。

第二件是第三方代发路径。 这一条在大成云的域名解析与安全认证配置页上被单独列为最容易被忽略的坑：CRM、ERP、营销工具代发的邮件如果没有写进 SPF，容易被判为伪造而退信或进垃圾箱；处理方式是把全部发信路径统一梳理一遍、补全认证记录[5]。梳理范围还要覆盖多域场景——阿里邮箱域名解析文档要求多域、子域与域别名分别核对相应的认证记录[4]，只配主域会在子域发信时留下缺口。

这两个卡点会互相加剧，这是本节最值得记住的一点：代发系统越多，需要的 include 越多，越容易撞上十次上限。所以梳理路径和压缩查询次数是同一件事的两面，不能分开做。

身份层做到 reject 之后，缺口会转移到账号本身

这一节写的是本篇这套动作的适用边界，不写清就会把身份层策略当成邮件安全的全部。

阿里邮箱反垃圾产品文档有一段值得原样理解：通过外域发到用户邮箱的垃圾邮件或钓鱼邮件，基本上都可以被防病毒和反垃圾网关挡掉；但如果用户的账号和密码被盗，不法分子用被盗账号发送钓鱼邮件，会造成更严重的信息泄露和财产损失，主要破解方式是撞库和弱密码猜测[6]。

这句话把身份层策略的作用范围划清了：DMARC 管的是「别人冒用你的域名」，管不了「别人用你的账号」。 被盗账号是从合法服务器、带合法签名发出的，SPF 与 DKIM 都会通过，DMARC 判定为 pass。官方给出的对应能力是双重认证、专属密码认证和访问策略[6]。

访问策略这一项有一条默认值要知道：新购买的阿里企业邮箱默认带有一条已开启的「三方客户端访问策略」黑名单策略，不允许登录第三方客户端；需要用 Outlook、Foxmail 的账号要加为例外或关闭该策略，5 分钟后生效[8]。这条默认值的方向和本篇一致——它默认关掉的正是被盗账号最常用的外发通道。 升级 DMARC 的同时，值得确认这条策略是被精确放开了例外，而不是被整条关掉。

还有一条边界要写明：官方钓鱼防护指南明确指出，任何技术手段都无法百分之百杜绝钓鱼邮件[9]。所以 reject 不是终点，它把「域名被冒用」这一类风险压下去之后，剩下的是账号安全与人的环节——攻击落地后怎么处置，见员工误点钓鱼链接后，企业还能补救吗。

reject 会拒掉哪三类合法邮件

reject 的语义是拒收，而且拒绝应当发生在 SMTP 会话期间[3]。这意味着被拒的邮件不进垃圾箱、不进隔离区，而是在投递环节就被退回。对冒用你域名的邮件这正是目的，但有三类合法邮件也可能落在同一侧。

这三类都不是「升级有风险所以别升」的理由，而是「升级前要做完的清单」。 第一类靠梳理路径解决，第二类决定了 DKIM 不能省（SPF 在转发场景下必然失效），第三类只要显式声明 sp 就能分开处理。

按企业规模判断该做到哪一档，见中小企业邮件安全分级建议。

沟通前准备哪些信息

要把策略推上去，动手前建议先备齐四类信息：

DMARC 策略升级常见问题（FAQ）

因为发布记录和要求处置是两件事。如果 DMARC 的 p 取值是 none，按规范这表示域名所有者不要求收件方对验证失败的邮件采取任何特定动作[3]，收件方完全可以照常投递。判断方法很直接：查一下自己域名的 DMARC 记录里 p 是什么值。如果是 none，那么前面三条记录目前的作用主要是产生报告，而不是阻止冒用。

可以设，但风险不对称。按规范 reject 要求收件方在 SMTP 会话期间拒收[3]，邮件不是进垃圾箱而是在投递环节被退回。在你还没有通过报告确认「哪些失败流量是自己的」之前直接跳到 reject，被拒的可能包含正在用的业务系统代发邮件，而且你不会在垃圾箱里找到它们。中间的 quarantine 档之所以值得走一遍，是因为它出问题时邮件还在一个可找回的位置。规范也为渐进提供了工具：pct 标签的用途正是分批启用[3]。

转发场景下 SPF 大概率会失败，因为校验对象变成了转发服务器的 IP，与你的域名不再匹配。此时能让 DMARC 通过的只剩 DKIM——签名跟着邮件走，只要转发过程没有改动被签名的部分，签名仍然可验。所以「SPF 配了就够了」这个想法在转发场景下会直接暴露问题，这也是升级到 reject 之前必须确认 DKIM 已经正常签名、且算法与密钥长度符合规范要求的原因[2]。如果业务上确实大量依赖转发或邮件列表，建议在 quarantine 档多停留一段，用报告看清转发流量的实际比例再决定。

先分清哪些项在消耗预算。按规范，include、a、mx、ptr、exists 与 redirect 每个计一次，而 all、ip4、ip6、exp 不计入[1]。所以压缩的方向是把需要查询的项换成不需要查询的项：能拿到固定 IP 段的发信源，直接写成 ip4 而不是 include；mx 机制如果只是为了覆盖自家邮件服务器，同样可以用 ip4 替代，顺带避开「每个 mx 不得查询超过 10 条地址记录」这条附加限制[1]。另外要清掉已经不用的历史 include——停用的营销工具往往还留在记录里占着预算。

按规范，父域的策略默认适用于子域，除非用 sp 标签显式声明子域策略[3]。所以两种情况都成立：如果子域没有独立的发信需求，不配置也会被父域策略覆盖；如果某个子域在用独立的发信系统（比较常见的是营销子域）而它的认证记录没有配齐，那么父域升到 reject 会一并把它的邮件拒掉。这种情况下的做法是给子域显式写 sp，让它按自己的进度单独推进，而不是为了它把父域策略压在低档位上。

没有，缺口会转移。DMARC 管的是别人冒用你的域名，管不了别人用你的账号——被盗账号从合法服务器带合法签名发出的邮件，SPF 与 DKIM 都会通过。阿里邮箱文档明确指出外域来的垃圾钓鱼邮件基本可被网关挡掉，而账号密码被盗后由被盗账号外发的风险更严重，主要破解方式是撞库与弱密码猜测[6]。对应动作是双重认证、专属密码与访问策略，其中新购邮箱默认已开启一条不允许第三方客户端登录的黑名单策略[8]。另外官方也写明任何技术手段都无法百分之百杜绝钓鱼邮件[9]，所以员工上报与事件处置流程不能省。

References