1982年8月，Jon Postel发布了RFC 821，定义了简单邮件传输协议（SMTP）。这份文档奠定了一个影响至今的设计假设：网络上的所有用户都是可信的。四十多年后的今天，这个假设已经酿成了一场全球性的信任危机——商业邮件欺诈（BEC）在2024年造成了超过27亿美元的损失，而部署了完整邮件认证体系的域名仅占全球域名的10.7%。

这不是一个关于"技术不够先进"的故事，而是一个关于"信任模型设计失误"如何被一层层补丁修补，却始终无法根除隐患的技术博弈史。

一个没有身份验证的协议是如何诞生的

当SMTP在1980年代初期被设计时，互联网还是一个小型的、封闭的学术社区。ARPANET上的用户大多是研究人员和军方人员，彼此之间存在天然的信任关系。在这种环境下，Postel和他的同事们做了一个看似合理但后果深远的设计决策：SMTP协议本身不提供任何发送者身份验证机制。

SMTP协议的核心设计是"信封"概念。就像传统邮件一样，SMTP区分了两个关键概念：MAIL FROM（信封上的寄件人地址）和RCPT TO（收件人地址）。但与传统邮件不同的是，SMTP允许任何人声称自己来自任何域名——协议本身不会验证这个声明是否属实。

sequenceDiagram
    participant 攻击者
    participant SMTP服务器
    participant 收件人
    
    攻击者->>SMTP服务器: HELO attacker.com
    SMTP服务器->>攻击者: 250 OK
    攻击者->>SMTP服务器: MAIL FROM: <[email protected]>
    SMTP服务器->>攻击者: 250 OK
    攻击者->>SMTP服务器: RCPT TO: <[email protected]>
    SMTP服务器->>攻击者: 250 OK
    攻击者->>SMTP服务器: DATA
    攻击者->>SMTP服务器: From: CEO <[email protected]><br/>紧急转账请求...
    SMTP服务器->>收件人: 投递邮件
    Note over 收件人: 收件人看到来自<br/>legitimate-bank.com的邮件

这种设计导致了一个严重的副作用：开放式中继（Open Relay）。在SMTP的原始设计中，每个邮件服务器都被设计为中继——它不仅接受发往本地用户的邮件，还会转发发往其他服务器的邮件。到1998年，互联网邮件联盟的调查显示，全球约55%的邮件服务器是开放式中继。这意味着任何人都可以利用这些服务器发送大量垃圾邮件，而真正的来源却无法追踪。

timeline
    title 邮件安全协议四十年演进史
    section 1980年代 
        1982 : RFC 821发布<br/>SMTP协议诞生
        1988 : Morris蠕虫爆发<br/>催生CERT
    section 1990年代
        1998 : 开放式中继达55%<br/>黑名单机制兴起
    section 2000年代
        2003 : SPF协议提出
        2005 : DKIM协议提出
    section 2010年代
        2012 : DMARC协议发布
        2016 : ARC协议标准化
        2017 : MTA-STS定义
    section 2020年代
        2020 : 18种认证绕过攻击披露
        2023 : SMTP走私攻击披露
        2025 : PCI DSS 4.0强制DMARC

1988年11月2日，Morris蠕虫的爆发首次向世人展示了互联网协议缺乏安全验证的后果。虽然这个蠕虫主要利用的是finger和sendmail的缓冲区溢出漏洞，但它揭示了一个更深层的问题：在缺乏身份验证的网络环境中，恶意代码可以以指数级速度传播。这次事件催生了第一个计算机应急响应小组（CERT），但SMTP协议的根本缺陷——缺乏发送者身份验证——并没有被立即解决。

到了1990年代中期，垃圾邮件问题开始失控。营销人员发现了SMTP的漏洞：只要声称自己来自任何地址，就可以向任何人发送邮件。1998年，互联网邮件联盟的数据显示，开放式中继服务器的比例高达55%。但仅仅四年后，这个数字就降到了1%以下——不是因为协议被修复了，而是因为黑名单机制的广泛部署。各大邮件服务商开始维护IP黑名单，拒绝接受来自已知垃圾邮件源的连接。

这是一种"治标不治本"的方案。黑名单可以阻止已知的恶意发送者，但无法防止新的攻击者。更关键的是，黑名单机制无法解决一个核心问题：如何验证邮件确实来自它声称的域名。

第一道防线：基于IP地址的信任（SPF）

2003年，一种新的验证机制开始获得关注：发送者策略框架（Sender Policy Framework，SPF）。SPF的核心思想简单而直接：域名所有者在DNS中发布一个列表，声明哪些IP地址有权发送来自该域名的邮件。

SPF的工作流程如下：当邮件服务器收到一封声称来自example.com的邮件时，它会查询example.com的DNS记录，获取该域名的SPF策略。SPF策略以TXT记录的形式存储，例如：

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 -all"

这条记录的含义是：只有来自192.0.2.0/24网段和198.51.100.123这个IP的邮件才是合法的，其他所有来源都应该被拒绝（-all）。

SPF验证分为几个步骤：首先检查SMTP会话中的HELO命令（服务器声称的身份），然后检查MAIL FROM命令（信封寄件人地址）。如果发送服务器的IP地址不在SPF策略允许的范围内，邮件可能会被标记为可疑、放入垃圾邮件文件夹，或直接被拒绝。

flowchart TD
    A[接收邮件服务器收到邮件] --> B[提取MAIL FROM域名]
    B --> C[DNS查询SPF记录]
    C --> D{IP地址匹配检查}
    D -->|匹配| E[SPF Pass]
    D -->|不匹配| F[SPF Fail]
    D -->|无SPF记录| G[SPF None]
    E --> H[邮件继续处理]
    F --> I[根据策略处理:<br/>拒绝/标记/放行]
    G --> H

然而，SPF存在一个致命的结构性缺陷：它无法处理邮件转发。当邮件从一个服务器转发到另一个服务器时，转发服务器的IP地址显然不在原始域名的SPF策略中。这意味着合法的转发邮件会通不过SPF验证。

考虑这样一个常见场景：用户在大学期间注册了[email protected]，毕业后设置了自动转发到[email protected]。当有人给[email protected]发邮件时，大学的邮件服务器会将邮件转发到company.com的邮件服务器。但company.com的服务器在进行SPF验证时，检查的是原始发件人的域名——而转发服务器的IP地址显然不在该域名的SPF记录中。

sequenceDiagram
    participant 发件人
    participant 大学邮件服务器
    participant 公司邮件服务器
    participant 收件人邮箱
    
    发件人->>大学邮件服务器: 发送邮件到[email protected]
    大学邮件服务器->>大学邮件服务器: SPF验证通过<br/>（发件人IP在SPF记录中）
    大学邮件服务器->>公司邮件服务器: 转发邮件到[email protected]
    Note over 公司邮件服务器: SPF验证！<br/>转发服务器IP不在<br/>原始发件人SPF记录中
    公司邮件服务器->>公司邮件服务器: SPF验证失败
    公司邮件服务器->>收件人邮箱: 邮件被标记或拒绝
    Note over 收件人邮箱: 合法邮件被误判！

这个问题的根源在于SPF验证的是SMTP会话中的发送者IP，而不是邮件本身的真实来源。邮件转发是SMTP协议的正常功能，但SPF的设计使这一功能变得"非法"。

第二道防线：密码学签名（DKIM）

为了解决SPF的局限性，DomainKeys Identified Mail（DKIM）于2005年被提出。DKIM采用了一种完全不同的验证方法：密码学签名。

DKIM的工作原理类似于数字签名：发送服务器使用私钥对邮件的特定部分进行签名，并将签名附加到邮件头中。接收服务器通过DNS查询获取发送域名的公钥，验证签名的有效性。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 
  d=example.com; s=selector1; 
  h=from:to:subject:date;
  bh=2jUSO9Puv3dO8og7H3zqJ1Ll1REaMvJ4k5DnFwXyZ+Q=;
  b=Base64EncodedSignature...

关键字段的含义：

  • d=：签名者的域名
  • s=：选择器，用于构造公钥查询的DNS路径
  • h=：被签名的邮件头字段列表
  • bh=：邮件正文的哈希值
  • b=：实际的数字签名

DKIM的一个关键优势是签名会随邮件一起传输，即使邮件经过多次转发，签名仍然有效。这解决了SPF在转发场景下的问题。

flowchart LR
    subgraph 发送方
        A[邮件内容] --> B[计算内容哈希]
        B --> C[使用私钥签名]
        C --> D[添加DKIM-Signature头]
    end
    
    subgraph 传输
        D --> E[邮件传输]
    end
    
    subgraph 接收方
        E --> F[提取DKIM-Signature]
        F --> G[DNS查询公钥]
        G --> H[验证签名]
        H --> I{验证结果}
        I -->|成功| J[DKIM Pass]
        I -->|失败| K[DKIM Fail]
    end

但DKIM同样存在设计缺陷。最严重的问题是：DKIM签名的是邮件的某些部分，而不是发送者的身份。DKIM验证通过只意味着"这封邮件确实经过d=所声明域名的授权"，但并不验证From头中的地址是否与签名域名一致。

换句话说，攻击者可以从attack.com发送一封邮件，使用attack.com的DKIM签名，但在From头中声称自己是[email protected]。如果接收服务器只检查DKIM验证结果，这封邮件会通过验证——因为签名确实是有效的，只是签名的域名与显示的发件人域名不一致。

第三道防线：策略统一（DMARC）

2012年1月，一个旨在整合SPF和DKIM的协议诞生了：Domain-based Message Authentication, Reporting and Conformance（DMARC）。DMARC解决的是前两个协议留下的最后一块拼图：发送者身份的对齐问题。

DMARC的核心机制是"标识符对齐"（Identifier Alignment）。它要求邮件不仅要通过SPF或DKIM验证，而且验证通过的域名必须与From头中显示的域名一致。

DMARC定义了三种对齐模式：

  • SPF对齐：SPF验证通过的域名（MAIL FROM域名）与From头域名一致
  • DKIM对齐：DKIM签名中的d=域名与From头域名一致
  • 策略模式：指定当验证失败时接收方应采取的行动

DMARC策略通过DNS TXT记录发布，例如：

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
  • p=none：仅监控，不采取行动
  • p=quarantine：将验证失败的邮件放入垃圾邮件文件夹
  • p=reject：直接拒绝验证失败的邮件

DMARC还引入了报告机制。域名所有者可以指定一个接收报告的地址，定期收到关于其域名邮件验证情况的汇总报告。这对于发现配置问题和未授权的发送源至关重要。

flowchart TD
    A[收到邮件] --> B[SPF验证]
    A --> C[DKIM验证]
    B --> D{SPF通过?}
    C --> E{DKIM通过?}
    D -->|是| F[检查SPF对齐]
    E -->|是| G[检查DKIM对齐]
    F --> H{SPF域名与From头匹配?}
    G --> I{DKIM域名与From头匹配?}
    H -->|是| J[DMARC Pass]
    I -->|是| J
    H -->|否| K{DKIM对齐通过?}
    I -->|否| K
    K -->|是| J
    K -->|否| L[DMARC Fail]
    L --> M[查询DMARC策略]
    M --> N{策略是什么?}
    N -->|p=none| O[放行但记录]
    N -->|p=quarantine| P[放入垃圾邮件]
    N -->|p=reject| Q[拒绝邮件]

为什么这些协议仍然不够

到2024年，SPF、DKIM和DMARC已经成为邮件安全的标准配置。但部署数据令人担忧：根据DmarcDkim.com的实时统计，全球只有10.7%的域名拥有完整的DMARC保护（p=reject策略），70.9%的域名完全没有DMARC记录。

更关键的是，即使正确部署了这三个协议，邮件系统仍然存在被绕过的风险。USENIX Security 2020发表的一篇题为《Composition Kills》的论文揭示了18种绕过邮件认证系统的攻击方法，所有测试的10个邮件服务商和19个邮件客户端都存在多种漏洞。

攻击向量一：组件间的不一致解释

邮件系统由多个独立开发的组件构成——SMTP服务器、DKIM验证模块、DNS解析器、邮件客户端。这些组件对同一份邮件内容的解释可能存在微妙但致命的差异。

歧义域名攻击利用了DKIM组件和DNS组件对特殊字符处理的不一致。例如，NUL字符（\x00）在C语言中会终止字符串，但在Perl或PHP中不会。攻击者可以构造一个DKIM签名，其中s=（选择器）字段包含attack.com\x00.any。DKIM验证组件会查询attack.com\x00.any._domainkey.legitimate.com，而DNS解析器在遇到NUL字符时截断字符串，实际查询的是攻击者控制的attack.com。结果，DKIM验证显示"通过"，但使用的公钥来自攻击者。

sequenceDiagram
    participant 攻击者服务器
    participant 目标邮件服务器
    participant DNS服务器
    participant 攻击者控制的DNS
    
    攻击者服务器->>目标邮件服务器: 发送伪造邮件<br/>d=legitimate.com<br/>s=attack.com\x00.any
    目标邮件服务器->>目标邮件服务器: 构造DNS查询<br/>attack.com\x00.any._domainkey.legitimate.com
    目标邮件服务器->>DNS服务器: 查询域名
    Note over DNS服务器: NUL字符截断
    DNS服务器->>攻击者控制的DNS: 查询attack.com
    攻击者控制的DNS->>DNS服务器: 返回攻击者公钥
    DNS服务器->>目标邮件服务器: 返回公钥
    目标邮件服务器->>目标邮件服务器: 使用攻击者公钥验证签名
    目标邮件服务器->>目标邮件服务器: DKIM验证通过！

攻击向量二：歧义From头

RFC 5322规定邮件只能有一个From头，但论文发现测试的系统中，19个实现中有19个不遵循这一规范。攻击者可以构造包含多个From头的邮件：邮件服务器验证第一个From头（来自攻击者控制的域名），而邮件客户端显示第二个From头（来自受害域名）。

空格处理的不一致同样危险。RFC明确规定某些空格用法是非法的，但测试的系统中没有一个是完全符合规范的。攻击者可以利用空格的歧义解释，使邮件服务器和客户端解析出不同的发件人地址。

攻击向量三：SMTP走私攻击

2023年12月，SEC Consult的研究人员披露了一种新型攻击：SMTP走私（SMTP Smuggling）。这种攻击利用了不同邮件服务器对SMTP协议中"数据结束标记"解释的差异。

SMTP协议规定，邮件正文的结束标记是<CR><LF>.<CR><LF>（回车换行、点、回车换行）。但研究发现，某些邮件服务器接受非标准的结束标记，例如<LF>.<LF>或<CR>.<CR>。

攻击者可以利用这种差异"走私"额外的SMTP命令。例如，攻击者发送一封邮件，正文中包含非标准的结束标记。某些出站服务器（如Microsoft Exchange Online）会将非标准标记后的内容作为新邮件处理，而入站服务器（如某些Cisco设备）则会将其作为原始邮件的一部分。这允许攻击者完全绕过SPF、DKIM和DMARC验证。

根据研究，当时约40,000个使用Cisco Secure Email Cloud Gateway的域名默认配置下易受此攻击。Cisco的回应出人意料：这"不是漏洞，而是功能"。

邮件转发的结构性困境

即使所有协议都正确部署，邮件转发和邮件列表仍然是一个棘手的问题。当邮件被转发时：

  1. SPF验证会失败：转发服务器的IP不在原始域名的SPF记录中
  2. DKIM签名可能失效：如果转发服务器修改了邮件内容（如添加页脚），签名将不再匹配
  3. DMARC因此失败：因为前两者都失败

为了解决这个问题，2016年，Authenticated Received Chain（ARC）协议被提出。ARC的核心思想是在邮件转发过程中保留原始验证结果。每个转发服务器都会添加一个ARC签名，记录邮件在上游的验证状态。接收方可以查看整个转发链，判断邮件在源头是否合法。

ARC的工作方式是：每个转发服务器添加三类信息：

  • ARC-Authentication-Results：记录上游验证结果
  • ARC-Message-Signature：对邮件内容的签名
  • ARC-Seal：对整个ARC链的签名
sequenceDiagram
    participant 发送方
    participant 转发服务器A
    participant 转发服务器B
    participant 接收方
    
    发送方->>转发服务器A: 原始邮件<br/>SPF/DKIM通过
    转发服务器A->>转发服务器A: 验证原始邮件
    转发服务器A->>转发服务器A: 添加ARC-Seal-1<br/>记录验证结果
    转发服务器A->>转发服务器B: 转发邮件+ARC链
    Note over 转发服务器B: SPF失败（转发IP）<br/>但ARC链有效
    转发服务器B->>转发服务器B: 验证ARC链
    转发服务器B->>转发服务器B: 添加ARC-Seal-2
    转发服务器B->>接收方: 转发邮件+完整ARC链
    接收方->>接收方: 验证ARC链有效性
    接收方->>接收方: 根据ARC判断原始邮件合法

然而，ARC的部署仍然有限，且其安全性取决于"第一个转发服务器是否可信"——如果攻击者控制了第一个转发节点，整个信任链就会崩溃。

传输层安全：被忽视的一环

除了身份验证，邮件传输过程的加密同样重要。SMTP最初设计时没有任何加密机制——邮件以明文形式在网络中传输，任何中间节点都可以读取内容。

2002年，RFC 3207定义了STARTTLS扩展，允许SMTP连接升级为TLS加密。但STARTTLS存在一个根本性问题：它是机会性加密（Opportunistic Encryption）。服务器可以声明支持STARTTLS，但客户端并不验证服务器证书的有效性——这为中间人攻击留下了空间。

MTA-STS（Mail Transfer Agent Strict Transport Security）试图解决这个问题。它允许域名所有者声明：所有发送到该域名的邮件必须使用有效的TLS连接。MTA-STS策略通过HTTPS发布，避免了DNS欺骗的风险。

TLS-RPT（TLS Reporting）则提供了报告机制，让域名所有者了解其域名的TLS连接情况，包括失败原因和安全问题。

合规压力：从自愿到强制

长期以来，邮件认证协议的部署主要依赖自愿采用。但近年来，监管机构开始将其纳入合规要求。

PCI DSS 4.0（支付卡行业数据安全标准）于2025年3月31日生效，明确要求处理支付卡数据的组织必须为其所有发送域名部署DMARC。这是第一个将DMARC作为强制要求的全球性安全标准。

对于金融机构而言，这一要求的逻辑是清晰的：钓鱼邮件是数据泄露的主要入口之一，而有效的DMARC部署可以显著降低域名被伪造的风险。但合规只是第一步——PCI DSS要求的是"部署"，而不是"正确配置"。根据Validity的研究，约16%的域名尝试了DMARC实施，但其中很大一部分停留在p=none阶段，这实际上提供了零保护。

部署的隐性成本

为什么DMARC的部署率如此之低？一个关键原因是实施的隐性复杂性。

一个看似简单的DMARC部署实际上涉及：

  1. 梳理所有邮件发送源：企业可能使用数十个第三方服务发送邮件（营销平台、客户支持系统、HR系统等），每个都需要被正确配置
  2. SPF记录的DNS查询限制：SPF记录的DNS查询次数限制为10次，超过这个限制会导致验证失败。对于使用多个第三方服务的企业，这可能成为严重问题
  3. DKIM密钥轮换：密钥需要定期更换，但这个过程如果操作不当可能导致合法邮件被拒绝
  4. 监控和报告分析：DMARC报告可能非常庞大，需要专业工具进行分析

一个被忽视的问题是DNS记录的复杂性爆炸。一个使用5个第三方邮件服务的企业，其DNS记录可能包含：

; SPF记录（已接近查询限制）
example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com include:salesforce.com include:zendesk.com ~all"

; DKIM选择器（每个服务可能需要多个）
selector1._domainkey.example.com. IN CNAME selector1._domainkey.google.com.
sendgrid._domainkey.example.com. IN CNAME sendgrid._domainkey.sendgrid.net.
k1._domainkey.example.com. IN CNAME dkim.mcsv.net.
...

; DMARC记录
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

; BIMI记录（可选）
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg"

任何一条记录配置错误都可能导致合法邮件被拒绝——这就是为什么许多组织停留在p=none策略的原因。

展望：信任模型的重新设计

四十年的邮件安全演进揭示了一个核心问题：SMTP的信任模型建立在错误的假设之上。所有的补丁（SPF、DKIM、DMARC、ARC）都在尝试在协议层面添加身份验证，但它们都无法改变SMTP本质上是一个"信任所有发送者"的协议这一事实。

2020年代出现的一些新方案试图从不同角度解决问题：

**BIMI（Brand Indicators for Message Identification）**允许域名所有者在邮件客户端显示经过验证的品牌Logo。这增加了一个视觉信任层，帮助用户识别合法邮件。但BIMI要求域名必须已经部署了p=quarantine或p=reject级别的DMARC策略，这实际上是一种激励机制。

**DNSSEC（DNS Security Extensions）**为DNS查询提供了真实性验证，可以防止DNS欺骗攻击。但截至2024年，DNSSEC的全球部署率仍然有限，且其复杂性使其难以被广泛采用。

端到端加密（如PGP、S/MIME）提供了更强的安全保证，但密钥管理的复杂性使其无法成为大众化的解决方案。

邮件安全的未来可能需要更根本的改变：重新设计信任模型。一种可能的方向是将身份验证从协议层面移到应用层面——用户不再信任"邮件声称来自谁"，而是信任"谁签发了这封邮件的凭证"。但这需要对现有邮件系统进行根本性的重构，其成本和复杂性可能是当前互联网生态无法承受的。

在可见的未来，我们能做的仍然是多层防御：正确配置SPF、DKIM、DMARC、ARC、MTA-STS；持续监控DMARC报告；对员工进行安全培训；部署邮件网关进行内容分析。这不是完美的解决方案，但它是当前现实条件下最务实的做法。

正如计算机安全领域的一条铁律所言：安全不是一种状态，而是一个过程。在SMTP协议的信任模型被根本性重构之前，这个过程将持续下去——攻击者不断发现新的绕过方法，防御者不断修补漏洞，这场四十年的博弈还将继续。

参考文献

  1. Postel, J. (1982). RFC 821: Simple Mail Transfer Protocol. IETF.
  2. Kitterman, S. (2014). RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email. IETF.
  3. Crocker, D., Hansen, T., & Kucherawy, M. (2011). RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. IETF.
  4. Kucherawy, M., & Zwicky, E. (2015). RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). IETF.
  5. Chen, J., Paxson, V., & Jiang, J. (2020). Composition Kills: A Case Study of Email Sender Authentication. USENIX Security Symposium.
  6. SEC Consult. (2023). SMTP Smuggling - Spoofing E-Mails Worldwide. SEC Consult Blog.
  7. Validity. (2025). DMARC Adoption: A Deep Dive into the Current State of Email Authentication.
  8. FBI. (2024). Internet Crime Report 2024. IC3.
  9. DmarcDkim.com. (2025). DMARC Adoption Statistics - Live Global Data.
  10. Payment Card Industry Security Standards Council. (2022). PCI DSS v4.0.