结论先行：邮件"通过了 SPF、DKIM、DMARC"并不等于发件人可信。这三重校验依赖邮件服务商在签名之前的处理是否正确，一旦服务商出站链路的多个解析模块对同一封邮件理解不一致，伪造邮件就会带着"全部通过"的结论进入收件箱。企业可以把动作落在两处：把邮件相关日志纳入统一日志平台，对"可见发件人与回退地址不一致""同域内异常发件人"做关联复核；对索要凭据、催促付款类邮件保留人工确认通道。
这次披露了什么
据 SEC Consult 2026 年 10 月 1 日发布的技术报告，以及 FreeBuf 2026 年 10 月 2 日的报道，研究人员在某主流邮件服务商的出站邮件基础设施中发现两个邮件伪造漏洞，属于"表头走私"（header smuggling）这一类。攻击者只需拥有一个免费账号，就能发出可见发件人显示为该服务商任意地址的邮件。
更值得关注的是这些伪造邮件的"体检结果"：SPF、DKIM、DMARC 三项校验全部通过。这三项正是邮件网关与用户最常用来判断发件人身份的凭据。
按上述报告披露的时间线，其中一处漏洞于 2024 年 5 月 21 日首次报送，2024 年 12 月发现第二个绕过方式，2025 年 12 月确认修复完成，2026 年 10 月 1 日公开技术报告。
为什么三重校验会一起失效
要理解这件事，先要分清一封邮件里其实有两个"发件人"概念。
- 信封发件人：协议层的发件标识，也就是回退地址，用于退信处理与部分校验逻辑。
- 可见发件人：用户在邮件客户端里真正看到的那一行地址。
正常情况下，服务商会校验已认证的账号只能使用自己名下的发件地址。问题出在出站链路的解析不一致：同一条邮件在链路上被解析了不止一次，一次用于账号校验，一次用于投递前的预处理，两处对异常回车符与点填充规则的处理方式不同。校验阶段看不到的字段，会在后续环节被"清洗"成看起来合法的发件人字段。
| 校验项 | 为什么仍然判为通过 |
|---|---|
| SPF | 邮件确实由该服务商的合法基础设施发出，来源授权成立 |
| DKIM | 签名动作发生在存在缺陷的处理环节之后，签名内容与最终投递内容一致 |
| DMARC | 可见发件人域名与签名域名保持对齐，绑定关系成立 |
邮件认证机制的可靠性，取决于服务商在签名之前有没有处理正确——这一段不在企业自己的控制范围内。
日志侧的四条复核动作
多数企业每天产生的日志里本来就包含邮件相关记录。把它们用起来，比反复争论"要不要继续信 DMARC"更有价值。
- 把邮件日志纳入统一平台。邮件系统的日志常自成一套，与其他数据无法串联，跨字段核对只能靠人工逐条看。前提是字段口径先对齐：账号、操作时间、来源地址、目标资产等关键字段标准化之后，关联才有意义。
- 复核可见发件人与回退地址的差异。报告给出的防御建议很直接：检查完整邮件头，留意可见发件人地址与回退地址是否存在差异。这类"一封邮件两个身份"的情况，最适合做成一条关联规则。
- 建立同域异常发件人的基线。同一个域名的对外发件人通常有限且稳定。把该域历史出现过的发件人沉淀成清单，超出基线的发件人本身就是可告警事件。
- 给高风险邮件留人工通道。涉及索要凭据、要求付款、催促紧急处理三类主题的邮件，即便校验全部通过，也应保留人工确认环节。
边界与前提
三点要说清楚。其一，本次披露的问题在服务商侧，报告显示已确认修复，企业不需要为此额外采购任何产品。其二，SPF、DKIM、DMARC 仍是必要的邮件安全机制，结论不是"可以不用"，而是"不能只看通过与否就放行"。其三，日志复核依赖邮件日志的完整性——如果邮件日志没有集中留存，前面三条动作都无从落地。
落地清单
- 清点现有日志来源，确认邮件系统日志是否已在统一平台内。
- 先统一关键字段口径，把账号、时间、地址类字段标准化后再建关联规则。
- 为"可见发件人与回退地址不一致"配置一条关联告警。
- 梳理核心域名的常规发件人清单，作为异常判定的基线。
- 对索要凭据、催促付款类邮件保留人工复核环节。
- 把邮件日志的留存周期与审计要求对齐。
奇摩在日志平台落地项目中通常把"先统字段、再建关联"作为启动顺序：日志平台的价值不在于接了多少来源，而在于关键字段能不能对上。若这项建设还在方案阶段，欢迎预约咨询，我们可以按现网情况把清单与口径过一遍。