详解电子邮件安全：从SMTP到PGP再到DNSSEC的加固

电子邮件安全

系统架构

电子邮件系统是一个由多个独立但协同分布的组件构成的分布式系统，主要有三个组件：

• 邮件用户代理MUA：比如QQ邮箱网页版，gmail网页版，Outlook客户端等
• 邮件传输代理MTA ：起到中转站的作用
  • 核心工作：接收客户端提交的邮件；验证发件人是否有权发送（如验证账号密码），负责将邮件转发给收件方的服务器
  • 协议：SMTP，简单邮件传输协议，用于发送邮件
• 邮件投递代理MDA ：邮件传递链条的最后一个环节，当收件人域的MTA收到邮件后，会将这封邮件交给MDA处理
  • 核心工作：解析邮件的最终收件人地址，并将其准确地放入该用户在服务器上的个人收件箱
  • 协议：POP3，IMAP，用于接收邮件

一封电子邮件从发送到接收的完整过程：

发件人MUA -ESTMP-> 发件服务器MSA -DNS,SMTP-> 中转站MTA -SMTP-...-SMTP-> 中转站MTA -SMTP-> 邮件投递代理MDA -ESTMP-> 收件服务器 -POP/IMAP->收件人MUA 

我们思考一个问题：在这样一个架构下，TLS还能保证邮件传输的安全了吗？

不能，TLS保护的仅仅是一方到另一方的传输安全；也就是说邮件被发送到MTA时，MTA是可以看见邮件内容的，若MTA被黑客攻破了，那么邮件就会泄露

核心协议

• 用于发送邮件：SMTP
• 用于接收邮件：POP，IMAP
• 可传输多种类型数据：MIME

简单邮件传输协议SMTP

• 负责：将电子邮件从发送端传输到接收端的邮件服务器，但不提供安全性
• 报文格式：分为以下3部分：
  • 信封：主要是传输层指令，给邮件服务器/MTA看的
    • MAIL FROM：发件人，作用是指定退信地址而不是身份认证标识
    • RCPT TO：指明邮件的实际投递目标
  • 首部：给MUA看的
    • From：显示的发件人，比如sunxiaochuan@company.com
    • To:显示的收件人
    • Date：日期
    • Subject：邮件主题
  • 主体：邮件的正文与附件
• 工作原理： 采用C-S模式，客户端向服务器发送邮件请求，服务器根据请求将邮件发送到目标邮件服务器，整个过程可分为以下步骤：
  • 建立连接：客户端和邮件服务器建立TCP/IP连接
  • 邮件发送请求：客户端通过HELO命令或EHLO命令向服务器发送问候，表示服务已建立
  • 邮件传输：客户端使用MAIL FROM，RCPT TO 和 DATA等命令告诉服务器邮件的发件人、收件人和内容
  • 传输结束：客户端发送QUIT命令结束邮件发送会话，服务器关闭连接
• 工作端口：默认端口为25或587

由于SMTP并不提供安全性，所以实际应用中需要配合SSL/TLS加密来保证邮件传输的安全性

邮局协议POP

POP是一个简单但是功能有限的邮件读取协议，现在使用的是POP3

• 作用 ：允许MUA连接到邮件服务器，把邮箱中的 所有新邮件 下载到本地设备
• 工作模式：可以类比取快递或者现实中的邮局，默认情况下，在邮件服务器上把新邮件下载到本地后，新邮件就会在服务器上被删除，这使得它不适合在多个设备上管理邮件
• 常用端口
  • 未加密的POP3：110
  • 加密的POP3S：995

互联网邮件访问协议IMAP

• 作用：IMAP负责从邮件服务器接收电子邮件，并在用户邮件客户端与服务器之间同步邮件状态

• 工作模式：IMAP把邮件的主副本都存储在邮件服务器上，并在所有连接的设备上同步状态，比如在一个设备上标记邮件已读/删除邮件，在其他设备上都会显示已读/邮件被删除

• 常用端口：

  • 未加密的IMAP：143
  • 加密的IMAPS：993

• 工作原理： 使用C-S模式，客户端通过IMAP服务器访问和管理存储在邮件服务器上的邮件，可分为以下几个步骤：

  • 连接建立：邮件客户端与IMAP服务器建立TCP/IP连接，连接在143/993端口上
  • 用户身份认证：客户端提供用户名和密码向服务器验证身份
  • 邮件同步：客户端从服务器下载邮件头信息，用户可以选择查看、下载或删除特定邮件
  • 状态更新：IMAP服务器实时更新邮件的状态（已读、未读、标记等），并将更新同步到所有客户端设备

与POP3的对比：

• 优点：
  • 适合现代多设备用户，可状态跨设备同步
• 缺点：
  • 占用较多服务器存储空间

辅助邮件转发的关键角色

• DNS服务器（域名系统）
  • 角色：邮件的导航仪
  • 核心工作：通过 "MX记录"（邮件交换记录，DNS中的一种资源记录类型，用于指定负责接收发往该域名电子邮件的邮件服务器），查询收件人域名对应的"收件服务器IP地址"
  • 例子：要给xxx@qq.com发邮件，此时发件服务器MSA就会查询DNS，知道了xxx@qq.com对应的邮件服务器IP为114.51.4.x,让MSA知道往哪里转发
• 中继服务器（邮件网关）
  • 角色：邮件的长途运输站
  • 核心工作：在发件服务器和收件服务器之间进行转发，同时进行初步过滤，过滤掉明显的垃圾邮件
  • 风险：若中继服务器不安全，邮件可能被拦截、泄露

邮件发送的详细过程

以Alice（alice@comany.com）向Bob（bob@114.com）发送邮件，接收协议为IMAP为例

• MUA编辑与提交 ：Alice在Outlook等邮件客户端编写邮件，填写收件人为bob@114.com，随即发送，MUA会生成包含From/To/Subject头字段的符合RFC 5322的邮件格式
• SMTP会话建立 ：Outlook连接企业MTA的25端口建立SMTP连接，发送EHLO company.com命令，MTA返回支持的扩展能力
• 身份认证与加密协商 ：MUA发送账号密码哈希（AUTH CRAM-MD5认证），通过后发送STRARTTLS命令建立TLS连接
• MX记录查询 ：企业MTA向本地DNS发送MX查询请求，返回114.com的MX列表（如mx1.114.com，preference=10）
• 跨域MTA连接 ：企业MTA连接到mx1.114.com的TCP 25端口，完成AUTH/STARTTLS握手，发送MAIL FROM <alice@comany.com>指明发件人和退信地址是 alice@comany.com
• 邮件网关过滤 ：114.com的邮件网关会对邮件的内容进行沙箱检测，确定附件无恶意后转发至114.com的核心MTA上
• MDA存储与状态标记：核心MTA会将邮件传递到MDA，MDA解析邮件头并存储至Bob的邮箱目录，标记状态为未读
• MUA同步与访问 ：Bob的手机邮箱APP通过IMAPs（TCP 993）连接114.com的MDA，发送SELECT INBOX命令选中收件箱，通过FETCH命令同步邮件内容

电子邮件的存储转发机制

可以形象的理解成接力赛，只不过接力棒需要先自己保存一份发出去

电子邮件的存储转发机制是一种异步的、接力式的消息传递模型，消息是像包裹一样被逐站传递

• 存储Store：
  • MTA完整接收邮件->将邮件保存到本地硬盘->承担全部责任->向上游节点回复OK
• 转发Forward：
  • 查找下一站地址（MX记录）->尝试与下一站建立连接->发送邮件副本->等待下游节点回复OK

SMTP over SSL的不足与风险

• SSL/TLS模型
  • 是一个点到点的管道模型，也就是说数据一旦离开管道（到达服务器），那么就是明文
• 电子邮件传输模型
  • 电子邮件会在经过的每一个MTA中停留，存储，排队，在这个过程中，邮件是以明文形式存储在服务器硬盘上的

一个直观的例子就是：

• 单纯的SMTP，邮件无论是传输和存储都是裸奔的，相当于送报员骑着自行车送邮件，黑客可以直接打劫送报员就能获取到明文邮件
• SMTP Over SSL就可以理解成，把送报员的自行车换成装甲车，装甲车里装的是明文邮件，虽然避免了黑客直接打劫送报员获取明文邮件，但是当邮件送到邮局（MTA）等待存储时，仍是明文；黑客可以通过打劫邮局来得到明文邮件

所以需要给邮件本身进行上锁（类比成每一封邮件都放在一个特制的保险箱中），而不仅仅是对邮件传输的载体上锁

核心风险一：身份伪造，SMTP协议的"身份剥离"缺陷

• 威胁场景
  • 攻击者搭建恶意MTA或者控制一台开放的MTA，与目标MTA建立连接
  • 发送MAIL FROM <伪造的发件人（比如老板，导师...）>伪造发件人，RCPT TO <受害人（比如员工，学生...）>指定收件人
  • 发送DATA命令提交文件内容，邮件首部的From字段为伪造的发件人
  • 目标MTA接收邮件后，因为没有身份认证机制，会直接发送到受害人的MDA
• 潜在风险
  • SMTP协议的MAIL FROM字段只是起到指定退信地址的作用，而非身份认证标识；协议未强制要求该字段与实际发件人一致，且未绑定数字签名等身份验证机制。攻击者可通过篡改MAIL FROM字段（甚至伪造From邮件头）实现"发件人伪装"

核心风险二：数据窃听，传输链路的"明文暴露"风险

• 威胁场景
  • 攻击者通过ARP欺骗劫持目标终端与网关的通信，嗅探SMTP/POP3/IMAP等协议的通信
  • 通过邮件头关键字（如From/To/Subject）过滤流量，直接提取邮件正文与附件内容（如Base64编码的附件可直接解码）
• 潜在风险
  • 早期SMTP/POP3/IMAP均为明文协议，未定义加密字段，邮件内容（含附件）以ASCII码明文传输

核心风险三：数据篡改，缺乏端到端完整性校验

• 威胁场景
  • Alice向Bob发送包含转账的合同，但攻击者控制了AB通信之间的MTA，实施以下篡改：
    • 拦截Alice的明文邮件，或者在TLS链路结束后获取明文邮件
    • 修改金额和转账账户
    • 重新生成邮件头
    • 重新生成邮件首部，转发至Bob的MTA
  • 导致Bob按照错误信息转账，造成巨大损失
• 潜在风险
  • TLS的防御范围无法延伸至整个邮件传输链

核心风险四：恶意附件/链接

邮件能成为恶意代码传播的"重灾区"，核心源于其载体优势与攻击触发机制的结合：

• 载体优势：邮件附件支持EXE、XLSX、PDF、ZIP等多种文件格式，可轻松绕过传统防火墙对特定端口的限制，相当于为恶意代码打开了"合法通道"；
• 触发机制：攻击者利用收件人"信任发件人"的心理（比如伪装成同事、客户或官方机构），通过社会工程学话术诱导点击，大幅降低攻击门槛，这也是其区别于其他网络攻击的核心特点
• 技术支撑：恶意文件往往捆绑系统或软件漏洞（如Office宏漏洞CVE-2023-23397，PDF阅读器漏洞CVE-2024-27357），实现"点击即执行"甚至"无交互执行"，进一步提升攻击成功率

端到端的邮件加密协议

安全目标

• 机密性
  • 邮件正文、附件仅收发双方可以解密，中间节点无明文权限
• 完整性
  • 防止邮件内容/附件被篡改
• 身份认证
  • 验证发件人真实身份，阻断伪造发件人的钓鱼攻击
• 不可否认性
  • 发件方不能否认自己已经发送的邮件

通用场景

• 中转与存储：
  • 密文邮件经过多MTA分段传输，在服务器存储
  • 所有中间节点仅处理密文，无法解密

PGP

PGP（Pretty Good Privacy） 是一种端到端的邮件加密协议，PGP及其开放标准实现OpenPGP采用了一种名为信任网络（WoT）的 去中心化信任模型

在WoT模型中，用户通过互相为对方的公钥签名来建立信任，比如：

• Alice不直接认识Bob，但是非常信任Carol，并且已经认证并签署了Carol的公钥；如果Carol验证了Bob的身份并签署了它的公钥，那么当Alice的PGP客户端看到Bob的公钥上带有Carol的有效签名时，它可以根据预设的信任级别，自动地对Bob的公钥赋予一定程度的信任。信任的程度取决于Alice在她的PGP配置中给予Carol作为"介绍人"的信任权重；思想：朋友的朋友会比陌生人更可信一些

优点：形成了一个分布式的、容错的信任模型，避免了对单一权威机构的依赖，防止单点故障

提供的服务

1. 认证：使用散列函数（SHA）和公钥签名算法（DSS/RSA）提供数字签名服务

   1. 使用SHA算法计算消息的散列值，将此消息摘要使用发送方私钥签名后，连带着原消息一起发送

   

2. 保密：发送方生成一个随机数作为一次性会话密钥，然后用此会话密钥按分组对称加密算法加密原消息，然后使用接收方公钥加密会话密钥，与密文一起发给接收方

   

   保密和认证可以同时应用于一个消息
   

3. 压缩：作为默认处理 ，PGP在 应用签名之后、加密之前 对消息进行ZIP压缩

   1. 优势：压缩后的消息比明文更短，节省网络传输时间和存储时间
   2. 签名后压缩：
      1. 不同的压缩算法版本可能导致二进制数据有细微差别，如果对压缩后的数据签名，如果发方和收方压缩算法版本不同就会造成签名校验失败
   3. 压缩后加密：
      1. 压缩后的消息冗余度更小，密码分析的难度更大

4. 电子邮件兼容性：PGP加密会产生任意的8bit二进制流，但是许多邮件系统仅允许使用ascii文本组成的数据块通过

   1. 使用Radix-64将二进制流转换成人类可读的ascii字符
   2. Radix-64：可以理解成加上CRC校验的Base64编码，3个8bit编为一组，映射为4个ascii码字符

5. 分段和组装

   1. 电子邮件工具通常限制消息的最大长度
   2. PGP自动将长消息分段使之可以通过电子邮件发送， 分段操作在其他所有操作（包括Radix-64）之后才进行

PGP密钥系统

使用4种类型的密钥：

• 一次性会话传统密钥
• 公钥
• 私钥
• 基于口令短语的传统密钥

其中，一次性会话密钥是 不可预测的 ，PGP允许一个用户拥有多个公私钥对；另外，每个PGP实体都必须管理 一个自己的公私钥的文件和一个其他用户的公钥的文件

密钥标识

一个用户拥有多对公私钥，接收者怎么知道发送者使用哪个公钥来加密会话密钥呢？

• 如果将公钥和消息一起发送，消息太长，性能开销过大
• 需要给每个公钥分配一个唯一的标识符，传输时将标识符与消息一起传送

密钥标识符KeyID：

• 对于每个用户，每个公钥需要与唯一的KeyID相关联
• 发送方必须容易了解一个公钥在其所有者上分配的KeyID
• PGP采用公钥的低64位作为KeyID
• 数字签名也需要使用KeyID，因为接收方需要确定使用发送方的哪个公钥来验证签名

PGP消息格式

• 会话密钥
  • 公钥标识符KeyID
  • 用接收方公钥加密的会话密钥
• 签名
  • 时间戳
  • 公钥标识符KeyID
  • 消息摘要
• 报文
  • 文件
  • 时间戳
  • 数据

密钥环

密钥环其实是一个保存密钥的列表，每一表项保存一个用户密钥

PGP为每个节点提供了一对数据结构：

• 私钥环：用于存放本节点自身的公私钥对
• 公钥环：用于存放本节点知道的其他用户的公钥

私钥的安全存储

私钥环表项字段解析：

• 时间戳：密钥对生成的时间
• 密钥标识：至少64位的公钥标识符
• 公钥
• 私钥：此域需要被加密！
• 用户标识：通常使用用户的电子邮件地址

私钥域之所以需要被加密，是因为私钥是PGP安全体系的根信任凭证，承担着两大核心功能：

• 唯一解密凭证 ：只有私钥才可以解密发送方发送的密文（包含签名、密文、会话密钥）
• 唯一签名凭证： 只有私钥才可以对消息摘要生成可验证的签名

私钥存储需要做到：防窃取、防丢失、可控使用

• 私钥丢失：加密数据永不可解密
• 私钥被盗：数字身份被盗，攻击者可以生成恶意的签名

私钥是超长随机数，怎么存放？

核心设计逻辑：多层防御+最小权限暴露，在可存储和高安全之间建立平衡

私钥存储的多层防御

第一层：基于口令的对称加密（核心防御）

• 私钥加密过程：私钥并不以明文形式存储在私钥环中，而是加密后存储，步骤如下
  • 用户产生保护密码的口令
    • 鼓励用户使用一个更长、更复杂的短语作为保护密码口令，以极大提高抗暴力破解的能力
  • 使用密钥派生函数，派生出对称加密密钥
    • 先对保护密码口令进行散列值计算以将其映射为更长的密钥，随后丢弃口令明文 ，并派生出一个临时的、高强度的对称加密密钥
  • 使用对称加密密钥以及算法加密私钥，并丢弃对称密钥
  • 将加密后的私钥存于私钥环

把口令和对称密钥全都扔了，那用户怎么从私钥环上拿到私钥呢？？

当用户需要使用私钥时，PGP客户端会执行一个与存储过程相反的、安全可控的取用过程

核心原则：真正的私钥尽可能少地以明文形式存在，并且**只在内存中短暂停留，**绝不会以解密状态被写回硬盘

• Step 1：用户操作触发，比如用户需要解密发送方发来的密文，需要对消息摘要进行签名，需要管理密钥等
• Step 2：根据PGP消息中给出的公钥标识符找到对应的私钥环的表项
• Step 3：请求保护密码，这一步是用户可感知的（需要用户手动输入）
• Step 4：按照存储中相同的步骤派生出临时的对称密钥
• Step 5：在内存中解密私钥
• Step 6：执行操作
• Step 7：从内存中清除私钥

优点：只有需要时，私钥明文才会浮出水面，并且停留的时间窗口被缩到最短

第二层：操作系统级别的访问控制隔离

利用操作系统的文件权限控制，对存储私钥环的目录进行访问权限控制，比如在Linux下设置为700，只有自己有读写执行权限

第三层：内存级别的临时保护

明文私钥仅仅在使用瞬间存在内存之中，并且通过技术手段防止内存数据被窃取

公钥环

表项字段：

• 时间戳：表项生成时间
• 密钥标识
• 公钥
• 用户标识

S/MIME

是PGP在企业环境中的主要替代方案

S/MIME构建在一个严格的、等级化的信任模型之上，这个模型的核心是公钥基础设施PKI，信任的根基在于少数证书认证机构

与PGP对比：

电子邮件安全协议

欺诈邮件

成因

SMTP协议的首部FROM字段和MAIL FROM字段，SMTP协议不会验证FROM字段与发送者的关系，导致了任何人都可以手动填写任意FROM地址

• FROM：相当于信纸上的地址，给最终收件人看的，代表了信件内容的官方身份
• MAIL FROM：相当于信封上的地址，给MTA看的，如果邮件无法投递就会按照这个地址退回邮件

攻击者流程

1. 伪造发件人地址，将FROM字段改成一个可信的发件人
2. 用窃取的私钥对邮件内容做PGP或者S/MIME签名，嵌入邮件
3. 发送到自己控制的邮件服务器MTA，通过SMTP协议将邮件发送给接收方的MTA

核心矛盾与身份认证断层

• SMTP协议设计缺陷：原始SMTP协议（1982）未内置发件人身份认证，任何人都可以声称自己来自任意地址
• PGP | S/MIME的验证边界：
  • 仅验证邮件内容与签名的关系，不关心邮件从何发出，无法验证私钥持有者是否有权使用发件人域名

解决思路：从验证邮件发送路径的角度入手，验证发件人MTA的IP

发件人策略框架SPF

核心思想：允许域名所有者在其DNS中发布一条TXT记录，明确列出授权允许代表该域名发送邮件的服务器IP，收件方服务器通过查询DNS中的SPF记录，验证邮件是否来自授权IP

university.com. 3600 IN TXT "v=spf1 ip4:192.168.1.100 ip4:10.0.0.0/24 include:mail.qq.com -all"

只有ip为192.168.1.100和10.0.0.0/24网段的服务器才可以使用university.com这个域名发送邮件，其他的一律拒绝（-all表示全部拒绝）

SPF能与PGP | S/MIME形成互补：前者对邮件路径进行验证，后者对内容和签名（身份）进行验证

执行步骤

• Step 1：MTA接收邮件，并从MAIL FROM字段中提取发送方域名与IP
• Step 2：MTA解析域名，作为查询SPF记录的基础
• Step 3：MTA向DNS查询SPF并获取合法IP
• Step 4：MTA会将Step1中的发送方实际IP与TXT记录中的合法IP进行匹配
• Step 5：MTA在邮件头部添加SPF验证结果，供后续处理

缺陷

SPF仅能证明目标域名授权的MTA合法，但是不能确定操控MTA的人合不合法，发送方服务器合法是发件人身份合法的必要不充分条件

这样一来就有2个场景：

• 授权的MTA被劫持：MTA合法，邮件伪造
  • 攻击者劫持了一台域名授权的MTA，使用它发送伪造邮件
  • SPF验证：MTA在TXT记录内，SPF验证通过
• 授权MTA上的用户伪造发件人：MTA合法，用户越权
  • 公司员工使用Gamil账号发送邮件，但是MAIL FROM字段填写的是ceo@company.com
  • 收件服务器SPF验证：发件服务器是Gmail的MTA，IP在TXT记录内，SPF通过
  • 但是员工并不是company.com的合法发件人

域名密钥识别邮件DKIM

上面SPF的缺陷主要是因为发件人域名与邮件之间没有绑定关系

DKIM通过密码学技术为邮件提供来源真实性和内容完整性保证；借鉴了PGP | S/MIME的数字签名思想，做了域级化适配（即将签名主体从单个用户升级为整个域名）

核心逻辑：

• 发件方域名所有者生成公私钥对，私钥用于对邮件内容签名，公钥发布在发送域的DNS TXT记录中
• 收件方MTA通过查询DNS获取公钥，验证签名是否有效；若签名有效，则证明消息未被篡改且确实来自域名的合法拥有者

DKIM公钥

字段与含义：

• v=DKIM1：指定DKIM版本
• k=rsa：指定密钥类型
• p=xxx：公钥的内容
• s=email：密钥用途，仅用于邮件签名
• t=s：严格模式，仅允许与From域名一致的签名

DKIM签名生成

• 发件人撰写邮件，提交给发件MTA
• 发件MTA提取邮件中的关键字段（From，Subject，Body等），计算这些字段的哈希值
• 然后发件MTA使用存储的example.com私钥来对字段哈希值签名
• 发件MTA构造DKIM-Signature嵌入邮件头
  • v=1:DKIM版本
  • a=rsa-sha256：签名与消息摘要算法
  • d=example.com：发件人域名（签名对应的域名）
  • s=selector1：选择器（用于查询公钥）
  • h=From:Subject:Body：覆盖的字段
  • bh=xxx：邮件正文的哈希值
  • b=xxx：用私钥签名后的数字签名
• 带DKIM前面的邮件通过SMTP协议发送给收件方的MTA

验证DKIM签名

收件MTA接收邮件后，启动验证流程：

• 检查邮件头是否含有DKIM-Signature字段，从中提取签名、选择器、签名对应域名
• 构造DNS请求，获取example.com的DKIM公钥
• 提取邮件的关键字段计算哈希值
• 使用DKIM公钥解密签名值，对比哈希值是否一致

优势

• 内容与身份强绑定：签名不仅需要域名持有者的私钥，同时还需要邮件内容核心字段，即使发送IP是授权的，一旦邮件内容被篡改，签名验证也会失败，防御了MTA合法，邮件伪造这一情景下的攻击
• 支持邮件转发场景：签名与域名持有者私钥以及邮件内容本身有关系，在不篡改邮件内容的前提下，IP变更不会导致签名验证失败
• 防御内部风险与服务器失陷：只要没有DKIM私钥，就无法得到DKIM签名，收方MTA会因为验证签名失败而拦截攻击邮件
• 具有不可抵赖性：DKIM 签名由发件方域名的私钥生成，私钥仅域名所有者持有，签名行为具备不可否认性 -若邮件 DKIM 验证通过，发件方无法否认发送过该邮件

DMARC

基于域的消息验证、报告和一致性DMARC

是将SPF和DKIM整合在一起的策略和报告层

域名所有者通过发布一条DMARC记录（一条DNS TXT记录），向收件方服务器声明其策略：对于那些未通过SPF或者DKIM验证的邮件，应该怎么处理

DMARC配置参数

DMARC的参数通过DNS的TXT记录来定义，这些参数决定了哪些未通过SPF或DKIM验证的邮件会被接收方如何处理，以及接收方如何向发送方发送反馈报告

• 策略参数：
  • Policy§
    • none：监控模式，接收方正常放行邮件，仅发送报告
    • quarantine：隔离模式，接收方将未通过验证的邮件放在垃圾邮件文件夹
    • reject：拒绝模式，接收方直接拒绝接收未通过的邮件
  • sp：子域名策略，默认情况下继承p的策略，如果设置了sp则使用sp的策略
  • pct：策略应用的百分比，范围1-100
    • 场景，刚从none切换至reject时，可以设置p=reject,pct=10 即只有10%的报文会被直接拒收，其他的降级隔离或者放行
• 报告机制参数：
  • rua：接收聚合报告的地址
  • ruf：接收失败报告的地址
  • fo：什么时候可以发送ruf报告
    • 0：spf和dkim都失败时发送（默认）
    • 1：任一失败就发送
    • d：仅dkim失败
    • s：仅spf失败
• 验证参数
  • aspf：spf对齐模式
    • r：宽松模式（默认）：主域名匹配就能通过，比如Mail From 是 mail.news.example.com，Header From 是 example.com，算通过
    • s：严格模式：必须完全匹配
  • adkim：dkim对齐模式
    • r：宽松模式（默认）DKIM 签名的 d= 域名与 Header From 的主域名匹配即可
    • s：严格模式
• 基础参数
  • v：DKIM版本，放在TXT记录的第一个位置

DNSSEC与DANE

前言

SPF+DKIM+DMARC都建立在DNS记录可信的基础上，如果DNS本身被篡改了怎么办？

DNS本身是明文传输，无身份验证和完整性校验保护

• 对于SPF：攻击者通过DNS投毒，修改了域名与授权MTA服务器IP之间的关系，将授权服务器IP替换成自己的恶意IP
• 对于DKIM：篡改目标域名的DKIM公钥为自己的公钥，用自己的私钥伪造签名
• 对于DMARC：删除目标域名的DMARC记录，收件方无统一处理策略，即使SPF/DKIM失效，也可能导致邮件被放行

此时我们需要引入DNSSEC和DANE：

引入DNSSEC 和 DANE 的核心原因 ------加固 DNS 安全根基，让前面的所有验证规则都建立在可信的基础上

• DNSSEC：对DNS的安全拓展，为DNS记录增加了数据签名和身份认证机制，解决DNS记录被篡改，来源不可信的问题
• DANE：基于DNSSEC的应用层安全协议，使用基于DNSSEC的安全的DNS记录，将服务身份（比如邮件服务器）与加密证书（比如TLS证书）直接绑定

带DNSSEC的SPF验证步骤

eg：发件人（user@example.com）向收件人(member@abc.com)发送邮件

• Step 1：MTA从邮件的Mail From字段中提取发件人域名
• Step 2：获取该域名的SPF TXT记录以及对应的DNSSEC记录
  • SPF TXT记录
  • RRSIG记录：DNSSEC对TXT记录的签名，包含签名算法、签名有效期、对应的DNSKEY标识
  • DNSKEY记录：目标域名的公钥集合，分为两类：
    • ZSK区域签名密钥：用于签名TXT等业务记录
    • KSK密钥签名密钥：用于签名ZSK公钥，确保ZSK未被篡改
• Step 3：RRSIG签名校验，验证SPF TXT消息是否合法（完整性）
  • 从RRSIG中提取签名算法、签名有效期、DNSKEY标识
  • 根据DNSKEY标识找到用于签名TXT记录的ZSK
  • 对签名值进行解密得到原始TXT的哈希值
  • 使用相同的消息摘要算法计算重新获取的SPF TXT记录的哈希值
  • 将解密得到的原始哈希值与重新计算的哈希值进行一致性比较
• Step 4：DNSSEC信任链校验：验证DNSKEY的合法性
  • 通过分层信任链确认DNSKEY来自域名所有者，而非攻击者伪造：
    • 确认信任锚：MTA本地预置了"根域公钥"作为信任起點（比如.com域的公钥）
    • 查询父域的DS记录
      • MTA查询example.com父域（如.com）的DS记录，DS记录是父域对目标域DNSKEY的哈希值
    • 验证DNSKEY与DS记录匹配
      • 计算当前DNSKEY的哈希值，与DS记录中的哈希值对比，若不一致，则说明DNSKEY被篡改，DNSSEC验证失败
• Step 5：处理DNSSEC验证结果，执行SPF IP匹配