1. 引言

M3AAWG（Messaging, Malware and Mobile Anti-Abuse Working Group，消息、恶意软件与移动设备反滥用工作组）是全球最大的在线反滥用行业组织，其成员涵盖 Gmail、Yahoo、Microsoft 等主要邮件服务提供商以及大量商业发件组织。

本文档推荐了一套使用以下安全协议对电子邮件进行认证的最佳实践：SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting & Conformance）以及ARC（Authenticated Received Chain）。

M3AAWG 的核心论断是：认证是二元的——要么做对，要么没做，不像内容过滤打分那样存在概率空间。行业的最终目标是实现"No Auth, No Entry（无认证不进入）"：无法确定来源身份的邮件将不再被投递。认证是防御域名仿冒、钓鱼攻击和垃圾邮件的基石。

2. SPF 推荐实践

SPF 允许域名所有者公布哪些 IP 地址有权使用该域发送邮件。M3AAWG 提出以下重点建议：

• 为所有发信域发布 SPF 记录。无论组织规模大小，只要通过该域发送邮件，就应具备有效的 SPF 记录。
• 不发送邮件的域应发布 v=spf1 -all。这明确拒绝任何来源以该域发送邮件，是防止域名被伪造的有效手段。
• 避免使用 +all 或过于宽松的策略。任何形式的全部授权都会使 SPF 形同虚设，攻击者可随意伪造该域发信。
• 保持 DNS 查询在 10 次以内。根据 RFC 7208，SPF 评估过程中的 DNS 查询总数（包括 include、redirect 等机制）不得超过 10 次，超出会导致permerror，等同于认证失败。
• 利用 DMARC 报表验证 SPF 配置。DMARC 的聚合报告（rua）可展示 SPF 验证的通过率与失败率，帮助管理员发现配置遗漏。
• 定期审计 SPF 记录。持续检查 SPF 中授权的 IP 地址是否仍然有效，清理不再使用的第三方服务商。

特别的，M3AAWG 建议 SPF 记录应以 ~all（软失败，softfail）收尾；只有那些明确从不发信的域才应使用 -all（硬失败，fail）。

关于对齐：SPF 验证的是 Return-Path 域（即 MAIL FROM）。为使 DMARC 通过，该域应与信头 From 域对齐（即 SPF 对齐）。由于邮件转发过程中 Return-Path 常被改写，SPF 对齐在转发场景中容易失效——这正是引入 ARC 的原因之一。

3. DKIM 推荐实践

DKIM 通过数字签名让接收方验证邮件在传输过程中是否被篡改，并确认其与某个域名的绑定关系。M3AAWG 的建议：

• 对全部外发邮件进行 DKIM 签名。不留死角，确保每一封从组织发出的邮件都携带签名。
• 密钥长度至少 1024 位，推荐 2048 位。更长的密钥提供更强的安全保障，同时不会对签名验证性能产生显著影响。
• 定期轮换 DKIM 密钥。推荐每 6–12 个月轮换一次，以降低密钥泄露带来的风险。
• 为不同的邮件流使用不同的选择器。例如为营销邮件、交易邮件、内部通信分别使用独立选择器，便于定向轮换和问题排查。
• 确保 DKIM 签名包含在邮件头中。签名必须覆盖关键头部字段（如 From、Subject、Date）以保证完整性验证。
• 签名域应与信头 From 域对齐。虽然 DKIM 不对齐本身也可作为签名验证通过，但要使 DMARC 通过，签名域（d=）必须与 From 域完全匹配或子域匹配。M3AAWG 特别推荐优先使用 DKIM 对齐而非 SPF 对齐，因为 DKIM 签名在邮件转发过程中不易被破坏。

M3AAWG 还特别指出：当一个域的 SPF 记录过于宽松时，攻击者可利用"SPF 升级攻击（SPF Elevation Attack）"在某些条件下成功伪造该域。优先让 DKIM 签名域与 From 域对齐，是缓解该风险的关键手段——这也与 NIST SP 800-177r1 的结论"DKIM 比 SPF 更稳健"一致。

4. DMARC 推荐实践

DMARC 在 SPF 和 DKIM 之上提供了策略层，告诉接收方当认证失败时应如何处理邮件。M3AAWG 给出以下分阶段建议：

• 从 p=none 开始。首先在监控模式下发布 DMARC 记录，观察当前的认证通过率，了解有哪些发信流已经覆盖、哪些尚未覆盖，避免部署初期误杀合法邮件。
• 确认认证覆盖后转为 p=quarantine。当监控显示认证通过率达到可接受水平后，将未通过认证的邮件标记为垃圾邮件（隔离处理）。
• 最终推进到 p=reject 以提供最强保护。p=reject 是最严格的策略——接收方直接将未通过认证的邮件拒绝投递。这是行业公认的最终目标。M3AAWG 认为 p=reject 应是所有域的默认姿态。
• 设置 pct=100 实现全面执行。pct 标签控制策略施行的比例。许多组织最开始设置 pct=1 或 pct=5 以小流量试运行，但最终应达到 pct=100。
• 配置聚合报告（rua）和取证报告（ruf）。rua 提供总体认证通过率统计，ruf 提供每封未通过认证的邮件的详细失败信息，两者结合可全面把控认证健康状况。
• 定期审阅 DMARC 报告。报告的频率取决于邮件量，但至少应每周检查一次，以确保及时发现认证配置变化或新的滥用行为。

M3AAWG 强调：p=none、sp=none 与 pct<100 只应视为过渡态，目标是将这些限制条件尽快移除。

5. ARC 推荐实践

ARC（Authenticated Received Chain）被 M3AAWG 文档正式纳入邮件认证栈。ARC 解决的是邮件经过中间跳（如邮件列表、转发服务）后认证失效的问题：

• 在转发链上实施 ARC。当邮件经过合法的转发服务、邮件列表或自动转发时，原有的 SPF 和 DKIM 验证结果可能因路径改变而失效。ARC 由转发服务对已有的认证结果进行"链式"背书，使下游接收方仍能信任原始认证状态。
• ARC 有助于在邮件被转发时维持 DMARC 合规。不使用 ARC 时，合法转发邮件可能会因 DMARC 策略被错误拒绝；部署 ARC 可大幅缓解这类误判。
• ARC 协议定义在 RFC 8617 中。目前 Google、Yahoo、Fastmail 等主要服务商均已支持 ARC。

6. 实施策略

M3AAWG 推荐分阶段推进邮件认证部署，以降低风险：

1. 从监控开始。先设置 DMARC 的 p=none，结合 rua 报表了解当前认证全景。
2. 识别并修复认证缺口。分析 DMARC 报告，找出哪些合法的发信流尚未通过 SPF 或 DKIM 认证，逐一补充。
3. 逐渐收紧策略。从 p=none → p=quarantine → p=reject 逐步推进，每一步都确认无重大误判后再前进。
4. 与第三方发件人协调。许多组织依赖 ESP（邮件服务提供商）、CRM 系统等第三方代为发信，务必确保这些第三方发信流也已配置 SPF/DKIM，并与组织的 From 域对齐。
5. 维持持续监控。认证配置不是"一次部署、终身无忧"的工作。定期检查 DMARC 报告、审计 SPF 记录中的授权 IP、按期轮换 DKIM 密钥，是保持认证体系健康的必要投入。

7. 常见错误

M3AAWG 指出以下在实践中经常出现的错误：

• SPF 记录中 DNS 查询次数过多。过多的 include 语句导致 DNS 查询超出 10 次上限，使整个 SPF 评估结果为 permerror。
• DKIM 签名未通过对齐。DKIM 签名域（d=）与 From 域不匹配，即使签名验证通过，DMARC 仍判定为 DKIM 失败。
• 未充分准备就启用过于严格的 DMARC 策略。直接设置 p=reject 可能导致合法邮件被拒绝，造成业务损失。
• 未涵盖所有合法发信来源。未将第三方的发信 IP 纳入 SPF，或未与第三方协调 DKIM 签名，导致认证覆盖不全。
• 不监控 DMARC 报告。设置 DMARC 记录后忽略其报表，等于放弃了发现问题和优化的机会。
• DKIM 密钥不轮换。长时间使用同一组密钥，增加了私钥泄露后的攻击面。

8. 国外场景补充

上述 M3AAWG 的推荐主要面向全球邮件生态，以下结合国内邮件系统的实际部署情况做几点补充：

国内 DMARC p=reject 部署现状

截至 2026 年，国内大型邮件服务商（如 QQ 邮箱、163 邮箱、阿里邮箱）对 DMARC 策略的处理存在较大差异。部分服务商对 p=reject 的执行力度较弱，甚至对未通过 DMARC 认证的邮件仍以 p=none 逻辑投递。这意味着在国内环境下，仅靠 p=reject 可能无法实现真正的拒绝效果。

因此建议：

• 在部署 DMARC p=reject 的同时，配合接收端主动检查 DMARC 策略并执行对应的过滤规则。
• 如果主要收件方为国内邮箱，p=quarantine 可能是现阶段更务实的中间目标。
• 定期检查各主流邮箱商对 DMARC 执行策略的更新公告。

SPF 10 次 DNS 查询限制在国内的常见问题

国内企业邮件系统常引入多个第三方服务（企业微信、钉钉、营销平台、CRM 系统等），每个服务商都可能要求在 SPF 中添加一条 include 语句。加上部分第三方服务的 SPF 记录本身又包含多层 include，很容易触及 10 次 DNS 查询上限。

常见解决方案：

• 合并多家服务商的发信 IP，用 ip4 机制替代 include，减少 DNS 查询次数。
• 将不常用的第三方服务迁移到独立的子域发信，子域拥有独立的 SPF 记录。
• 使用 SPF 宏（macros）在特定场景下优化查询路径。
• 定期审计 SPF 记录中的 include，移除不再使用的第三方服务。