DKIM.

DomainKeys Identified Mail (DKIM) は RFC 6376 で規定されています。送信側 Mail Transfer Agent は、選択したヘッダ(h= タグで指定、通常は From、Subject、Date)と本文に対してハッシュを計算し、それに署名したうえで、署名ドメイン(d=)とセレクタ(s=)を記載した DKIM-Signature: ヘッダを付加します。受信側は <セレクタ>._domainkey.<ドメイン>(DNS の TXT レコード)から公開鍵を取得し、署名を検証します。DKIM は伝送経路ではなくコンテンツを保護するため、多くの転送を経ても維持され、DMARC が突き合わせる暗号的識別子を提供します。

実際に起きた失敗例

鍵長は妥協できません。2012 年、研究者 Zachary Harris は、Google が素因数分解可能な 512-bit の RSA 鍵で署名していることを発見しました。彼はおよそ $75 分のクラウド計算資源でこれを解読し、Sergey Brin「から」Larry Page 宛てという偽造メールを送りつけました。eBay、Yahoo、Twitter、Amazon も同じ弱点を抱えており、Google は数日以内に 2048-bit へ移行しました。RFC 8463(2018)はコンパクトで高速な Ed25519-SHA256 アルゴリズムを追加しましたが、多くのメールボックス事業者は依然として RSA しか検証しないため、運用者は両方を別々のセレクタで公開します。

より巧妙な悪用が DKIM リプレイ攻撃 です。DKIM は配送履歴を持たないため、高い評価を持つドメインから正当に署名された 1 通のメッセージを攻撃者が入手すると、それを数千の被害者へ再送しても署名は依然として検証を通過し、そのドメインの評価を借用できてしまいます。対策としては、重要なヘッダのオーバーサイニング、本文長 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 が判断]