为什么要持续监测 SPF/DKIM/DMARC

认证配置是“活的系统”，不是“一次配好就行”的开关。供应商会新增 include、 DKIM 选择器要轮换、模板改版可能丢头部；这些变化大多发生在夜里或迭代中，等收件箱 降权/拒收才发现就晚了。每日体检 + 阈值告警 + 可验证证据，能把事故变成通知。

四大支柱（以及它们如何“走形”）

• SPF：唯一 TXT、总查询 ≤10（建议 ≤8）、无递归环。新增供应商或供应商自身的 include 扩张，最容易把查询数推高。
• DKIM：每日至少一次 dkim=pass、密钥 ≥2048 位、双选择器、零停机轮换。过期/未完全切换会造成间歇性失败。
• DMARC：按 none→quarantine→reject 分阶段推进，必要时用 sp= 管控子域。策略滞后会掩盖对齐问题。
• 对齐：宽松（r）按组织域；严格（s）需完全一致。使用供应商 envelope 或供应商 d= 会打破对齐。
• 一键退订：头部存在且端点安全（POST、幂等、HTTPS）。模板切换最容易丢。

每日监测清单（含阈值）

1. SPF 健康：唯一记录；lookups ≤10（≥8 预警）；递归深度 ≤3；无重复 TXT。
2. DKIM 健康：最近 24h 有 pass；两个选择器有效；密钥 ≥2048；轮换日历可追溯。
3. DMARC 状态：分阶段策略、rua/ruf 正常；子域 sp= 按业务线设置。
4. 对齐：宽松通过（或严格通过）；PSL 版本保持最新。
5. 退订：头部存在；自动化检查仅校验存在/语法，不访问 URL。

可验证证据（Proof‑of‑Scan）

每次体检都会生成标准化 JSON（键排序、LF、UTC）与 sha256 哈希，并打印在 PDF 尾页（含 scanId、rulepackVersion、解析器与超时）。任何人都可调用 /api/verify 用 1.1.1.1/8.8.8.8/9.9.9.9 复算，比对哈希。

从 AR 头读出问题

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=return@mail.example.com;
  dkim=pass header.d=mail.example.com header.s=s1;
  dmarc=pass header.from=example.com

• SPF 身份：smtp.mailfrom
• DKIM 身份：header.d（d=）与 header.s（选择器）
• 可见发件人：header.from

宽松对齐用 PSL 推导组织域后比对；严格对齐需完全一致。若 spf=pass/dkim=pass 却仍 dmarc=fail，多半是对齐出了问题（供应商 envelope 或供应商 d=）。

告警 → 原因 → 修复 → 验证（一页表）

可扩展的作业流

• 队列与去重：Redis + BullMQ；同域 15 分钟只入队一次
• 扫描器：解析 DNS 与 AR；PSL 对齐；出分与建议
• 证据：规范化 JSON + sha256；记录 rulepackVersion、解析器集合
• PDF：Worker 异步渲染、24h 签名下载
• 告警：Email 为先；Slack/飞书 可选；模板使用 Markdown

保留与隐私

• JSON 90 天；PDF 30 天；Proof 可长期（或 1 年）
• 不保存邮件正文；.eml 仅用于头部解析且即删
• 下载链接 HMAC 签名，24 小时过期

常见问答