怎样从 EOP 邮件头判断一封邮件被判为垃圾邮件的真正原因？

邮件头字段很多，逐个看会迷失。按这个顺序读，三步之内基本能定位：

1. 认证层：Authentication-Results —— 这封信是不是它声称的那个域发的？
2. 判定层：反垃圾报告头 —— 平台把它归为哪一类、来源 IP 是什么？
3. 评分层：垃圾评分与批量投诉级别 —— 严重程度如何？

倒过来看（先盯评分）是常见错误：评分只是结果，不解释原因。

该头部由 RFC 8601 定义，记录接收方执行的各项认证结论。重点看四个值：

• spf= —— 连接 IP 是否被发件域授权。转发场景下失败属正常，不必惊慌。
• dkim= —— 签名是否有效。同时要看 header.d=，确认签名域是否与 From 域一致。
• dmarc= —— 对齐结果与发件域声明的处置策略。
• compauth= 及其 reason= —— 平台的综合结论及依据。这一项通常最接近真正的拦截原因。

若 compauth 失败，基本可以判定问题出在发件方的认证配置或确属伪造，不必再往内容特征方向排查。

该头部承载平台的过滤判定详情。运维上优先关注：

• 判定类别：指出被归为垃圾、钓鱼、恶意软件、批量邮件还是欺骗。这是分流的依据——钓鱼类和批量邮件类的处理路径完全不同。
• 来源 IP：平台认定的连接来源。若这里是你自己网关的 IP，说明前置网关的跳过配置有问题，整个判定链都建立在错误的来源上。
• 过滤动作与命中来源：说明是被策略、列表还是检测判定命中，直接决定去哪里调整配置。
• 安全提示相关标记：指示是否触发了首次联系、外部标识等提示。

• 垃圾评分反映「像不像垃圾邮件」。需要注意的是：该值可能被传输规则强制设定，因此一个异常干净的评分不一定代表邮件真的干净，也可能是某条规则做了免检。发现评分与内容明显不符时，回头查规则。
• 批量投诉级别反映「这个发送源的群发邮件被投诉的普遍程度」，针对的是营销、通知类批量邮件。

实用区分：用户抱怨「订阅的正常通知进了垃圾箱」，通常是批量投诉级别的阈值问题，而不是垃圾评分问题。两者调整的位置不同。

• 认证全失败 + 判为钓鱼：大概率是真伪造，不要放行，应核实是否有其他用户也收到了同类邮件。
• SPF 失败但 DKIM 通过且对齐：典型的转发场景，属正常，问题多在本侧对转发邮件的处置过严。
• 认证全通过但仍被判垃圾：内容或发送行为特征命中，走误报提交流程，同时检查是否为批量邮件类判定。
• 来源 IP 是自家网关：优先修复前置网关的跳过配置，在此之前所有其他判定都不可信。

头部取证只能看到单封邮件的静态结论。要还原完整过程，需要用 Message-ID 把邮件头、邮件追溯记录、隔离区记录三处串联起来。

建议在日志采集时就把 Message-ID 作为独立字段索引——事后再从原始邮件里逐封提取，效率极低，且退信、转发等场景下容易取错。