ご質問ありがとうございます。 ご指摘の通り、l=タグがないため本文全体が署名対象です。 ドコモでdkim=passになっているので、本文は署名時から1バイトも書き換えられていません。 ポイントは、本文の「中身」ではなく「解釈のしかた」が変えられている点です。 本文をどう解釈するかは、Content-Typeヘッダ(MIMEの種類と境界文字列)で決まります。 今回はh=From:Fromで、Content-Typeは署名対象外でした。 届いたメールのContent-Typeは multipart/alternative; boundary="no" という不自然な値になっています。 本文は確認できていないので以下は推測ですが、次のような手口と考えられます。 ①攻撃者が楽天カード側の問い合わせフォームなどに、「--no」という境界行やHTMLパート、フィッシングのリンクを含む文字列を入力する ②その入力内容が本文にエコーされた正規メールが、楽天カードの署名付きで攻撃者に届く ③攻撃者はContent-Typeだけを boundary="no" の multipart に差し替えて再送する ④受信側は本文中の「--no」を境界行として解釈するため、楽天カードの元の文面ではなく、攻撃者が仕込んだパートがメールとして表示される 本文は1バイトも変わっていないので署名は有効なまま、表示される内容だけが攻撃者のものになります。 これが、Content-Typeを含むMIMEヘッダを署名対象にすべき理由でもあります。 RFC 6376 Section 5.4の運用上の注記でも、すべてのMIMEヘッダを署名することが強く勧められています。

こちらのドコモ宛てに届いた「楽天カード」を名乗るフィッシングメールのヘッダを分析しました。 SPF・DKIM・DMARCはすべてpass、BIMIのロゴ表示まで付いています。 偽装ではなく、楽天カードの正規の署名付きメールを再送する「DKIMリプレイ攻撃」に、「SPF Bypass」を組み合わせた手口です。 ■経路 ①10/14 21:19、楽天カードが利用しているOKWeb3（okweb3.jp、現在の提供会社はPKSHA Communication社）の送信基盤（楽天カードのSPFで許可済みのIP）から、攻撃者のアドレス宛てに正規メールが送信 ②約18時間後、無関係なサーバーからドコモ宛てに再送 元の宛先と、実際に届いた宛先が違います。 ■なぜDMARCがpassするのか DKIM署名は、本文と署名対象のヘッダが改変されていなければ、誰が再送しても有効です。 署名ドメインはFromと同じmail.rakuten-card.co.jpなので、DMARCもpassします。 p=rejectでも、リプレイは防げません。 SPFもpassしていますが、これはエンベロープ送信者を空にし、HELOに使った攻撃者自身のドメインで判定させたものです（いわゆるSPF Bypass）。 Fromとはアラインしないため、p=rejectのドメインならこれだけでは届きません。 DMARCを通したのはDKIMリプレイです。 ■被害を広げた原因：署名対象がFromだけ DKIM-Signatureは h=From:From でした。 署名されているのはFromだけで、Subject・To・Content-Typeは署名対象外です。 攻撃者は件名を「楽天カード登録情報の更新について」に差し替え、MIME境界（boundary）も書き換えています。 RFC 6376 Section 5.4はFromの署名をMUSTとしていますが、それ以外は必須ではないため、仕様違反ではありません。 しかし、Fromだけの署名では、再送時に改変できる範囲が最大になります。 このDKIM署名は、楽天カードの鍵を使ってOKWeb3の送信基盤で付与されています。 署名範囲を決めているのは送信基盤側なので、まず送信基盤側で是正すべき問題です。 ■もう一つの根本原因 任意の外部アドレス宛てに、正規の署名付きメールが届く経路があったことです。 フォームの自動返信などを本番の送信ドメインで送ると、攻撃者にリプレイの素材を渡すことになります。 ■現状 現在、このDKIMセレクタはDNSに存在しません（全権威サーバーでNXDOMAIN）。 鍵を消せば以後の再送は止まりますが、すでに配送されたメールは、ロゴ付きのまま受信箱に残ります。 ■再発防止策（送信側） 1. DKIMの署名範囲を広げる（送信基盤側の対応） From以外に、Subject・To・Cc・Date・Message-ID・Reply-To・Content-Type・MIME-Versionも署名します。 さらに、存在しないヘッダも含めてオーバーサインし、ヘッダの追加・差し替えを防ぎます。 これは署名を行う送信基盤側、今回はOKWeb3が実装すべき対策です。 送信を外部に委託しているドメイン所有者も、委託先が何に署名しているかを確認する必要があります。 2. 未確認の宛先に送るメールを、本番の送信ドメインから分離する フォームの自動返信や登録確認メールは、本番の通知とは別のサブドメインから送ります。 そのサブドメインにはBIMIを設定しません。 利用者の入力内容を本文にエコーせず、送信数も制限します。 3. DKIM鍵を3か月ごとにローテーションし、リプレイを検知したら即座に失効させる 定期的なローテーションで、古い署名を再送できる期間を最長3か月に抑えます。 M3AAWGのDKIM鍵ローテーションの指針は「少なくとも6か月ごと」なので、3か月ごとはそれより厳しい運用です。 あわせてDMARC集計レポートを監視します。 「DKIMはpassしているのに、自社のSPFに含まれないIPから大量に送信されている」という記録は、リプレイの兆候です。 検知したら、定期の周期を待たずに鍵を失効させて再送を止めます。 4. SPFの許可範囲を最小化し、隠蔽化する クラウドなどの共有基盤を広く許可すると、その基盤の他の利用者からのメールもSPF passになり得ます（BreakSPF）。 許可するのは必要なIPだけにします。 さらにSPFを隠蔽化し、どの送信基盤を使っているかを分かりにくくすることで、利用しているメール配信基盤の脆弱性を探すことを困難にできます。 ■DMARCは実装して終わりではない DMARCは、実装して終わりではありません。 p=rejectにして、BIMIを設定しても、それで終わりではありません。 今回のように、利用しているサービス自体が脆弱であれば、突破されます。 委託先の送信基盤も含めて、DMARCレポートを継続的に監視し、異常を早期に検知して対処し続けることが必要です。