要約

  • DKIM は d= と s= が示す鍵の下で、選択された正規化済み部分の署名を確かめる。表示中の From ドメインを自動的に認めるものではない。
  • RFC 9989 の DMARC 整合が作者ドメインを別に評価する。整合しても、内容の真実性、安全性、鮮度、業務権限までは証明しない。

pass の持ち主を残す

受信側は攻撃者ドメインの DNS 鍵を取得し、本文ハッシュと署名を正しく検証した。障害は結果からドメイン名を落とし、目立つ From に pass を付け替えたことにある。

d= は署名ドメイン、s= は鍵 selector、h= は署名対象ヘッダー、bh= は正規化した本文のハッシュ、b= は署名値である。From は h= に必須だが、これは後から書き換えられていないことを示すだけだ。攻撃者は他社の From を書いたまま正確に署名できる。

本文ハッシュが合わなければ、ヘッダー側の計算が通っても署名全体は失敗する。結果は正規化、bh=、DNS 鍵、b= に分けて記録すべきだ。

正規化は意味を理解しない

simple と relaxed は空白などの変化を異なる範囲で許す。読者に無害な整形が失敗を招く一方、有害な命令が不変なら成功する。

l= は本文署名を先頭の一定オクテットに限定する。その後ろへ文字を追加しても bh= は変わらず、l=0 では本文全体が未署名になる。画面は未署名の末尾を署名済み本文と同じ表示にしてはならない。

From の権限は整合で問う

2026 年 5 月の RFC 9989 は旧 RFC 7489 を置き換えた。RFC5322.From の Author Domain と、認証された DKIM d= または SPF 識別子を比較する。strict は同一ドメイン、relaxed は同じ Organizational Domain を求める。

冒頭のメールは攻撃者ドメインで DKIM pass、銀行ドメインとの整合は fail になる。DMARC pass であっても、証明するのは Author Domain の利用許可までで、安全なメールという判定ではない。

SMTP envelope、SPF、d=、i=、From、SMTP 認証アカウントは別々である。Authentication-Results は受信管理域が認めた生成者から来た場合だけ使える。ARC も仲介前の判断を運ぶが、その署名者と chain を信頼するかは受信側の方針である。

署名済みメールも再送できる

x= は期限を示せるが、RFC 6376 は再送防止ではないと明記する。本文も署名もそのままのメールを二度処理できるため、支払いや公開には取引 ID、状態、冪等性が要る。

敵対ドメインと偽 From、整合済み悪意本文、l= 後の追記、署名済み・未署名ヘッダー、複数署名、偽の結果ヘッダー、selector 交換、メーリングリスト改変、再送を試験する。各判定は自分の対象だけを答えなければならない。