邮件标头分析工具（メールヘッダー解析ツール）
粘贴收到邮件的原始标头（Received:、Authentication-Results: 等），即可逐跳解析投递路径，并列出 SPF/DKIM/DMARC 认证结果。全部解析在浏览器内完成。
Received: 标头各字段的含义
| 字段 | 含义 |
|---|---|
| from | 将此邮件交过来的上一台服务器的主机名/IP地址，由写入这一行的接收端服务器记录。发件人可以随意添加伪造的 Received 行，因此越早的行越容易被伪造。判断真实发件IP时，请使用由您自己管理的接收服务器写入的行中最早的一行（在本工具的列表中，即 by 第一次出现您自己服务器的那一跳）的 from。 |
| by | 在这一跳接收邮件的服务器（例如你自己的邮件服务器）的主机名。 |
| with | 本次投递所使用的协议（如 ESMTP、ESMTPS、SMTP）。ESMTPS 表示该连接使用 TLS 加密。 |
| for | 本次投递的目标收件人地址。邮件列表或多个收件人时通常会省略。 |
| timestamp | 此跳接收邮件的日期和时间。时间和时区由写入这一行的接收端服务器记录（RFC 5321 §4.4）。各跳之间的时间差可粗略估算投递延迟。 |
Authentication-Results: 各字段的含义
| 字段 | 含义 |
|---|---|
| SPF | SPF（发件人策略框架）认证结果：验证发件IP是否包含在发件域名DNS记录所允许的地址列表中。 |
| DKIM | DKIM（域名密钥识别邮件）认证结果：验证邮件正文及主要标头的数字签名，能否用发件域名的公钥成功校验。 |
| DMARC | DMARC（基于域名的邮件认证、报告与一致性）认证结果：综合校验 SPF、DKIM 结果与 From 标头域名是否一致（对齐）的最终判定。 |
由邮件标头追踪投递的路径
把所收邮件的原始标头贴进来，本工具便将 Received: 逐跳拆开，把投递的路径摊出来，并把 Authentication-Results: 中所记的 SPF、DKIM、DMARC 判定一并列出。整套解析都在浏览器内完成，贴入的东西不会被送往任何地方。
读它时头一件要明白的，是 Received: 须由下往上读。 每台服务器收到邮件，便把自己那一行添在最顶上，故而最早的一程在最底下，最后收下它的服务器在最顶上。 更要紧的是：这些标头人人都伪造得来。 发信方尽可捏造任意多条 Received: 摆在开头。可信的只有您自家管辖的服务器所写的那一行，以及其上的一切；其下的种种，不过是「某人如此宣称」罢了。Authentication-Results: 亦然——不看清那判定出自哪台服务器，判定本身便可能是假的。
使用方法
- 贴入原始标头 可自邮件客户端的「显示原始邮件」「查看源代码」处取得。
- 由下往上读 Received 最底下是最初的发信方，最顶上是最后收下它的服务器。
- 查看认证的结果 SPF、DKIM、DMARC 的判定一并摆出。
- 弄清信任自何处起 您自家管辖的服务器所写那一行之下的种种，皆可能是伪造的。
用好本工具的小技巧
- 在 Gmail 中，打开邮件后点击右上角的竖三点菜单，选择"显示原始邮件"即可获取原始标头。在 Outlook 中可通过"文件"→"属性"→"Internet 标头"查看。
- Received: 标头在邮件正文中是按照最新在前（接收方在最上方）的顺序追加的，本工具会自动将其重新排序为从发件方到收件方的时间顺序。
- 如果链路中的邮件服务器时钟存在细微偏差，"相对上一跳的延迟"可能显示为负数。几秒级别的负值通常只是时钟不同步造成的，并非真正的投递异常。
- 即使 SPF、DKIM、DMARC 全部通过，也不能保证该邮件不是诈骗邮件。这些认证只能验证发件域名所有者自身配置的流程被正确执行，无法检测出攻击者合法拥有的仿冒域名。
- 如果发现某两跳之间延迟骤增，说明该段路径上的邮件服务器很可能发生了投递阻塞或被垃圾邮件过滤器拦截。
这些场景会用到
查究垃圾邮件的出处
真正的发信地址，现于您信得过的最底下那条 Received: 之中。
识破冒名
显示名与 From 一行伪造起来易如反掌，故当凭认证结果来判断。
追查投递的迟滞
读一读各跳的时刻，便知邮件在何处停滞。
确认自家邮件是否通过认证
给自己发一封测试信，看 SPF、DKIM、DMARC 是否尽皆通过。
邮件标头的术语
- Received
- 每台收信服务器把自己那一行添在最顶上的标头。 路径须由下往上读。
- Authentication-Results
- 记录收信一方所作 SPF、DKIM、DMARC 判定的标头。要紧的是它出自哪台服务器。
- Return-Path
- 投递失败时退回之处。SPF 正是针对这个域名来查的。
- From
- 所显示的寄件人。此处任人书写，故不足以证明是谁寄的。
- Message-ID
- 唯一标识一封邮件的字符串，用以分辨同一封邮件的重复。
- 跳
- 邮件所经的一台服务器。每一跳留下一条
Received:。
常见问题
闲话 ― 邮件标头是一叠"数字邮戳"
正如信件上的邮戳记录了哪个邮局在何时处理了它，电子邮件的 Received: 标头也是一叠"数字邮戳"——每一台转发过这封邮件的服务器都会在其上盖上自己的时间戳。SMTP 协议（RFC 5321）要求每一台中继服务器都必须把自己的信息添加到标头的最前面，于是每封邮件都会自然而然地积累起一份完整的投递路径记录。
这套机制在追查垃圾邮件来源时最为实用。但需要注意的是，Received: 标头和发件人栏（From 标头）一样，发件人可以随意伪造。发件人可以在发出邮件之前添加任意多条伪造的 Received: 行，因此越早（越靠下）的行越有可能是伪造的。真正可以信任的，只有由您自己管理的接收服务器写入的行。其中最早的一行，是您的服务器接受外部连接时记录的，其 from 中的连接来源IP地址是发件人无法伪造的。反垃圾邮件专家首先查看的，正是这个“由自己的服务器记录的第一个连接来源”。
SPF、DKIM、DMARC 这三项认证技术，正是为了弥补仅靠"邮戳"无法阻止的仿冒行为而后来加入的。SPF 核对发件IP是否在该域名的许可列表中，DKIM 通过数字签名验证邮件内容未被篡改，DMARC 则综合以上两者与 From 标头域名的一致性做出最终判定。2024年 Google 和 Yahoo 事实上要求大批量发件方必须配置 DMARC 之后，Authentication-Results: 标头也开始频繁出现在普通用户的收件箱中。
平时几乎没人会去打开邮件标头，但一旦打开，你会发现其中精确记录着这封邮件曾经过地球上的哪些服务器、每一步各花费了多少秒——这是一段肉眼看不见的互联网旅程日志。