Source: https://once-email.com/zh_cn/blog/read-received-headers

送达与认证  · 2026年8月3日更新于 2026年8月8日

# 如何阅读 Received 邮件头并还原邮件投递路径

按正确顺序阅读 Received 字段，谨慎比较时间戳，并理解主机名、IP 地址、时钟偏差与不可信追踪信息的证据边界。

[Once Email 工程团队, Once Email author Once Email 工程团队](<https://once-email.com/zh_cn/about>)

审校 Once Email 中文邮件技术审核

这篇指南帮助你完成

读者可以建立统一为 UTC 的投递时间线，识别可能的延迟区间，并准确表述主机名、IP 地址、不一致时钟和发件方可控字段不能证明什么。

文章导读

这篇文章值得阅读的原因

**原创分析**

本文从可信收件边界向前追溯每一跳，说明字段书写顺序、各子句和时区换算，把接收服务器实际观察到的中继证据，与不可信发件方能够预先伪造的头字段明确分开。

**趋势背景**

云中继、过滤网关和隐私代理会增加跳数及字段改写，但可信接收服务器把自己的追踪字段添加到最上方，仍是判断投递路径最有价值的锚点。

**实用价值**

读者可以建立统一为 UTC 的投递时间线，识别可能的延迟区间，并准确表述主机名、IP 地址、不一致时钟和发件方可控字段不能证明什么。

邮件到达收件箱前，可能依次经过应用服务器、外发中继、过滤服务和收件方邮件交换器。每台接收邮件的 SMTP 服务器通常会添加一个 ` Received ` 字段。正确阅读这些字段，可以帮助定位延迟、识别最后把邮件交给收件服务的服务器，并建立投递时间线。

这些字段是诊断证据，不是完整、不可篡改的监管链。发件方可以在投递前伪造较早的行，各服务器时钟也可能不一致，私有基础设施还会隐藏或改写信息。分析时应同时参考提供商日志、邮件认证结果和消息背景。

## [Received 字段记录什么](<https://once-email.com/zh_cn/blog/read-received-headers#received-%E5%AD%97%E6%AE%B5%E8%AE%B0%E5%BD%95%E4%BB%80%E4%B9%88>)

[RFC 5321 第 4.4 节](<https://www.rfc-editor.org/rfc/rfc5321#section-4.4>) 要求，为投递或进一步处理而接收邮件的 SMTP 服务器在最前面添加追踪信息。典型字段如下：

```
Received: from outbound.example.com (outbound.example.com [192.0.2.10])
        by mx.example.net with ESMTPS id ABC123
        for <recipient@example.net>;
        Mon, 03 Aug 2026 10:30:04 +0000
```

常见部分分别回答不同问题：

- ` from ` 描述发送端声明的主机，有时也包含接收服务器在网络连接中看到的地址；
- ` by ` 标识接受这一跳并写下该字段的服务器；
- ` with ` 描述传输协议，例如 ESMTP 或加密 SMTP；
- ` id ` 是队列或事务编号，管理员可用它查询对应服务器日志；
- ` for ` 可能记录某个信封收件人，但它不是必需字段，也可能因隐私被删除；
- 分号后的日期是接收服务器接受邮件的时间，包含数字时区偏移。

并非每行都有全部部分。网关和非 SMTP 系统可能产生不同格式。RFC 5321 也要求接收系统能够容忍意外的追踪格式，而不是仅因某行看起来特殊就拒绝邮件。

## [从底部向上还原路线](<https://once-email.com/zh_cn/blog/read-received-headers#%E4%BB%8E%E5%BA%95%E9%83%A8%E5%90%91%E4%B8%8A%E8%BF%98%E5%8E%9F%E8%B7%AF%E7%BA%BF>)

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
```

正确路线是：

1. ` app.internal.example ` 把邮件交给 ` outbound.sender.example `；
2. 外发服务器交给 ` filter.example.net `；
3. 过滤服务最后交给收件方的 ` mx.recipient.example `。

不要按表面时间戳重新排序。协议确定的字段顺序通常更可靠，因为服务器时钟可能错误或没有同步。只有估算延迟时才把时间转换到同一时区，保存证据时仍应保留原始值。

## [谨慎计算延迟](<https://once-email.com/zh_cn/blog/read-received-headers#%E8%B0%A8%E6%85%8E%E8%AE%A1%E7%AE%97%E5%BB%B6%E8%BF%9F>)

先应用数字时区偏移，再计算相邻接收时间之差。较大的正间隔可能表示排队、限速、临时网络故障或下一服务的处理时间，但单凭间隔无法确定根因。

负间隔通常意味着时钟偏差、解析错误或不可信字段，而不是“时间倒流”，也不能自动证明邮件伪造。应先核对时区处理，并判断两行是否由你控制或信任的系统写入。

调查自有应用时，可以关联：

- 应用请求发送邮件的 UTC 时间；
- 发件服务的队列 ID 和投递日志；
- 第一条由可信基础设施写入的 ` Received ` 字段；
- 收件服务报告的接收或展示时间；
- 发信系统记录的重试状态与 SMTP 响应。

[开发者邮件测试清单](<https://once-email.com/zh_cn/blog/email-testing-checklist>) 介绍了如何记录从请求到到达的完整时间线，避免把一次收件观察当成整个投递系统。

## [明确可信边界](<https://once-email.com/zh_cn/blog/read-received-headers#%E6%98%8E%E7%A1%AE%E5%8F%AF%E4%BF%A1%E8%BE%B9%E7%95%8C>)

最上方的 ` Received ` 字段由离当前邮箱最近的服务器添加。如果你信任该邮箱提供商，这通常是最可靠的起点，因为它能记录提供商实际从哪个网络地址接受连接。

向下检查时，只应信任与已知基础设施一致的字段。邮件进入可信提供商之前声称存在的行可能由发件方伪造。恶意发件者通常不能修改收件方系统随后写入的字段，却可以预先在消息中放入看似真实的追踪文本。

主机名也必须结合来源理解。` from ` 名称可能来自 SMTP 问候、反向 DNS 或本地配置。` 10.0.0.0/8 ` 等私有地址可以描述内部跳转，却无法直接在公网追踪。IP 地理位置只是近似推断，不能证明作者身份或真实物理位置。

## [Received 不能替代 SPF、DKIM 和 DMARC](<https://once-email.com/zh_cn/blog/read-received-headers#received-%E4%B8%8D%E8%83%BD%E6%9B%BF%E4%BB%A3-spfdkim-%E5%92%8C-dmarc>)

` Received ` 描述传输路径；SPF、DKIM 和 DMARC 分别评估域名授权、签名与对齐证据。路线看起来正常的邮件仍可能含恶意内容，合法转发邮件也可能有复杂路线。

应使用[SPF、DKIM 与 DMARC 指南](<https://once-email.com/zh_cn/blog/read-spf-dkim-dmarc-results>) 单独解释认证结果。不能因为可见 ` From ` 地址熟悉，就推断它控制路线中每台主机；也不能因为中继知名，就认为正文、链接和附件一定安全。

## [使用本地邮件头分析器时减少暴露](<https://once-email.com/zh_cn/blog/read-received-headers#%E4%BD%BF%E7%94%A8%E6%9C%AC%E5%9C%B0%E9%82%AE%E4%BB%B6%E5%A4%B4%E5%88%86%E6%9E%90%E5%99%A8%E6%97%B6%E5%87%8F%E5%B0%91%E6%9A%B4%E9%9C%B2>)

Once Email 的[邮件头分析器](<https://once-email.com/zh_cn/tools/email-header-analyzer>) 会在浏览器中提取 ` Received ` 跳转、认证结果和重复字段。只粘贴邮件头，不要粘贴密码、验证码、正文或附件。工具不会联系这些服务器、核实日志，也不能证明字段真实。

分享结果前，在保留顺序和时区偏移的同时替换个人邮箱、公网 IP、队列 ID 与内部主机名。[测试证据脱敏指南](<https://once-email.com/zh_cn/blog/safe-email-test-evidence>) 提供了更安全的报告方法。

## [一份可靠的解释清单](<https://once-email.com/zh_cn/blog/read-received-headers#%E4%B8%80%E4%BB%BD%E5%8F%AF%E9%9D%A0%E7%9A%84%E8%A7%A3%E9%87%8A%E6%B8%85%E5%8D%95>)

先从顶部识别最终接收系统，再从底部向上还原路径。字段顺序优先于时钟；统一时区后标记负间隔和异常长间隔；明确可信基础设施与发件方可控字段之间的边界；如果有授权，使用队列 ID 对照服务器日志。

最重要的是写清结论边界。追踪字段可以支持“收件提供商在这个时间从该中继接受了连接”，但通常不能证明是谁写了邮件、每一条早期路径都真实，或邮件中的链接和附件安全。

## 相关文章

收不到验证邮件？一份安全的排查清单

依次检查地址错误、发件延迟、重试、过滤和邮箱限制，不要反复索取验证码或削弱账号安全。

[收不到验证邮件？一份安全的排查清单](<https://once-email.com/zh_cn/blog/anxiety>)

如何阅读邮件头中的 SPF、DKIM 与 DMARC 结果

理解 SPF、DKIM 和 DMARC 分别认证什么、域名对齐为何重要，以及通过结果为什么只是证据而不是安全证明。

[如何阅读邮件头中的 SPF、DKIM 与 DMARC 结果](<https://once-email.com/zh_cn/blog/read-spf-dkim-dmarc-results>)

Postfix 与 Dovecot 有什么区别：收件服务器职责与排障路径

看懂 Postfix、Dovecot、LMTP、邮件队列和 IMAP 在收件链路中的分工，并按证据判断邮件卡在哪一层。

[Postfix 与 Dovecot 有什么区别：收件服务器职责与排障路径](<https://once-email.com/zh_cn/blog/corecomponent>)

## 使用相关工具

邮件头分析器

解释邮件投递路径并汇总 SPF、DKIM、DMARC 证据，不作绝对真实性承诺。

[邮件头分析器](<https://once-email.com/zh_cn/tools/email-header-analyzer>)

[为什么有些网站拒绝临时邮箱？ 理解网站因账号找回、滥用控制、支持成本和业务风险限制临时邮箱的原因，以及正常用户为什么不应尝试绕过规则。](<https://once-email.com/zh_cn/blog/why-sites-reject-disposable-email>) [下载邮件附件前的安全检查清单 下载附件前检查请求背景、发件人、完整文件名、类型和处理环境，并理解邮件预览、认证结果和扫描工具不能证明什么。](<https://once-email.com/zh_cn/blog/attachment-safety-checklist>)