如何阅读 Received 邮件头并还原邮件投递路径
Once Email 工程团队审校 Once Email 中文邮件技术审核
文章导读
这篇文章值得阅读的原因
- 原创分析
- 本文从可信收件边界向前追溯每一跳，说明字段书写顺序、各子句和时区换算，把接收服务器实际观察到的中继证据，与不可信发件方能够预先伪造的头字段明确分开。
- 趋势背景
- 云中继、过滤网关和隐私代理会增加跳数及字段改写，但可信接收服务器把自己的追踪字段添加到最上方，仍是判断投递路径最有价值的锚点。
- 实用价值
- 读者可以建立统一为 UTC 的投递时间线，识别可能的延迟区间，并准确表述主机名、IP 地址、不一致时钟和发件方可控字段不能证明什么。
本文导航
邮件到达收件箱前，可能依次经过应用服务器、外发中继、过滤服务和收件方邮件交换器。每台接收邮件的 SMTP 服务器通常会添加一个 Received 字段。正确阅读这些字段，可以帮助定位延迟、识别最后把邮件交给收件服务的服务器，并建立投递时间线。
这些字段是诊断证据，不是完整、不可篡改的监管链。发件方可以在投递前伪造较早的行，各服务器时钟也可能不一致，私有基础设施还会隐藏或改写信息。分析时应同时参考提供商日志、邮件认证结果和消息背景。
Received 字段记录什么
RFC 5321 第 4.4 节要求，为投递或进一步处理而接收邮件的 SMTP 服务器在最前面添加追踪信息。典型字段如下：
Received: from outbound.example.com (outbound.example.com [192.0.2.10])
by mx.example.net with ESMTPS id ABC123
for <[email protected]>;
Mon, 03 Aug 2026 10:30:04 +0000
常见部分分别回答不同问题：
from描述发送端声明的主机，有时也包含接收服务器在网络连接中看到的地址；by标识接受这一跳并写下该字段的服务器；with描述传输协议，例如 ESMTP 或加密 SMTP；id是队列或事务编号，管理员可用它查询对应服务器日志；for可能记录某个信封收件人，但它不是必需字段，也可能因隐私被删除；- 分号后的日期是接收服务器接受邮件的时间，包含数字时区偏移。
并非每行都有全部部分。网关和非 SMTP 系统可能产生不同格式。RFC 5321 也要求接收系统能够容忍意外的追踪格式，而不是仅因某行看起来特殊就拒绝邮件。
从底部向上还原路线
SMTP 服务器会把新的 Received 字段放在已有字段上方。因此头部最上方是最新一跳，最底部通常是最早记录的一跳。
例如：
Received: from filter.example.net by mx.recipient.example;
Mon, 03 Aug 2026 10:30:07 +0000
Received: from outbound.sender.example by filter.example.net;
Mon, 03 Aug 2026 10:30:04 +0000
Received: from app.internal.example by outbound.sender.example;
Mon, 03 Aug 2026 10:29:59 +0000
正确路线是：
app.internal.example把邮件交给outbound.sender.example；- 外发服务器交给
filter.example.net； - 过滤服务最后交给收件方的
mx.recipient.example。
不要按表面时间戳重新排序。协议确定的字段顺序通常更可靠，因为服务器时钟可能错误或没有同步。只有估算延迟时才把时间转换到同一时区，保存证据时仍应保留原始值。
谨慎计算延迟
先应用数字时区偏移，再计算相邻接收时间之差。较大的正间隔可能表示排队、限速、临时网络故障或下一服务的处理时间，但单凭间隔无法确定根因。
负间隔通常意味着时钟偏差、解析错误或不可信字段，而不是“时间倒流”，也不能自动证明邮件伪造。应先核对时区处理，并判断两行是否由你控制或信任的系统写入。
调查自有应用时，可以关联：
- 应用请求发送邮件的 UTC 时间；
- 发件服务的队列 ID 和投递日志；
- 第一条由可信基础设施写入的
Received字段； - 收件服务报告的接收或展示时间；
- 发信系统记录的重试状态与 SMTP 响应。
开发者邮件测试清单介绍了如何记录从请求到到达的完整时间线，避免把一次收件观察当成整个投递系统。
明确可信边界
最上方的 Received 字段由离当前邮箱最近的服务器添加。如果你信任该邮箱提供商，这通常是最可靠的起点，因为它能记录提供商实际从哪个网络地址接受连接。
向下检查时，只应信任与已知基础设施一致的字段。邮件进入可信提供商之前声称存在的行可能由发件方伪造。恶意发件者通常不能修改收件方系统随后写入的字段，却可以预先在消息中放入看似真实的追踪文本。
主机名也必须结合来源理解。from 名称可能来自 SMTP 问候、反向 DNS 或本地配置。10.0.0.0/8 等私有地址可以描述内部跳转，却无法直接在公网追踪。IP 地理位置只是近似推断，不能证明作者身份或真实物理位置。
Received 不能替代 SPF、DKIM 和 DMARC
Received 描述传输路径；SPF、DKIM 和 DMARC 分别评估域名授权、签名与对齐证据。路线看起来正常的邮件仍可能含恶意内容，合法转发邮件也可能有复杂路线。
应使用SPF、DKIM 与 DMARC 指南单独解释认证结果。不能因为可见 From 地址熟悉，就推断它控制路线中每台主机；也不能因为中继知名，就认为正文、链接和附件一定安全。
使用本地邮件头分析器时减少暴露
Once Email 的邮件头分析器会在浏览器中提取 Received 跳转、认证结果和重复字段。只粘贴邮件头，不要粘贴密码、验证码、正文或附件。工具不会联系这些服务器、核实日志，也不能证明字段真实。
分享结果前，在保留顺序和时区偏移的同时替换个人邮箱、公网 IP、队列 ID 与内部主机名。测试证据脱敏指南提供了更安全的报告方法。
一份可靠的解释清单
先从顶部识别最终接收系统，再从底部向上还原路径。字段顺序优先于时钟；统一时区后标记负间隔和异常长间隔；明确可信基础设施与发件方可控字段之间的边界；如果有授权，使用队列 ID 对照服务器日志。
最重要的是写清结论边界。追踪字段可以支持“收件提供商在这个时间从该中继接受了连接”，但通常不能证明是谁写了邮件、每一条早期路径都真实，或邮件中的链接和附件安全。