DKIM.

DomainKeys Identified Mail (DKIM) 由 RFC 6376 规定。发送方 Mail Transfer Agent 对选定的邮件头(通过 h= 标签选择,通常包括 From、Subject、Date)和正文计算哈希值,对其签名,并添加 DKIM-Signature: 头,声明签名域名(d=)与选择器(s=)。接收方从 <选择器>._domainkey.<域名>(一条 DNS TXT 记录)获取公钥并验证签名。由于它保护的是内容而非传输路径,DKIM 能在大多数转发中保持有效,并为 DMARC 的对齐提供加密标识。

现实中的失效案例

密钥长度不是可选项。2012 年,研究者 Zachary Harris 发现 Google 使用一把可被分解的 512-bit RSA 密钥签名;他用大约 $75 的云计算成本将其破解,并向 Larry Page 发送了一封"来自" Sergey Brin 的伪造邮件。eBay、Yahoo、Twitter 和 Amazon 也存在同样的弱点,Google 在数天内升级到了 2048-bit。RFC 8463(2018)引入了紧凑高效的 Ed25519-SHA256 算法,但许多邮箱服务商仍只验证 RSA,因此运营方会在不同选择器下同时发布两者。

一种更隐蔽的滥用是 DKIM 重放攻击:由于 DKIM 不携带投递历史,攻击者只要获得一封由高信誉域名有效签名的邮件,就能将其重发给成千上万的受害者,签名依然能通过验证,从而盗用该域名的信誉。防御手段包括对关键邮件头进行过度签名(oversigning)、避免使用正文长度 l= 标签、用 x= 标签设置过期时间,以及定期轮换密钥(参照 M3AAWG 指南)。

flowchart LR
  A[发送方 MTA] -->|对邮件头+正文哈希,<br/>用私钥签名| B[添加 DKIM-Signature 头]
  B --> C[邮件传输中]
  C --> D[接收方 MTA]
  D -->|查询 selector._domainkey TXT| E[(DNS 公钥)]
  E --> D
  D -->|重算哈希,<br/>验证签名| F{有效且未被篡改?}
  F -->|是| G[通过 - 供 DMARC 对齐]
  F -->|否| H[失败 - 由 DMARC 决定]