入力エコー攻撃とは？フォーム入力でDMARC・BIMIを通過するフィッシングの手口と対策

入力エコー攻撃とは？フォーム入力でDMARC・BIMIを通過するフィッシングの手口と対策

SPF・DKIM・DMARCがすべてpassし、BIMIのロゴまで表示されたフィッシングメールの実例から、送信側の対策を読み解く

作成
著者: 竹洞 陽一郎

Webフォームの自動返信や、アカウント登録時の通知メールに、利用者が入力した内容をそのまま載せていませんか。
入力内容をメールの本文にそのまま載せること（本記事では「エコー」と呼びます）は、正規の署名付きメールを、攻撃者が作った文面のフィッシングメールに変えてしまう原因になります。
このエコーを悪用する攻撃を、MailDataでは「入力エコー攻撃」と名付けました。
本記事では、SPF・DKIM・DMARCがすべてpassし、BIMIのロゴまで表示されたフィッシングメールの実例を分析し、同じ原因による他の事例とあわせて、送信側と受信側が取るべき対策を解説します。

問題は仕様ではなく、推奨されている対策を実装していないこと
この事例について、「SPF・DKIM・DMARCという仕様そのものがダメだ」という意見を目にします。
しかし、今回の攻撃を成立させたのは、仕様の欠陥ではなく、推奨されている設定や運用が行われていなかったことです。
フォームの入力内容をエコーしない、主要なヘッダを署名する、受信側でSPFとDKIMの双方のアライメントを求める、受信側でDMARCのpassだけに頼らず多層フィルタで判定する、といった対策のどれか1つでも行われていれば、このメールは届かなかったか、ここまで本物らしくは表示されなかった可能性が高いと考えます。
DKIMの署名がそのまま再送（リプレイ）され得ることは、RFC 6376自体が、セキュリティ上の考慮事項の中で認めている既知の性質です。
（RFC 6376 Section 8.6）
仕様は、その性質を前提に、署名の対象や運用のしかたを推奨しています。
どのようなセキュリティの仕様も、推奨どおりに設定し、運用しなければ、突破されたり、悪用されたりします。

この記事の要点：

1. 入力エコー攻撃（Input Echo Attack）とは？

要点: 入力エコー攻撃は、外部の人が書き込める入力欄の内容を、正規の署名付きメールにそのまま載せる仕組みを悪用し、攻撃者が書いた文面を正規の送信者のメールとして届ける攻撃です。送信元は本物なので、SPF・DKIM・DMARCを正規に通過します。

1.1 エコーとは？

本記事でいう「エコー」とは、Webのフォームなどに入力された内容を、そのままメールの本文に載せて送る処理のことです。
問い合わせフォームの自動返信で「お問い合わせ内容」として入力内容を書き添えるもの、会員登録の確認メールで登録内容を表示するものなどが、典型的なエコーです。
PHPのmail()関数やmb_send_mail()関数で作ったフォーム、WordPressのContact Form 7の自動返信（メール(2)）のようにメールタグで入力内容を本文に差し込む設定、フォーム作成サービスの自動返信など、ごく一般的に使われている処理です。

次は、PHPで作った問い合わせフォームの自動返信の例です。 


$body  = "お問い合わせを受け付けました。\n";
$body .= "■お問い合わせ内容\n";
$body .= $_POST['message'];  // 入力内容をそのまま本文に載せる（エコー）

// 宛先も、フォームに入力されたアドレス
mb_send_mail($_POST['email'], "お問い合わせを受け付けました", $body);

この例では、本文に入力内容がそのまま載るうえに、宛先もフォームに入力されたアドレスです。
つまり、誰でも、好きな文面を、好きな宛先に、このWebサイトのドメインから送らせることができます。
送信するメールサーバーや配信サービスがDKIM署名をしていれば、その文面に正規の署名も付きます。

1.2 エコーを悪用する攻撃

入力エコー攻撃（Input Echo Attack）とは、メールフォームやアカウント登録などに入力された内容を、正規の署名付きメールにそのまま載せて送る仕組み（エコー）を悪用し、攻撃者が書いた文面を、正規の送信者のメールとして届ける攻撃です。
「入力エコー攻撃（Input Echo Attack）」は、MailDataを運営する株式会社Spelldataが名付けた名称です。
OWASPのContent Spoofing（Content Injection）の解説では、入力欄の文字列が自動送信メールに載る手口が例として挙げられており、入力エコー攻撃はこれに近い攻撃です。

入口
メールフォーム、アカウント登録の任意項目、アプリ名など、外部の人が自由に書き込める入力欄です。
悪用されるもの
入力内容を本文に載せた自動返信や通知のメールです。
送信者自身のドメインの鍵で、正規にDKIM署名されます。
届け方
署名済みのメールを手に入れて再送する（DKIMリプレイ）か、送信者自身に被害者宛てに送らせます。
結果
SPF・DKIM・DMARCを正規に通過し、BIMIのロゴ付きで届くこともあります。

DMARCが担保するのは、メールの送信元のドメインです。
入力エコー攻撃では、送信元は本物で、偽物なのはメールの中身です。
そのため、送信元のドメインを確認するだけでは見抜けません。

本記事では、楽天カードを名乗るメールの実例（2.〜6.）と、Google・Robinhoodの事例（7.）を取り上げます。
エコーされた入力は、楽天カードの事例では問い合わせフォームの入力（推測）、Googleの事例ではOAuthアプリ名、Robinhoodの事例ではアカウント登録の任意項目です。

2. 事例の概要

2026年10月、楽天カードを名乗るフィッシングメールが、ドコモのメールアドレス（docomo.ne.jp）宛てに届きました。
件名は「【楽天カード株式会社】楽天カード登録情報の更新について」という、典型的なフィッシングの文言です。
しかし、ドコモの受信サーバーの認証結果はSPF・DKIM・DMARCがすべてpassで、BIMIによるブランドロゴの表示まで有効になっていました。
この事例は、X上の投稿（@TechnoTreasure）で報告されたもので、本記事の分析は、同じ投稿者が別の投稿で公開したヘッダにもとづいています。

ドコモは、2026年10月15日に「不審メールに伴うお知らせ」を公表しています。
このお知らせでは、一部の公式アカウントの企業のメールで、「送信元のメール認証設定などの影響により、フィッシングメールにもかかわらず、公式アカウントマークが表示されるケースが報告されています」としています。
そのうえで、事象が解消するまでの一定期間、該当の企業についてドコモメール公式アカウントの表示を停止するとしています。
お知らせでは企業名は明らかにされておらず、本記事の事例がこのお知らせの対象に含まれるかどうかは、お知らせからは確認できません。

同様のメールは、1年前にも届いていました。
X上で提供された受信画面（2025年10月9日受信）では、件名「【ご注意】楽天カード登録情報の更新について」のメールに、ドコモメールの公式アカウントマーク（「公式アカウントより送信されたメールです」）と、BIMIによる楽天のロゴ（「本メールはドメイン所有者の認証済みメール(BIMI)です。」）の両方が表示されていました。
本文には楽天カードの定型文は見えず、フィッシングの文面とリンクだけが表示されていました。
このメールのヘッダは確認できていないため、本記事の事例と同じ手口かどうかは断定できません。

以下は、公開されたヘッダの抜粋です。
説明に必要な行だけを抜き出しており、値は公開されたヘッダのままです。
受信者のアドレスは、公開されたヘッダと同じく伏せています。 


Authentication-Results: docomo.ne.jp;
 spf=pass smtp.mailfrom= smtp.helo=ytdatangbaoan.com;
 dkim=pass header.d=mail.rakuten-card.co.jp header.s=rakuten-card-001;
 dmarc=pass header.from=mail.rakuten-card.co.jp dmarc_spf=fail dmarc_dkim=pass aspf=relaxed adkim=relaxed;
 bimi=pass header.d=mail.rakuten-card.co.jp header.selector=default
 policy.authority=pass
Received: from ytdatangbaoan.com ([161.33.150.25])
 by mfsmax.docomo.ne.jp(DOCOMO Mail Server Ver2.0) with SMTP id 30f200df6ad06171004e
 for <********>; Thu, 15 Oct 2026 15:22:42 +0900 (JST)
X-DCMCertifiedMail: 1
X-DCMCompany-E: Rakuten Group
Received: from sc-okmail1.okweb3.jp ([124.146.170.8]) by smtp.mail.td with
 ESMTPS tls TLS_AES_128_GCM_SHA256; Wed, 14 Oct 2026 12:19:43 +0000
Received: from localhost (mcv-bzwex5-1.sc.private.okweb3.jp [172.20.0.128])
 by sc-okmail1.okweb3.jp (Postfix) with ESMTP id 7D0631016BA5
 for <yghsbs@end.tw>; Wed, 14 Oct 2026 21:19:41 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=mail.rakuten-card.co.jp; s=rakuten-card-001; t=1791980381;
 bh=（省略）; h=From:From; b=（省略）
To: ********@docomo.ne.jp
Content-Type: multipart/alternative; boundary="no"

3. ヘッダから再構成したメールの経路

Receivedヘッダを下から読むと、このメールは次の2段階で配送されています。

  1. 2026年10月14日21時19分、楽天カードが問い合わせ対応に利用している外部サービスの送信基盤（sc-okmail1.okweb3.jp）から、攻撃者が用意したアドレス（yghsbs@end.tw）宛てに正規のメールが送信されました。
    送信基盤のドメイン（okweb3.jp）の登録者は、PKSHA Communication Inc.です。
    （JPRSのWHOIS、2026年10月19日に確認）
    ドメイン名は、Q&AとFAQを蓄積して顧客対応に活かす「ナレッジ統合型CRMツール」である「OKWeb3」の名称と一致します。
    （グッドデザイン賞の受賞紹介）
    ただし、楽天カードがこのツールのどの機能からメールを送っていたかは確認できていません。
    送信元のIPアドレス（124.146.170.8）は、楽天カードのSPFレコードで許可されているものでした。
    （mail.rakuten-card.co.jpのSPFレコードがincludeするspf03.rakuten-card.co.jpに「ip4:124.146.170.8」として記載。2026年10月19日に確認）
  2. 約18時間後の10月15日15時22分、楽天カードとは無関係なサーバー（ytdatangbaoan.com、161.33.150.25）から、ドコモの利用者宛てに同じメールが再送されました。

元の宛先と実際に届いた宛先が異なること、そして18時間の空白があることが、正規メールの再送（リプレイ）である証拠です。

4. なぜすべての認証を通過したのか

4.1 DKIM：正規の署名がそのまま残っている

DKIM署名は、本文と署名対象のヘッダが改変されていなければ、誰が再送しても有効です。
今回の署名は、楽天カードのドメイン（d=mail.rakuten-card.co.jp）の鍵で、楽天カードが利用する送信基盤が付与した本物です。
攻撃者は署名を偽造したのではなく、正規に署名されたメールを手に入れて、そのまま再送しています。

4.2 SPF：攻撃者自身のドメインでpassさせている（SPF Bypass）

再送時のエンベロープ送信者（MAIL FROM）は空、つまりnull reverse-pathでした。
RFC 7208 Section 2.4では、reverse-pathがnullの場合、「postmaster」とHELOのドメインを組み合わせたメールボックスを"MAIL FROM" identityとして扱うと定義しています。
そのため、SPFは楽天カードのドメインではなく、攻撃者がHELOで名乗ったドメイン（ytdatangbaoan.com）で評価されました。

攻撃者のドメイン（ytdatangbaoan.com）のSPFレコードは、次のとおりです。
（2026年10月19日に確認） 


v=spf1 +all

「+all」は、すべてのIPアドレスからの送信を許可する設定です。
どのサーバーから送っても、SPFは必ずpassします。
正規の送信者がこの設定を使うことはまずありませんが、「+all」のドメインを減点するかどうかは受信側の実装次第です。
ドコモの受信サーバーでは、そのままspf=passとして扱われています。

このように、自分のドメインでSPFをpassさせつつ、ヘッダFromだけをなりすます手口は「SPF Bypass」と呼ばれています。
（MailDataのSPFの解説ページ「8.1. SPF Bypass攻撃」も参照してください。）

4.3 DMARC：DKIM側のアラインメントでpass

SPFでpassしたドメイン（ytdatangbaoan.com）は、ヘッダFromのドメイン（mail.rakuten-card.co.jp）と一致しないため、DMARCのSPFアラインメントはfail（dmarc_spf=fail）です。
一方、DKIMの署名ドメインはヘッダFromと同じなので、DKIMアラインメントはpassします。
DMARCは、SPFとDKIMのどちらか一方のアラインメントがpassすればpassになるため、結果はdmarc=passでした。
（RFC 9989）

楽天カードのDMARCポリシーはp=reject; pct=100という厳格な設定ですが（2026年10月19日に確認）、DKIMリプレイはこのポリシーでは防げません。
なお、pctタグは、RFC 9989ではhistoric（非推奨）とされています。
SPF Bypassだけであれば、p=rejectで拒否されていたはずです。
DMARCを通したのは、DKIMリプレイです。

4.4 BIMI：DMARCがpassしたためロゴも表示

BIMIは、DMARCがpassしたメールに対してブランドロゴを表示する仕組みです。
DMARCがpassしている以上、受信側から見ればこのメールは正規のメールと区別できず、楽天カードのロゴ付きで表示されました。

ドコモメールには、BIMIとは別に、送信ドメイン認証に成功した申し込み企業のメールに「公式アカウントマーク」を表示する仕組みもあります。
（ドコモメール公式アカウント）
2.で紹介した2025年10月の受信画面では、BIMIのロゴと公式アカウントマークの両方が表示されていました。
利用者から見ると、二重に「本物」だと保証されているように見えます。

本記事の事例のヘッダにも、ドコモメールが付けたと考えられる「X-DCMCertifiedMail: 1」と「X-DCMCompany-E: Rakuten Group」が含まれています。
ヘッダの名前から、このメールも公式アカウントのメールとして扱われていたと考えられます。
また、BIMIの結果には「policy.authority=pass」があり、ロゴの証明書の検証にも合格していました。
送信元のドメインとロゴの正当性は、どちらも正しく検証されています。
偽物なのは、メールの中身だけです。

5. 本文を変えずに表示だけを変える仕組み

DKIMの署名は本文全体を対象にしており、今回の署名にはl=タグ（本文の一部だけを署名対象にする指定）もありません。
受信側でdkim=passになっているので、本文は署名時から1バイトも変わっていません。
では、なぜフィッシングの内容を表示させられたのでしょうか。

ポイントは、本文の「中身」ではなく「解釈のしかた」が変えられている点です。
本文をどう解釈するかは、Content-Typeヘッダ（MIMEの種類と境界文字列）で決まります。
今回の署名はh=From:Fromで、Content-Typeは署名対象外でした。
届いたメールのContent-Typeは、multipart/alternative; boundary="no"という不自然な値になっています。

注意
以下の手口は、ヘッダから推測したものです。
今回のメールの本文は確認できていません。
署名時と再送時のメールのヘッダと本文を比較した図。本文は同一のまま、To・Subject・Content-Typeだけが差し替えられている
署名時（左）と再送時（右）の比較。本文は同一で、署名対象外のヘッダだけが差し替えられている（推測を含む）

推測される手口は、次のとおりです。

  1. 攻撃者が、楽天カードの問い合わせフォームなどに、「--no」という境界行やHTMLのパートを含む文字列を入力する
  2. 楽天カード側のシステムが、その入力内容を含めて自動返信の本文を作る
  3. 送信基盤が、その本文に楽天カードの鍵でDKIM署名をする
  4. 署名済みのメールが、攻撃者のアドレスに届く
  5. 攻撃者は、署名対象外のContent-Typeヘッダだけをmultipart/alternative; boundary="no"に差し替え、件名と宛先も変えて再送する
  6. 受信側は、本文中の「--no」を境界行として解釈し、攻撃者が仕込んだパートをメールの内容として表示する

本文のハッシュ（bh=）は手順3の時点の本文から計算されるので、攻撃者の文字列も含んだ状態で正規に署名されています。
手順1で入力した文字列は、元のContent-Type（text/plainと想定）のままでは、ただの文字列にすぎません。
手順5でContent-Typeを差し替えることで、初めてMIMEの構造として解釈されます。

multipartのメールでは、最初の境界行より前の部分（プリアンブル）は表示されません。
RFC 2046 Section 5.1.1には、"implementations must ignore anything that appears before the first boundary delimiter line or after the last one." と書かれています。
そのため、楽天カードの定型文は表示されず、攻撃者が仕込んだHTMLパートだけが表示されます。

DKIMが保証するのは、「署名した時点から改竄されていないこと」と「どのドメインが署名したか」です。
「本文の中身が安全であること」や「ドメインの持ち主自身が書いた内容であること」までは保証しません。

6. 攻撃を成立させた3つの条件

今回の入力エコー攻撃は、次の3つの条件が重なって成立しています。

DKIMリプレイを成立させた条件
条件役割この条件がなかった場合
入力内容のエコー攻撃者が書いた文字列に、正規の署名を付けさせる攻撃者は本文の中身を操作できない
任意の外部アドレスへの送信署名済みのメールを攻撃者が手に入れるリプレイの素材が手に入らない
Fromだけの署名件名・宛先・Content-Typeを差し替えて、見せ方を変える件名は変えられず、仕込んだ文字列は「問い合わせ内容」として引用されたテキストのまま表示される

最も本質的なのは、入力内容のエコーです。
エコーがあると、攻撃者が書いた内容に正規の署名が付いてしまいます。
仮にContent-Typeまで署名していても、エコーが残っていれば、入力したURLが本文中にリンクとして表示されることはあり得ます。
見栄えは悪くなりますが、正規の署名とBIMIのロゴ付きで届く点は変わりません。
署名範囲を広げるのは、エコーが残った場合の被害を抑える対策で、エコーそのものの対策にはなりません。

7. エコーが原因となった他の事例

入力エコー攻撃は、今回の事例に限りません。
以下は、報道されている事例です。
いずれも二次報道にもとづいており、GoogleとRobinhoodの説明は、報道記事の中で引用されたものです。
（2026年10月18日に確認）

7.1 Google：OAuthアプリ名のエコー（2025年4月）

攻撃者は、自分で取得したドメインで「me@」というGoogleアカウントを作り、そのアカウントでOAuthアプリを作成しました。
アプリ名には、フィッシングメールの本文全文が入れられていました。
アプリにアクセス権を与えると、Googleがセキュリティアラートを「me@」宛てに送ります。
このメールには、アプリ名（つまりフィッシングの文面）を含んだまま、Googleの正規のDKIM署名が付きます。
攻撃者は、そのメールを標的のGmailへ再送しました（DKIMリプレイ）。
再送の経路は、同記事が引用しているEasyDMARCの分析によるものです。
Googleは、この経路を遮断する対策を展開したと説明しています。
（The Hacker News）

Googleの事例の流れを示した図。攻撃者がme@で始まるGoogleアカウントと、フィッシングの文面全文をアプリ名にしたOAuthアプリを作成し、Googleがそのアプリ名を含むセキュリティ通知を正規のDKIM署名付きでme@宛てに送信する。攻撃者はそのメールを改変せずに標的のGmailへ再送し、エンベロープの宛先だけが変わるため署名は有効なまま、Gmailでは宛先が「me」と表示される
OAuthアプリ名のエコーとDKIMリプレイによる手口（報道にもとづく構成図。アプリ名・文面はイメージ）

7.2 Robinhood：Gmailのドットエイリアスと登録項目のエコー（2026年4月）

Gmailは、ユーザー名に含まれるドットを無視して配送します。
被害者がjohn.doe@gmail.comを使っている場合、攻撃者はドットを除いたjohndoe@gmail.comで、Robinhoodの偽アカウントを作りました。
Robinhoodはこれを別のアカウントとして扱いますが、Gmailでは同じ受信箱に届きます。
攻撃者は、アカウント作成時の任意項目（例として「device name」欄）にHTMLを挿入し、Robinhoodのシステムメールの中に偽の警告文と悪意のあるボタンを表示させました。
メールはRobinhoodのサーバーから送られるため、SPF・DKIM・DMARCは正規にpassします。
（Finance Magnates）
この事例ではリプレイすら必要なく、送信者自身が、攻撃者の文字列入りのメールを被害者に直接届けています。
Robinhoodは、中核システムと顧客アカウントは侵害されていないと説明しています。
（同記事中の引用）
ただし、この不具合を修正したかどうかは、報道からは確認できません。

Robinhoodの事例の流れを示した図。攻撃者がドットを除いたGmailアドレスと、HTMLを入れたデバイス名で偽アカウントを登録し、Robinhoodがそのデバイス名を埋め込んだシステムメールを正規に送信する。johndoe@gmail.comにどこにドットを入れたアドレスも、Webサイトは別々のユーザーとして登録するが、Gmailはすべて同じ受信箱に配送するため、被害者の受信箱で本物のメールの中に偽の警告文とボタンが表示される
Gmailのドットエイリアスと登録項目のエコーによる手口（報道にもとづく構成図。件名・文面はイメージ）

7.3 手口によって有効な対策が異なる

エコーが原因となった事例の比較
項目本記事の事例Google（2025年4月）Robinhood（2026年4月）
エコーされた入力問い合わせフォームの入力（推測）OAuthアプリ名アカウント登録の任意項目
被害者に届ける方法攻撃者宛てのメールをリプレイ攻撃者宛てのメールをリプレイGmailのドットエイリアスで送信者に直接配送させる
ヘッダの差し替えあり（To・Subject・Content-Type）なし（改変せずに再送したと報道。宛先は「me」のまま表示）なし
署名範囲の拡大は効くか効く（被害軽減）効かない（改変なしで再送できる）効かない（改変がない）
HTMLのエスケープは効くか効かない（MIME構造の読み替え）該当しない（文面をテキストのまま表示）効く（HTMLがそのまま描画された）
エコーをやめることは効くか効く効く効く

3つの事例に共通して効く対策は、外部の入力を正規の署名付きメールにエコーしないことだけです。
署名範囲の拡大やHTMLのエスケープは、手口によって効いたり効かなかったりします。

8. 送信側の対策

送信側（ドメイン所有者と送信サービスの提供者）の対策は、次の9つです。
根本対策は8.1のエコーの禁止で、8.2以降は、エコーが残った場合の被害を抑え、リプレイに早く気付くための対策です。

8.1 Webのフォームに書かれた内容をメールに載せない（エコー禁止）

8.2 SPFとDKIMの双方のアライメントを一致させる

DMARCの仕様（RFC 9989 Section 8）は、DMARCに完全に参加する（Full DMARC Participation）ためにドメイン所有者が満たすべき要件として、次の2つをMUST（必須）と定めています。

MUST send mail so it produces an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain.

MUST send mail that has a DKIM Signing Domain that will produce a DKIM-Authenticated Identifier that has Identifier Alignment with the Author Domain.

（Author DomainとアラインしたSPF認証済み識別子が得られるようにメールを送信しなければならない（MUST）。
Author DomainとアラインしたDKIM認証済み識別子が得られる署名ドメインでメールを送信しなければならない（MUST）。）

受信側の判定では、SPFとDKIMのどちらか一方がアラインすればDMARCはpassします。
（RFC 9989 Section 5.3.5）
しかし、「DMARCは片方合格すればよい」として、SPFのMAIL FROM（Envelope From）がアラインしていない送信サービスを放置すると、リプレイ攻撃に気付けなくなります。

今回のリプレイでは、DKIMのアライメントはpassしていますが、SPFのアライメントはfail（dmarc_spf=fail）です。
すべての正規の送信元で双方のアライメントが一致していれば、DMARC集計レポートの「DKIMだけがpass」という記録は、リプレイの兆候として目立ちます。
一方、MAIL FROMがアラインしていない送信サービスが残っていると、正規のメールも「DKIMだけがpass」になり、リプレイが正規のメールに紛れて見分けられません。
また、受信側が双方のアライメントを求めている場合（9.1）、双方のアライメントが一致していない正規のメールは届かなくなります。
アライメントについては、DMARCアライメントとは？SPF・DKIMの一致判定とメールが届かない原因【2026年版】で詳しく解説しています。

8.3 SPFの許可範囲を最小化し、隠蔽化する

クラウドなどの共有基盤を広く許可すると、その基盤の他の利用者からのメールもSPF passになり得ます。
（BreakSPF）
許可するのは、必要なIPアドレスだけにします。
さらにSPFを隠蔽化し、どの送信基盤を使っているかを分かりにくくすることで、利用しているメール配信基盤の脆弱性を探すことを困難にできます。
今回の事例でも、攻撃者は、楽天カードのSPFで許可されている外部サービスの送信基盤から、署名済みのメールを手に入れています。
楽天カードのSPFは隠蔽化されていないため、include先を順にたどれば、利用している送信サービスがすべて分かります。
攻撃者は、その中から入力エコー攻撃に使えるサービスを探せばよいことになります。

8.4 利用しているサービスがメールを送信する場合は、DKIMの署名範囲を確認する

問い合わせフォームやアカウント登録など、利用しているサービスがメールを送信する仕様の場合は、そのサービスが何に署名しているかを確認します。
From以外に、Subject・To・Cc・Date・Message-ID・Reply-To・Content-Type・MIME-Versionも署名されているべきです。
さらに、存在しないヘッダも含めてオーバーサインされていれば、ヘッダの追加・差し替えを防げます。

RFC 6376 Section 5.4は、"The From header field MUST be signed" と規定しています。
それ以外のヘッダの署名は必須ではないため、Fromだけの署名は仕様違反ではありません。
しかし、同じSection 5.4の運用上の注記（INFORMATIVE OPERATIONS NOTE）では、Date・Subject・Reply-To・Senderと、すべてのMIMEヘッダを署名することが強く勧められています（"highly advised"）。

自社の問い合わせフォームにテスト投稿し、届いた自動返信のDKIM-Signatureヘッダのh=タグを確認すると、署名範囲が分かります。
ヘッダをメールヘッダ診断に読み込めば、署名範囲とアライメントの状態をまとめて確認できます。
署名範囲が狭い場合は、送信サービスの提供者に改善を求めるか、別のサービスへの切り替えを検討します。

8.5 フォームに書き込まれた内容が不正でないかをチェックする

フォームに入力された文章をチェックし、URL、「--」で始まる行、HTMLのタグ、base64のような長い英数字の羅列などを含む入力は、受け付けたうえで自動返信には載せないようにします。
ただし、MIMEの解釈は受信側の実装ごとの差が大きく、抜け道が残りやすいため、8.1を補う対策です。

8.6 Gmailのアドレスは、ユニーク性をチェックする

Gmailは、ユーザー名のどこにドットが入っていても、同じ受信箱にメールを届けます。
Webサイトがアドレスの文字列だけで重複を判定していると、Robinhoodの事例のように、被害者の受信箱に通知が届く別のアカウントを作られてしまいます。
gmail.comのアドレスで登録を受け付ける場合は、各文字の間にドットが入ったアドレスを同じアドレスとみなして、既存の登録と照合します。 


登録しようとしているアドレス：John.Doe@gmail.com

1. ユーザー名を小文字にし、ドットを取り除く → johndoe
2. 各文字の間にドットが入ってもよい正規表現を作る
   ^j\.*o\.*h\.*n\.*d\.*o\.*e@gmail\.com$
3. 既存の登録アドレス（小文字にしたもの）に一致するものがあれば、
   同じ受信箱のアドレスとして扱い、新規登録を受け付けない

ドットを取り除いて正規化したアドレスを別に保存し、その値で重複を判定する方法もあります。
Gmailは「+」以降の文字列も無視して配送するため（例：johndoe+abc@gmail.com）、あわせて確認します。
ただし、ドットの扱いはメールサービスごとに異なるため、この正規化はgmail.comに限った対策です。

8.7 DKIMの鍵を3か月ごとにローテーションし、リプレイを検知したら即座に失効させる

定期的なローテーションで、古い署名を再送できる期間を最長3か月に抑えます。
M3AAWGのDKIM Key Rotation Best Common Practices（2019年3月改訂）は「少なくとも6か月ごと」を推奨しており、3か月ごとはそれより厳しい運用です。
なお、ローテーションの周期はRFCでは定められていません。

あわせて、DMARC集計レポートを監視します。
「DKIMはpassしているのに、自社のSPFに含まれないIPアドレスから大量に送信されている」という記録は、リプレイの兆候です。
検知したら、定期の周期を待たずに鍵を失効させて再送を止めます。
今回の事例でも、使われたDKIMセレクタ（rakuten-card-001._domainkey.mail.rakuten-card.co.jp）は、その後DNSに存在しなくなっていました。
（全権威サーバーでNXDOMAIN、2026年10月19日にも確認）
ただし、鍵を消しても、すでに配送されたメールはロゴ付きのまま受信箱に残ります。

8.8 DNSSECを設定する

DKIMの公開鍵をCNAMEで提供するサービスでは、セレクタ._domainkey.自社ドメインに、サービス側のホスト名を指すCNAMEレコードを設定します。
DNSキャッシュポイズニング攻撃でこのCNAMEの応答を書き換えられると、受信側は、攻撃者が用意した公開鍵で署名を検証してしまいます。
そうなると、攻撃者は自分の秘密鍵で署名したメールを、自社ドメインのDKIM passとして届けられます。
自社ドメインにDNSSECを設定すると、受信側のリゾルバーが応答の改竄を検出できるようになります。
ただし、DNSSECの効果は、受信側のリゾルバーがDNSSECの検証を行っている場合に限られます。
また、CNAMEの参照先であるサービス側のゾーンが署名されていなければ、参照先の応答の改竄は検出できません。

8.9 ダングリングレコードをチェックする

利用をやめた送信サービスを指すCNAMEレコードが、DNSに残ったままになっていることがあります。
参照先のホスト名やアカウントを第三者が取得できる状態になると、そのレコードを使って、自社ドメインになりすましたメールを送られるおそれがあります。
特にAmazon SESのように、DKIMの設定にCNAMEレコードを使うサービスは、利用をやめたらDNSのレコードも削除します。
DNSのレコードを定期的に棚卸しし、参照先が存在しない、または自社の管理下にないレコード（ダングリングレコード）を削除します。

9. 受信側の対策

受信側の対策は、次の4つです。
今回のメールは、9.1と9.3のどちらか一方でも行っていれば拒否できていました。
9.2は、SPF Bypassで得られたpassを判定の材料から外す対策です。
9.4は、DMARCのpassだけで受信を決めず、メールの内容も含めて判定する対策です。
いずれもDMARCの仕様で求められている判定ではなく、受信側の独自の判断（ローカルポリシー）として行う対策です。

9.1 SPFとDKIMの双方のアライメントの一致を求める

DMARCの判定は、SPFとDKIMのどちらか一方がアラインすればpassです。
（RFC 9989 Section 5.3.5）
ドコモの受信サーバーも、dmarc_spf=failのまま、DKIMのアライメントだけでdmarc=passとしています。
受信側が双方のアライメントの一致を求めていれば、SPFのアライメントがfailになるリプレイは拒否できます。
MailDataの観測（2026年10月時点）では、GmailやOutlook.comなどの個人向けメールサービスは、すでにSPFのアライメントが一致しないメールを、DKIMのアライメントを満たしていても拒否しています。
（DMARCアライメントとは？の「実際の受信で起きていること」を参照）
ただし、今回のドコモのように、DKIMのアライメントだけで受信する受信サーバーもあり、すべての受信側が双方のアライメントを求めているわけではありません。

9.2 SPFの内容をチェックし、+allのような怪しいSPFは信用しない

今回のSPF Bypassでは、攻撃者のドメインの「v=spf1 +all」というSPFレコードで、spf=passになっています。
「+all」は、すべてのIPアドレスからの送信を許可する設定で、このSPFでのpassは、送信元について何も証明していません。
「+all」のようにすべての送信を許可するSPFレコードは、passしていても信用しない（減点する、または拒否する）ようにします。
なお、「+all」はSPFの仕様（RFC 7208）で禁止されている記述ではないため、受信側の判断で扱いを決める必要があります。

9.3 DKIMの署名範囲をチェックし、範囲が狭い署名は受信しない

今回の署名は、h=From:Fromで、From以外のヘッダを署名していませんでした。
署名範囲がFromだけのように狭い場合、署名対象外のTo・Subject・Content-Typeを差し替えても、署名は有効なままです。
DKIM-Signatureヘッダのh=タグを確認し、Subject・Content-Typeなどの主要なヘッダが署名されていないメールは受信しないようにします。
Fromだけの署名はRFC 6376の仕様違反ではないため（8.4）、これも受信側の判断として行う対策です。

9.4 多層フィルタリングを実装する

ドコモの受信サーバーは、DMARCにpassしたメールを、そのまま受信箱に届けています。
「DMARCに合格していれば受信する」と判定を単純化していることが問題です。
DMARCが担保するのは、そのメールの送信元のドメインです。
送信元が正しいからといって、メールの内容が安全であることを保証するわけではありません。

ドコモは、原因を「送信元のメール認証設定などの影響」とし、該当の企業の公式アカウントの表示を停止する対応を取っています。
（2.）
送信側の設定に原因があるという見方は、本記事の分析とも一致します。
ただし、表示の停止は、問題が報告された後の対応です。
送信側の不備は、どの企業でも今後起こり得ます。
そのため、受信側でも、DMARCのpassだけで受信や表示を決めない判定が必要です。

ドコモメールの「メールヘッダ情報」の画面では、「このメールが『mail.rakuten-card.co.jp』の所有者から送信されているかどうか、ドコモメールのサーバにて検証しました」と表示され、DMARCとSPFの結果がOKと示されます。
（2.で紹介した2025年10月の受信画面）
この画面には、DKIMの結果は表示されていません。
入力エコー攻撃では送信元は本物なので、送信元の検証結果をそのまま利用者に示すと、偽物の中身にまで「本物」のお墨付きを与えることになります。

これは、認証（相手が誰かを確かめること）と認可（その相手に何を許すかを決めること）を混同する問題に似ています。
正規のアプリとして認証されたからといって、そのアプリに何をさせてもよいわけではありません。
同じように、送信元が正規のドメインだと確かめられたからといって、そのメールの内容まで信用してよいわけではありません。

多くのMTAは、送信元IPのレピュテーション、SMTPの挙動、ヘッダの整合性、本文・添付ファイル・URLの解析など、SPF・DKIM・DMARCの検証以外の判定も組み合わせた多層フィルタを実装しています。
DMARCのpassは判定材料の一つとして扱い、SPFの内容（9.2）、署名範囲の狭さ（9.3）、件名や本文の内容、リンク先のURLなどとあわせて、受信の可否を判定します。
今回のメールにも、送信元IPが楽天カードのSPFで許可されたものではないこと、Content-Typeのboundaryが「no」という不自然な値であることなど、DMARC以外の判定で疑わしいと判断できる材料がありました。
多層フィルタについては、MTAの多層フィルタを理解するで解説しています。

10. 送信側・受信側対策早見表

送信側の対策
対策位置づけ主な実施者
フォームの内容をメールに載せない（エコー禁止）根本対策ドメイン所有者・送信サービス提供者
SPFとDKIMの双方のアライメントを一致させるリプレイの検知（RFC 9989のMUST要件）ドメイン所有者
SPFの許可範囲を最小化し、隠蔽化する共有基盤からのなりすまし対策（BreakSPF対策）・偵察の困難化ドメイン所有者
利用サービスのDKIMの署名範囲を確認する被害軽減策ドメイン所有者・送信サービス提供者
フォームの入力内容をチェックする補助策ドメイン所有者・送信サービス提供者
Gmailのアドレスのユニーク性をチェックするドットエイリアスの悪用対策Webサイトの運営者
DKIMの鍵を3か月ごとにローテーションする被害期間の限定と初動ドメイン所有者
DNSSECを設定するDKIM鍵の信頼性を守る周辺対策（DNSの応答の改竄対策）ドメイン所有者
ダングリングレコードをチェックするDKIM鍵の信頼性を守る周辺対策（放置されたレコードの悪用対策）ドメイン所有者
受信側の対策
対策位置づけ主な実施者
SPFとDKIMの双方のアライメントの一致を求めるリプレイの拒否受信サーバーの運用者
+allのような怪しいSPFは信用しないSPF Bypassの無効化受信サーバーの運用者
署名範囲が狭いDKIM署名は受信しないヘッダを差し替えるリプレイの拒否受信サーバーの運用者
多層フィルタリングを実装するDMARCのpassだけに頼らない判定（内容の検査）受信サーバーの運用者

11. よくある質問（FAQ）

Q1. Toを署名対象にすると、BCCや自動転送が使えなくなりませんか？

提案しているのは、Toで宛先を「絞る」ことではなく、Toヘッダを「署名対象に含める」ことです。
一般的なBCC配送では、受信者に届くToヘッダは署名時の内容のままなので、署名は壊れません。
ヘッダや本文を改変しない単純な自動転送であれば、DKIMはそのまま有効です。
署名が壊れるのは、件名や本文末尾を書き換えるメーリングリストのような経路です。

署名の有効期限（x=タグ）を短くする方法は、配送遅延とのトレードオフがあるため、補助策という位置づけです。

Q2. 転送で認証が壊れる問題は、送信側が対応すべきではありませんか？

送信事業者が担保すべき範囲は、自社から受信者への直接配送までだと考えます。
転送によって認証が壊れる問題は転送する側が解決すべきことで、転送する側がARC（RFC 8617、Experimental）を設定するという手段もあります。
転送の利便性のために、送信側が署名を弱くしてリプレイの余地を残すのは、順序が逆です。

そもそも転送では、SPFは転送するサーバーのIPアドレスで評価されるためfailになり、経路上で署名が壊れればp=rejectのドメインからのメールは届きません。
転送が必要なほどであれば、重要な通知は、実際に読んでいるアドレスを直接登録してもらうよう利用者に促すほうが確実です。

なお、転送とリプレイの両方の問題への対応を目指して、IETFではDKIM2の策定が進んでいます。
（IETF DKIM WG）
現在の仕様ドラフトでは、中継者による変更を記録して元の署名を検証できるようにし、受信側が想定外の再送を検出できるようにするとされています。
まだ標準化の途中なので、それまでは本記事の対策を積み重ねる必要があります。
DKIM2の仕組みについては、DKIM2とは？次世代のDKIMの仕組みと標準化の現状【2026年版】で解説しています。

Q3. なぜ署名対象をFromだけにしていたのでしょうか？

理由は送信基盤側に確認していないため、以下は推測です。
DMARCのアラインメントで見られるのは署名ドメイン（d=）だけで、RFC 6376でMUSTとされている署名対象もFromだけです。
そのため、「Fromさえ署名すれば認証は通る」という最小構成になっていた可能性があります。
また、RFC 6376 Section 5.4には、"Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit" という規定もあり、署名が壊れることを避けて対象を絞った可能性もあります。
ただし、Subject・To・Date・Content-Typeなどは、通常の配送で書き換えられるヘッダではありません。

Q4. 入力されたHTMLを適切にエスケープしていれば防げましたか？

HTMLのエスケープでは防げないと考えます。
攻撃者が仕込むのは「--no」という境界行や「Content-Type: text/html」といったパートのヘッダで、これらはHTMLではなく単なるテキストです。
HTMLのエスケープ（<を&lt;にする処理など）では変換されません。
さらに、仕込むパートに「Content-Transfer-Encoding: base64」を指定し、HTMLをbase64にした文字列を入力すれば、英数字と記号だけなのでエスケープもすり抜けます。
受信側は、そのパートをデコードしてからHTMLとして表示します。

ただし、これは本記事の事例（MIME構造の読み替え）についての説明です。
Robinhoodの事例のように、入力したHTMLがそのまま描画される手口では、エスケープが有効です。
手口にかかわらず効く根本対策は、入力内容をエコーしないことです。
（7. エコーが原因となった他の事例）

Q5. フォームに文字列を入力することは、「本文の変更」に当たらないのですか？

DKIMの意味での「本文の変更」には当たりません。
攻撃者の文字列が本文に入るのは、署名される「前」だからです。
本文のハッシュは署名時点の本文から計算されるので、攻撃者の文字列も含んだ状態で正規に署名されます。
その後に攻撃者が変えたのは署名対象外のヘッダだけで、本文は1バイトも変わっていません。

12. DMARCは実装して終わりではない

DMARCは、実装して終わりではありません。
p=rejectにして、BIMIを設定しても、それで終わりではありません。
今回のように、利用しているサービス自体が脆弱であれば、突破されます。
委託先の送信基盤も含めて、DMARCレポートを継続的に監視し、異常を早期に検知して対処し続けることが必要です。

MailData（PowerDMARC）では、DMARC集計レポートの可視化と、送信元ごとの認証結果の分析を通じて、こうした異常の検知を支援しています。
自社ドメインの送信元や署名範囲の確認をご希望の場合は、お問い合わせフォームからご相談ください。

13. 参考資料

いずれも2026年10月18日から19日にかけて確認したものです。
本文中で個別に確認日を記した箇所は、その日付の時点の内容です。