如何通过邮件头识别钓鱼邮件
逐行解读可疑邮件的邮件头：From、Reply-To 和 Return-Path，Received 链，以及 SPF、DKIM 和 DMARC 结果到底能证明什么。
PureTempMail 团队
设计并运营 PureTempMail 的工程师
简短回答
打开邮件原始内容，检查三件事：From 行中的域名是否通过了 DMARC，Reply-To 是否指向别处，以及最早的那行 Received 是否来自该公司自己的服务器。任何一项不通过都是强烈的警告。三项全部通过，也只能证明这封邮件是谁发的，并不能证明发件人是诚实的。
每封邮件在你阅读的正文上方都带着一段邮件头。邮件应用会把它隐藏起来，但它记录了邮件来自哪台服务器、由哪个域名为它担保，以及你的回复实际会发往哪里。钓鱼邮件往往就在这里露出马脚，即使正文看起来天衣无缝。
我们运营着一台只收不发的邮件服务器，每当有邮件表现异常，我们读的就是原始邮件头。本指南会逐行讲解一段真实感很强的钓鱼邮件头，然后展示更难的情况：所有检查全部通过。你可以一边阅读，一边把任意邮件的邮件头粘贴到我们的邮件头分析工具中。它在你的浏览器中运行，邮件头永远不会发送到我们的服务器。
第一步：从邮件应用中取出邮件头
所有邮件客户端默认都会隐藏邮件头。在 Gmail 中，打开邮件，点击“回复”旁边的三点菜单，选择显示原始邮件。在 Outlook 网页版中，打开三点菜单，然后依次选择查看和查看邮件源。在 Mac 上的 Apple Mail 中，依次选择显示、邮件、所有邮件头。邮件头分析工具页面还列出了 Windows 版 Outlook、Yahoo 等客户端的菜单路径。
复制第一个空行之上的全部内容，那就是邮件头。正文在空行之后，不需要复制。在 iPhone 和 iPad 上，系统自带的“邮件”应用完全不显示邮件头，所以请把邮件转发到电脑上，或者在网页版邮箱中查看。
逐行解读一封钓鱼邮件的邮件头
下面是一封典型的“账户警报”钓鱼邮件的邮件头，只保留了关键的几行。其中的域名和地址都是虚构的占位符，但这种模式我们见过无数次。邮件头按从新到旧的顺序叠放，所以把邮件投递给你的服务器在靠上的位置，邮件的起点在更下面。
Return-Path: <[email protected]> Authentication-Results: mx.example.com; spf=pass smtp.mailfrom=mail.example.net; dkim=none; dmarc=fail (p=none) header.from=examplebank.com Received: from mail.example.net (unknown [203.0.113.45]) by mx.example.com with ESMTPS; Thu, 29 Oct 2026 09:14:07 +0000 Received: from desktop-4kq2 (unknown [198.51.100.23]) by mail.example.net with ESMTPA; Thu, 29 Oct 2026 09:14:05 +0000 From: "Example Bank Security" <[email protected]> Reply-To: [email protected] To: [email protected] Subject: Unusual sign-in: confirm your account within 24 hours Date: Thu, 29 Oct 2026 09:14:02 +0000 Message-ID: <20261029091402.4471@desktop-4kq2>
每一行告诉你什么
- Return-Path
- 退信发往的地址，也叫信封发件人。这里它在
mail.example.net上，而不是银行的域名。单看这一点说明不了什么，因为通过邮件群发服务商发送的新闻通讯也是这个样子。先记住它，再看后面几行。 - Authentication-Results
- 邮件到达时，你的邮件服务商记录下的检查结论。SPF 通过了，但通过的是
mail.example.net，也就是攻击者的服务器。没有 DKIM 签名。DMARC 是唯一会检查你实际看到的 From 域名的检查，它对examplebank.com的结果是失败。这是整段邮件头中最有用的一行。 - Received（顶部）
- 由你自己的邮件服务商的服务器
mx.example.com在接收来自203.0.113.45的邮件时添加。你的服务商写下的行是可信的。在这一行以下的所有内容，都是由你一无所知的机器写的。 - Received（底部）
- 这是最早的一跳，所以要从下往上读这条链。邮件起始于一台自称
desktop-4kq2的机器，通过登录后提交（ESMTPA）交给了mail.example.net。银行的警报系统不会运行在某个人的台式机上，被盗或租来的邮箱才会。 - From
- 显示名称写着 Example Bank Security，地址自称来自
examplebank.com。任何人都可以在这个字段里随便填写。上面的 DMARC 失败，就是这一行 From 被伪造的证据。 - Reply-To
- 如果你点击回复，你的回信会发往
example.org，这是第三个域名。一家希望你打电话或登录的银行，没有理由在别人的域名上收集回复。要求你回信提供资料的钓鱼邮件，几乎都会设置这一项。 - Subject 和 Date
- 紧迫感加上截止时间。Date 只是发件机器自己声称的时间，但可以和 Received 的时间戳对比：如果 Date 与第一跳之间相差数小时甚至数天，可能说明这封邮件在到达你之前，曾在某个垃圾邮件队列里排队。
- Message-ID
- 由发件软件生成的唯一 ID。大公司的系统会在其中加上自己的域名。这一个的结尾是
desktop-4kq2，正是底部 Received 行中那台家用机器。这里不一致只是一个线索，不是证据，因为很多正规软件使用的是通用 ID。
把这些放在一起，来龙去脉就很清楚了：一封自称来自银行的邮件，从一台台式机经由陌生人的邮件服务器发出，没有通过银行自己的身份验证，还想让你把回复发到第三个域名。只要知道该看哪里，不到一分钟就能得出这个结论，而邮件头分析工具会替你标出 DMARC 失败和 Reply-To 不一致。
用大白话讲清 SPF、DKIM 和 DMARC
这三项检查是邮件头中由接收服务器在测试邮件后写下的部分，而不是发件人自己填写的文字。每一项回答的是不同的问题。
- SPF
- 这台服务器是否有权代表信封发件人的域名发信？域名所有者在 DNS 中发布一份允许发信的服务器清单，接收方把它与连接过来的 IP 地址进行比对。SPF 检查的是 Return-Path 的域名，而不是你看到的 From 地址，所以钓鱼邮件可以为它自己的域名通过 SPF。参见术语表中的 SPF。
- DKIM
- 这封邮件是否由某个域名签名，签名后是否被改动过？发件服务器添加一个加密签名，接收方用签名方 DNS 中的公钥来验证它。
header.d=的值就是签名的域名。来自一个无关域名的有效签名，对 From 行中的品牌说明不了任何问题。 - DMARC
- From 行中的域名是否与通过 SPF 或 DKIM 的域名一致？正是这一步“对齐”，把各项检查和你实际看到的名称绑定在一起。DMARC 还允许域名所有者告诉接收方如何处理失败的邮件：不处理（
p=none）、隔离或拒收。这就是为什么在真正的公司还没有启用强制策略时，伪造的邮件仍可能进入你的收件箱。
每种结果的含义
| 结果 | 含义 | 需要多担心 |
|---|---|---|
pass（通过） | 针对旁边列出的域名，检查成功。 | 低，但要看清是哪个域名通过的。仿冒域名通过了检查，那仍然是钓鱼邮件。 |
fail（失败） | 按照该域名自己的规则，这封邮件不应该从它实际的来源发出。 | 如果是你认识的品牌 DMARC 失败，就要高度警惕。 |
softfail（软失败） | 仅限 SPF。域名表示这台服务器很可能无权发信，但请接收方不要直接拒收。 | 中等。在邮件转发和维护不善的 SPF 记录中很常见，和其他警告同时出现时才可疑。 |
neutral（中立） | 域名对这台服务器不作任何表态。 | 视为没有证据。 |
none（无） | 没有可供检查的记录或签名。 | 对大公司而言属于中等，因为它们通常三项都会发布。 |
temperror / permerror（临时错误 / 永久错误） | 检查无法执行：DNS 超时，或者发件方的记录有误。 | 单独出现时较低。请看其他结果。 |
更难的情况：所有检查全部通过
谨慎的攻击者根本不会伪造银行的域名。他们注册一个相似的域名，正确配置好 SPF、DKIM 和 DMARC，然后用它发信。这时邮件头看起来无懈可击：
Authentication-Results: mx.example.com;
spf=pass smtp.mailfrom=examplebank-secure.com;
dkim=pass header.d=examplebank-secure.com;
dmarc=pass header.from=examplebank-secure.com
From: "Example Bank" <[email protected]>身份验证证明这封邮件确实是 examplebank-secure.com 发出的。但它无法告诉你这个域名是否属于你的银行。这部分要靠你自己，归根结底就是非常缓慢地读一遍域名本身。以下是我们最常见到的花招：
- 多出来的词。真实名称加上
-secure、-login、-support或-verify。 - 替换字符。用
rn冒充m，用数字 0 冒充字母 o，或者多一个、少一个字母。 - 不同的后缀。名称没错，但用的是
.co、.net或某个新的顶级域名，而不是该公司实际使用的后缀。 - 把真实名称放进子域名。在
examplebank.com.account-check.net中，真正的域名是account-check.net。请从右往左读域名。 - 外观相似的字母表。西里尔字母 а 看起来和拉丁字母 a 一模一样。在原始邮件头中，这类域名常以
xn--开头，这是非拉丁字母域名的编码方式。 - 靠显示名称撑场面。在一个免费网页邮箱域名的地址前面写上“Example Bank”。很多手机只显示名称，所以请点开它查看真实地址。
如果你不确定某个域名是否属于该公司，不要用邮件里的任何东西去查证。自己在浏览器中输入该公司的网址，然后进行比较。
邮件头中的危险信号，按严重程度排序
有些信号几乎等同于证据，另一些只有叠加在一起时才有分量。下面大致是我们衡量它们的方式。
| 信号 | 在哪里看 | 分量 |
|---|---|---|
| 知名品牌的 DMARC 失败 | Authentication-Results，dmarc=fail header.from= | 强。From 行很可能是伪造的。 |
| From 域名与真实域名相近但不完全相同 | From，以及 header.from= 的值 | 强，即使所有检查都通过。 |
| Reply-To 在另一个域名上 | Reply-To | 当邮件要求你回复时为强。 |
| 第一跳是家用机器或无关的服务商 | 最底部的 Received 行 | 中等。正规邮件通常始于公司内部或其邮件群发服务商。 |
| 完全没有身份验证结果 | 缺少 Authentication-Results | 对大品牌而言为中等，因为它们会发布 SPF、DKIM 和 DMARC。 |
| Message-ID 的域名与发件人无关 | Message-ID | 弱。只能作为辅助证据。 |
| Return-Path 在另一个域名上 | Return-Path | 弱。通过邮件群发服务发送的新闻通讯通常就是这样。 |
检查任何可疑邮件的五分钟流程
复制完整的邮件头
按上文所述使用“显示原始邮件”或“查看邮件源”，复制整段内容，包括每一行 Received。
粘贴到邮件头分析工具中
我们的邮件头分析工具会把 From、Reply-To 和 Return-Path 并排列出，显示 SPF、DKIM 和 DMARC 的结果，并按从早到晚的顺序列出投递路线。解析在你的浏览器中完成。
对照 From 域名检查 DMARC
找到
dmarc=和它旁边的域名。如果是你熟悉的品牌显示失败，就可以到此为止，直接删除这封邮件。从右往左，慢慢读每一个域名
From、Reply-To 以及通过 DKIM 的域名都应该属于该公司。留意上面提到的仿冒花招。
从底部开始读 Received 链
最下面一行是邮件的起点。只信任你自己的服务商在顶部添加的行。发件人可以在其下方插入伪造的 Received 行，甚至伪造的 Authentication-Results 行。
不点击，先检查链接
邮件头不会显示正文中的链接。在电脑上，把鼠标悬停在每个按钮上，读一读窗口角落显示的地址。凡是不指向该公司真实域名的链接，都是你该离开的理由。
如果你认为这是钓鱼邮件
- 不要点击、回复或打开附件。回复会确认你的地址有人在看，而附件是恶意软件最常见的入侵途径。
- 通过其他途径联系该公司。自己在浏览器中输入它的网址，或者拨打你的银行卡或合同上的电话号码，绝不要用邮件里的。
- 在邮件应用中举报。在 Gmail 中，使用三点菜单中的举报网上诱骗。在 Outlook 中，使用报告，然后选择报告网络钓鱼。这会帮助该服务为所有用户训练过滤器。
- 转发给反网络钓鱼工作组（Anti-Phishing Working Group），地址是
[email protected]，它会把举报分享给安全公司和浏览器厂商。 - 在美国，可以向 FTC 举报，网址是 ReportFraud.ftc.gov，尤其是涉及钱财或个人信息时。
- 如果你已经输入了密码，请立即在真实网站上修改密码，开启两步验证，并在其他所有重复使用过该密码的地方一并修改。我们的如何检查邮箱是否遭遇数据泄露指南介绍了信息泄露后第一个小时该做什么。
结论
要通过邮件头识别钓鱼邮件，只信任你自己的服务商写下的内容，确认 From 行中的确切域名通过了 DMARC，并仔细阅读这个域名，以识破仿冒。这三个习惯能拦住大多数伪造邮件。对于其余的情况，最安全的做法一如既往：直接联系该公司，而不是通过邮件。下次遇到可疑邮件，把它粘贴到邮件头分析工具中看看结果。
资料来源
- IETF，RFC 7208: Sender Policy Framework (SPF)，其中包括 pass、fail、softfail 和 neutral 的含义。
- IETF，RFC 6376: DomainKeys Identified Mail (DKIM) Signatures。
- IETF，RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)，于 2026 年发布，取代 RFC 7489。
- IETF，RFC 8601: Message Header Field for Indicating Message Authentication Status，定义了 Authentication-Results 邮件头。
- 美国联邦贸易委员会（FTC），How to Recognize and Avoid Phishing Scams，提供 FTC 和 APWG 的举报地址。
- 反网络钓鱼工作组（APWG），Report Phishing。