邮件头分析器

功能说明

Email Header Analyzer 解析电子邮件的原始邮件头（RFC 5322），并把它变成一份可读的取证报告：一条结论横幅把所有发现汇总成一个一目了然的判定（发现伪造迹象 / 可疑信号 / 干净）；一条逐跳的投递时间线，列出邮件经过的每一台 Received 服务器以及相邻两跳之间的延迟；SPF / DKIM / DMARC 三项认证判定；以及完整的异常清单 - 诸如 From 地址与 Return-Path 不匹配、Reply-To 指向意料之外的地方、可疑的群发软件标识、或者时间戳倒退等伪造信号。

页面布局分为两栏：左侧是原始邮件头输入，右侧是固定定位的实时分析报告面板，滚动浏览发现项时它始终保持在视野内。当一封邮件看起来像钓鱼而你想要证据而不是直觉时，这就是你要用的工具。

使用方法

1. 获取原始邮件头：在 Gmail 中打开邮件 → ⋮ → Show original，然后复制邮件正文以上的全部内容。Outlook：File → Properties → Internet headers。
2. 把内容粘贴到原始邮件头输入框（或点击 Sample 载入内置的演示邮件）。
3. 点击 Analyze headers。报告出现在右侧结论横幅的下方。
4. 先读结论横幅：红色（危险）= 至少一个严重伪造指标；琥珀色 = 仅有警告；绿色 = 无异常。严重程度计数显示在横幅右侧（critical × 1、warnings × 2、notices × 1）。
5. 依次阅读各个分区：投递路径（最早的跳在最前，延迟徽章按颜色分级）、认证（SPF/DKIM/DMARC 各行）、异常（每条发现及其证据），以及全部邮件头（完整展开的邮件头表格）。
6. 点击 Copy share link 得到一个携带你完整输入的 URL - 任何人打开它都会看到相同的分析结果。

如何读认证行。 每一行显示机制名称、结果词，以及它所来自的证据子句：

• SPF - 发送服务器的 IP 是否得到了信封中域名（smtp.mailfrom）的授权？pass = 已授权；softfail = 未授权，但该域名只要求接收方将其视为可疑；fail = 明确未授权，很可能是伪造；neutral = 域名不作任何声明；none = 未发布策略；temperror = 瞬时 DNS 故障；permerror = 记录损坏/格式错误。该行的附加文字显示被检查的信封地址。
• DKIM - 邮件是否带有加密签名，签名是否通过验证？pass = 签名有效（该行显示签名的 selector，以及在已发布时来自 header.d 的签名域）；fail = 签名存在但已损坏 - 邮件头或正文在传输途中被改动；none = 未签名；temperror/permerror = 公钥无法获取。详情行显示原始子句，例如 dkim=pass header.s=sel2026 header.b=AbCdEf。
• DMARC - 可见的 From: 域名的策略是否接受了这封邮件？pass = 对齐且底层检查全部满足（该行显示被评估的 header.from 域名及该域名的 p= 策略：none、quarantine 或 reject）；fail = 邮件声称的身份被其自身策略拒绝；none = From 域名未发布 DMARC 记录。

示例所演示的一个关键警示：三项全部通过，邮件仍可能是钓鱼诱饵。 SPF/DKIM/DMARC 验证的是发送域名确实发出了这封邮件 - 既不代表发件人可信，也不代表 Reply-To 指向你所想的地方。这就是为什么即使认证面板全绿，异常清单依然重要。

如何读 Received 链。 邮件服务器会前置（prepend）每一条 Received 头，因此工具按自下而上的顺序解析：第 1 跳是 origin 服务器，最后一跳是你的收件服务器。相邻两跳之间会显示一个延迟徽章 - 由两条时间戳计算出的耗时：

• 绿色，低于 1 秒（以毫秒显示）：正常中继。
• 琥珀色，1-60 秒：存在排队或灰名单 - 通常没有问题。
• 橙色，超过 60 秒：中继缓慢、邮件服务商限流，或邮件在队列中滞留。
• 灰色 “unknown delay”：该跳没有可解析的时间戳，因此这一段无法计量（同时会作为一条 info 异常提出）。

时间戳倒退（第 N 跳早于第 N−1 跳）会得到专门的警告：要么是两台服务器的时钟不一致，要么有人伪造了 Received 头。

示例

载入内置 Sample 并点击 Analyze headers，可一次性看到全部功能。示例的已验证输出：

• 投递路径 - 共 3 跳，最早的在前：sender.evil.example → mail.relay.example（ESMTP），然后是 mail-sor-f41.google.com → mx.google.com（ESMTPS，+7.0 s），最后 mx.google.com（SMTP，+3.0 s）。
• 认证 - 全部通过：billing@legit-shop.com 的 SPF pass、选择器为 sel2026 的 DKIM pass、legit-shop.com 策略为 quarantine 的 DMARC pass。
• 结论横幅 - 红色：critical × 1、warnings × 2，因为异常如下：

From: "Legit Shop Support" <support@legit-shop.com>
Reply-To: billing@evil.example
Return-Path: bounce@evil.example
X-Mailer: SuperBulk Mass Mailer 4.2

→ Critical：Return-Path (bounce@evil.example) does not match From (support@legit-shop.com) — the envelope sender differs from the displayed sender.（Return-Path 与 From 不匹配 - 信封发件人与显示的发件人不同）。此外还有针对被转移的 Reply-To 和群发软件 X-Mailer 的警告。认证之所以通过，是因为 legit-shop.com 确实发出了它 - 但这封邮件仍被精心伪装成另一个样子。

一封干净的邮件（信封与 From 一致、已签名、已认证）：

Received: from mail.example.com by mx.google.com with ESMTPS; Tue, 12 Aug 2026 10:15:42 -0700
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=billing@legit-shop.com; dkim=pass header.s=sel2026; dmarc=pass (p=quarantine) header.from=legit-shop.com
From: Billing <billing@legit-shop.com>
Return-Path: <billing@legit-shop.com>

→ 绿色结论，“No spoofing indicators found”，零异常。

一个全红的认证面板 - 三项机制全部判定失败：

Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=spoof@wrong.example; dkim=fail header.s=sel1; dmarc=fail (p=reject) header.from=bank.example

→ spoof@wrong.example 的 SPF softfail、DKIM fail（选择器 sel1）、策略为 reject 的 DMARC fail - 严格的接收方本应把这样一封邮件退回。

一个伪造的跳 - 时间戳倒退：

Received: by mx.example.com; Tue, 12 Aug 2026 10:15:40 -0700
Received: from a.example by b.example; Tue, 12 Aug 2026 10:15:50 -0700

→ 警告：Hop 2 is timestamped 10.0s BEFORE hop 1 — clock skew between servers or a forged Received header.（第 2 跳的时间戳比第 1 跳早 10.0 秒 - 服务器时钟偏差或伪造的 Received 头。）

补充说明

分析器检查的每一项信号（括号内为严重程度）：

1. Return-Path 与 From 不匹配（critical）- 信封发件人（Return-Path，退信的去向）使用的地址与显示的 From 不同。典型的伪造手法；在合法的邮件列表中继里也常见。
2. Reply-To 与 From 不同（warning）- 回复会被转移到第三个地址。客服台用它很正常，但当 From 是你的银行时就是铁证。
3. 可疑的群发软件标识（warning）- X-Mailer 或 User-Agent 中包含与群发工具相关的标记：bulk、mass mail、massmail、storm、flood、bomber、grabber、harvest、spambot、stealth、anonymous、dark、crack（不区分大小写的子串匹配）。
4. 没有可解析时间戳的跳（info）- 该段的延迟无法计算；显示为 “unknown delay” 徽章。
5. 时间倒退（warning）- 某跳的时间戳早于上一跳：时钟偏差或伪造的 Received 头。
6. 缺少 Authentication-Results 头（info）- 根本无法从这封邮件验证 SPF/DKIM/DMARC 状态。

值得了解的解析器细节：

• 私密： 所有解析 100% 在客户端完成 - 你的邮件头永远不会离开浏览器。
• 邮件头按 RFC 5322 展开（续行以空白字符开头）；解析在第一个空行（正文分隔符）处停止；非邮件头的垃圾行会被跳过。
• 当邮件携带多条 Authentication-Results 头时，每个机制以第一条判定为准；其余的会被忽略。
• 跳的时间戳取自每条 Received 行最后一个 ; 之后（并回退到第一个形似日期的 token），形如 (PDT) 的尾部时区注释会被忽略。
• 缺失的信息只报告、不猜测：未知延迟、无法验证的认证、链路断点全部作为明确的发现呈现，而不是留下一片沉默的空白。
• 相关工具： PII Redactor、Defang / Refang、

  Base64Base64An encoding representing binary data as 64 safe ASCII characters, so it survives transport through text-only channels. It encodes — it does not encrypt.

  。