通用面试：如何安全推进 DMARCbis 与 SPF、DKIM 对齐？
题干与适用场景
公司准备把多个邮件供应商纳入同一发信域。请解释 DMARC 对齐和 2026 年 RFC 9989、9990、9991 的职责，并设计从 p=none 逐步走到 reject 的验证与回滚方案。
题目适合平台工程、安全工程、邮件基础设施和需要跨团队排查投递问题的岗位。它测试的是协议判断和迁移控制，不要求候选人声称某家收件服务已经支持全部新 RFC。
面试官考察点
- 是否能把 SPF、DKIM、DMARC 的角色和检查对象分开。
- 是否知道 DMARC 通过需要 SPF 或 DKIM 至少一项通过，并且与可见的 From 域对齐。
- 能否区分 RFC 9989 核心协议、RFC 9990 聚合报告和 RFC 9991 失败报告。
- 能否用观测数据分批收紧策略，而不是直接把
p改成reject。 - 能否处理转发、第三方供应商、子域、报告隐私和回滚。
回答前需要澄清的问题
- 受保护的是主域还是多个子域，所有发信系统的 From、Return-Path 和 DKIM d 域分别是什么？
- 当前 SPF、DKIM、DMARC 通过率按供应商和子域如何分布，是否能收到聚合报告？
- 组织是否发送营销、交易和员工邮件，是否需要不同的子域或策略？
- 收件服务的策略支持和报告行为是否已验证，还是只能以标准和实测为准？
30 秒回答框架
DMARC 检查可见 From 域的身份是否与 SPF 的认证域或 DKIM 的 d 域对齐；两条链路至少一条通过且对齐，消息才通过 DMARC。RFC 9989 定义核心协议，RFC 9990 和 RFC 9991 分别定义聚合与失败报告。迁移先把 p=none 当观测模式，收集并解析报告，按供应商、子域和消息类型修复对齐问题，再逐步提升到 quarantine 和 reject。每一步都保留指标、抽样验证和快速回滚，不能把新 RFC 编号等同于所有收件服务的即时支持。
分步骤深入解答
1. 画出三条身份链路
SPF 验证发送服务器是否获授权，通常观察 SMTP 信封中的 MAIL FROM 域；DKIM 用签名验证消息，签名中的 d 域参与对齐；DMARC 关注收件人看到的 From 域，并根据对齐结果应用策略。三者负责的输入不同，不能只看一行 Authentication-Results 就跳过域名核对。
2. 用对齐而非单纯通过率判断
DMARC 的核心条件是 SPF 或 DKIM 至少一项通过，并且认证域与 From 域按组织选择的 relaxed 或 strict 模式对齐。一个供应商可能 SPF pass 但 envelope-from 不对齐，也可能 DKIM pass 但 d 域属于供应商；两种情况都需要修正域名、签名或发送边界。
3. 解释 2026 年三份 RFC 的边界
RFC 9989 是 DMARC 核心规范，取代早期 RFC 7489 的历史定位；RFC 9990 描述聚合报告，帮助域主按来源观察长期分布；RFC 9991 描述失败报告。面试中应把“规范已经发布”和“每个收件服务都会生成同样报告”分开，具体支持仍要用实测和供应商文档确认。
4. 设计逐步收紧策略
先发布 p=none，设置受控的 rua，并把报告送到有访问控制的分析邮箱或管道。按来源聚合 SPF、DKIM、From、子域和失败原因，先修复合法发送者。可对高风险子域使用 sp，也可以拆分交易和营销子域。只有在合法流量稳定通过且未知来源能解释后，才逐步采用 quarantine，最后再采用 reject。
5. 把验证和回滚写进变更单
上线前保存 DNS 记录、供应商配置和当前报告基线。每次收紧后观察合法邮件到达率、DMARC pass、对齐失败、投诉和报告延迟；用真实测试邮箱覆盖转发、列表和附件场景。若合法流量下降，先回到上一策略或缩小子域范围，再定位是 SPF 传播、DKIM 签名、转发改写还是报告缺失。
高质量示范回答
我会先盘点每个发送系统的 From、MAIL FROM 和 DKIM d 域，再按供应商和子域计算通过与对齐结果。DMARC 不要求 SPF 和 DKIM 同时通过，而是至少一条通过并对齐。RFC 9989 负责核心策略，RFC 9990 和 RFC 9991 负责两种报告；报告可见性不能假设为所有收件服务一致。迁移先用 p=none 收集聚合报告，修复第三方发送者、转发和子域问题，稳定后再小范围进入 quarantine，最后才是 reject。每一步都设置 pass 率、合法邮件到达率和未知来源占比的门槛，并保留 DNS 回滚和单独子域隔离。这样策略变化可审计，失败时也能迅速降低影响。
常见错误
- 看到 SPF 或 DKIM pass 就宣布 DMARC 通过，忽略 From 域对齐。
- 把 SPF 的 MAIL FROM、DKIM 的 d 域和可见 From 当成同一字段。
- 把 RFC 9989、9990、9991 都称为“DMARC 核心协议”，说不清报告职责。
- 没有报告基线就直接使用
p=reject，把合法第三方邮件一起拦截。 - 假设转发一定保留 SPF 或 DKIM，未设计转发和邮件列表测试。
- 把 DNS 记录公开给所有人，忽略报告中可能出现的地址和组织信息。
追问及应对
SPF pass 但 DMARC fail，先查什么？
先比较 SPF 认证域与 From 域，确认 relaxed 或 strict 对齐模式；再检查子域继承、重写和真实邮件头。不要只看发送 IP 是否在 SPF 中。
DKIM pass 但转发后失败怎么办？
检查转发方是否改写正文或关键头部，确认签名 d 域和选择器仍可解析。对无法控制的转发路径，评估稳定的 DKIM 签名、列表处理和隔离子域，不能用盲目放宽策略掩盖未知来源。
如何决定从 quarantine 到 reject？
用按供应商、子域和消息类型切分的报告数据证明合法流量持续对齐，并完成转发、营销和交易场景测试。阈值应包含合法到达率、对齐失败率、投诉和未知来源趋势，且必须有回滚窗口。
报告地址在另一个域名时要注意什么？
确认接收报告的域名明确授权该报告关系，并限制报告管道的访问和保留时间。跨域报告不应被当成自动可信的数据出口。
资料来源：RFC 9989、RFC 9990、RFC 9991、Google Gmail《Email sender guidelines》、Dataford《Explaining Email Authentication Clearly》（完整链接见 meta.json）。