DKIMリプレイ攻撃とは。運営者が見直すメールのDNS設定

こんにちは、株式会社TIMEWELLの濱本です。

2026年10月15日、NTTドコモが「不審メールに伴うお知らせ」を出しました。ドコモメールの公式アカウントに参加する一部の企業について、フィッシングメールにも公式アカウントマークが表示される事象が報告されている、という内容です。原因は「送信元のメール認証設定などの影響」とされ、該当企業の公式アカウント表示は一定期間止められます。¹

SPFもDKIMもDMARCも通って、ロゴまで付いたメールが偽物でした。この事実は、メールの認証を整えてきた運営者ほど重く受け止めるものでしょう。

この記事では、公表されている事実と、まだ分かっていないことを分けたうえで、DKIMリプレイ攻撃の仕組みを整理します。そのうえで、ドメインを持つ運営者がDNSとメール配信で見直すべき6項目を、規格と業界団体の指針に沿って書きます。

何が起きたのか。公表されている事実と、まだ分かっていないこと

まず、公式に確認できる範囲です。

NTTドコモの告知は、短い文章です。公式アカウントマークが表示されるフィッシングメールの報告があること、原因は送信元のメール認証設定などの影響とされていること、事象が解消するまで該当企業の表示を止めること、不審なメールは閲覧を中止するか削除すること。書かれているのは、これだけです。対象企業の名前、報告の件数、認証設定の具体的な中身、表示の再開時期は、告知に載っていません。¹

楽天カードは10月19日の告知で、同社を装い、楽天ブランドシンボルや公式アカウントマークを表示したなりすましメールを確認していると述べています。件名の例として「【重要】お支払い手続きのご案内」などを挙げ、カード番号16桁や楽天ID、ワンタイムパスワードをメールや電話で聞くことはないと案内しています。情報の更新が必要なときは、メールのリンクではなく、公式アプリや公式サイトから行うよう求めています。一方で、メールがどういう経路で届いたか、送信基盤に何があったかは、この告知には書かれていません。²

ここから先が、慎重に扱うべき部分です。X上では、届いたメールのヘッダーを調べた技術者の分析が広く共有されました。要旨は次のとおりです。

• 正規の送信基盤から、攻撃者が用意したアドレスに正規のメールが送られた
• 署名はそのまま有効なので、別のサーバーから被害者に再送しても、DKIMの検証は通る
• 署名の対象がFromヘッダーだけで、件名や本文の区切りは書き換えられた
• SPFのpassは、攻撃者自身のドメインで判定させる別の経路で得られた

これは個人の技術者による分析で、ドコモと楽天カードの公表には、この説明を確認する記述がありません。今回の事象の真相だと断定はできません。ただ、ここに出てくる仕組みはいずれもRFCに書かれた挙動で、今回の事件と無関係に、どのドメインの運営者にも当てはまります。次の章から、その仕組みを一つずつ見ていきます。

DKIMリプレイ攻撃の仕組み。なぜ「全部pass」になるのか

DKIMは、メールの送信側がヘッダーと本文のハッシュに電子署名を付け、受信側がDNSの公開鍵で検証する仕組みです。確かめているのは、署名された範囲が転送の途中で変わっていないことです。誰が送ったか、どこから送られたかは確かめません。

ここに、リプレイ攻撃の入り込む余地があります。署名はメールに付いたまま、誰の手を経ても有効です。攻撃者が自分宛てに正規のメールを送らせ、署名を保ったまま別の宛先に再送すれば、受信側の検証は通ります。RFC 6376の8.6節は、この種の攻撃を「リプレイ・スパム攻撃」として扱っています。スパム送信者が、署名ドメインの評判を借りるために、署名付きのメッセージを多数の宛先へ再送するというものです。³

厄介なのは、署名の範囲です。RFC 6376の5.4節は、Fromヘッダーの署名を必須としています。それ以外のヘッダーは、署名者が選べます。件名、日付、Reply-To、MIME関連のヘッダーに署名することが強く勧められていますが、義務ではありません。受信側が、署名されていないヘッダーを強く疑ってもよい、という注意も添えられています。³

つまりFromだけに署名した配信基盤は、規格には違反していません。それでも、再送のときに件名や本文の区切りを書き換える余地を、最大にしてしまいます。

さらに、RFCは「存在しないヘッダーを署名に含める」ことも認めています。実際には付いていないヘッダー名を署名の対象に入れておけば、あとからそのヘッダーを足されたときに、検証で検出できます(オーバーサイン)。ただし、将来定義されるヘッダーまでは予測できないので、すべての追加を防げるわけではない、という限界もRFC自身が書いています。³

なお、署名に有効期限(x=タグ)を付ける方法もあります。ただしRFC 6376は、このタグがリプレイ防止を目的としたものではないと明記しています。メールの配送には数時間の遅延がありうるので、期限を極端に短くもできません。³

SPFのpassはどこから来たのか。DMARCがpassする理由

SPFが確かめるのは、メールを送ってきたサーバーのIPアドレスが、エンベロープ送信者(MAIL FROM)のドメインで許可されているかどうかです。画面に表示されるFromとは、別のものです。

RFC 7208の2.4節には、MAIL FROMが空のとき、つまりバウンスのような通知メールのとき、HELOの名前から組み立てた「postmaster@HELOのドメイン」を判定に使う、という決まりがあります。⁴ 先ほどの分析が指摘したのは、この経路です。攻撃者は、自分が管理するドメインをHELOに使い、MAIL FROMを空にして、SPFをpassさせました。

ただしこのSPFのpassは、Fromのドメインとは一致していません。DMARCは、SPFまたはDKIMのどちらかがpassして、かつ、そのドメインが表示上のFromと一致していること(アライメント)を求めます。この経路のSPFは、DMARCの条件を満たしません。DMARCを通したのは、Fromと同じドメインで署名されたDKIMだった、というのが分析の読み解きです。

結果として、SPF、DKIM、DMARCのすべてがpassします。そして、p=rejectでも止まりません。署名は本物で、署名ドメインもFromと一致しているからです。公式アカウントマークやBIMIのロゴは、DMARCなどの認証結果をもとに表示されるため、そのまま付いてきます。ドコモの告知にも、公式アカウントマークは送信ドメイン認証に基づく表示であり、メールの安全性を保証するものではない旨があります。¹

運営者がDNSとメール配信で見直す6項目

ここからが本題です。リプレイは、署名する側の設計で被害の大きさが決まります。ドメインを持つ運営者が、見直せる箇所を6つに分けます。

1. 送信しているメールの一覧を作る。

自社のドメインから出ているメールの流れを、全部書き出します。業務のメール、お知らせ、フォームの自動返信、請求書の送信、マーケティング、外部のSaaSからの通知。M3AAWGの指針も、鍵の更新を始める前の準備として、この棚卸しを最初に置いています。DMARCをp=noneで公開し、集計レポート(rua)の宛先を設定すれば、ドメインを名乗って出ているメールの実態が日々届きます。⁵ 知らないサービスが自社ドメインで送っていたら、それがまず一つ目の発見になります。

2. DKIMの署名範囲を、委託先と一緒に確かめる。

署名の範囲を決めるのは、配信基盤の側です。自社のメールを外部の配信サービスに任せている運営者は、そのサービスが何に署名しているかを確認してください。確認したいのは、Fromに加えて、Subject、To、Cc、Date、Message-ID、Reply-To、Content-Type、MIME-Versionが署名の対象に入っているか、存在しないヘッダーのオーバーサインをしているかです。RFC 6376が強く勧めているのは、件名や日付、Reply-To、MIME関連のヘッダーです。³ 設定できない配信サービスなら、問い合わせて改善を求めるか、別のサービスを検討する理由になります。

3. DKIMの鍵を2048ビットにして、定期的に入れ替える。

M3AAWGは、DKIMの鍵を少なくとも6か月ごとに入れ替えることを勧めています。2019年の改訂で、以前の「3か月ごと」から「6か月ごと」に改められました。鍵を入れ替える目的は、鍵が破られたり盗まれたりしたときの被害の期間を短くすることと、緊急のときに慌てないよう、手順に慣れておくことです。同じ文書は、2048ビットのRSA鍵を、現在の計算環境では破れないと考えられる強度としています。⁵

リプレイとの関係では、古い鍵を残さないことが効きます。入れ替えたあとの古い鍵をDNSから消せば、その鍵で署名された過去のメールは、以後の再送で検証に失敗します。リプレイの兆候を見つけたときは、定期の周期を待たずに、その場で鍵を失効させる運用も考えられます。ただし、すでに配送されたメールが受信箱から消えるわけではありません。

4. SPFを必要なIPだけに絞る。

SPFのincludeで広い範囲を許可すると、同じ基盤を使う他の利用者のメールも、自社のSPFでpassになる可能性があります。許可は必要な範囲に限り、使っていないサービスのincludeは外します。SPFにはDNSの問い合わせ回数に上限(10回)があるので、includeを増やし続けると、そもそも判定が壊れます。⁴

5. DMARCは、運用して終わりにしない。

2023年2月、総務省、警察庁、経済産業省は連名で、クレジットカード会社等に対してフィッシング対策の強化を要請しました。内容は、利用者向けに公開するすべてのドメイン(メールを送らないドメインも含む)にDMARCを導入し、受信側でなりすましメールを拒否するポリシーで運用すること、でした。⁶ 日本の企業では、DMARCを導入していてもポリシーが監視だけのp=noneにとどまる例が多いと、報告されています(日本プルーフポイントの調査で、日本企業はnone 63%、quarantine 13%、reject 7%。米国企業はreject 46%)。⁷

p=none、quarantine、rejectの順に、集計レポートを見ながら段階的に強めるのが基本です。メールを送らないドメインやサブドメインは、SPFを「-all」、DMARCをrejectにして、使われない状態にしておきます。そのうえで、リプレイへの備えとして、集計レポートを見る習慣を付けてください。「DKIMはpassしているのに、自社のSPFに含まれないIPから大量に送られている」という記録は、再送の兆候になりえます。

6. 確認の取れていない宛先に送るメールを、本番の送信ドメインから分ける。

リプレイの材料になるのは、攻撃者が受け取った、正規の署名付きメールです。問い合わせフォームの自動返信、会員登録の確認メール、パスワード再発行のメールは、誰でも任意のアドレスを入力して、署名付きのメールを受け取れます。この種のメールを、請求や重要なお知らせと同じ送信ドメインから出していると、攻撃者に再送の素材を渡すことになります。

自動返信や確認メールは、本番の通知とは別のサブドメインから送ります。そのサブドメインには、公式アカウントマークのためのBIMIを設定しません。利用者が入力した内容を本文にそのまま入れない、1つのアドレスや1つのIPからの送信回数を制限する、といった設計も合わせて入れておきます。

この項目は、公表された事件の分析から私が引き出した対策であって、規格や公的機関が定めた手順ではありません。それでも、リプレイが「受け取れる署名付きメール」を前提に成り立つ以上、理屈は通っていると考えています。

受け取る側と社内にも伝えること

運営者の設定を直しても、すべてのメールが安全になるわけではありません。社員と取引先への伝え方も、あわせて整えておきます。

最初に伝えたいのは、公式アカウントマークやBIMIのロゴは、本文とリンクの安全を示すものではない、ということです。ドコモの告知は、不審な点のあるメールを開かず、削除するよう求めています。¹ 楽天カードも、メールのリンクではなく、アプリや公式サイトから手続きするよう案内しています。² この「リンクから入らない」という行動が、認証がすり抜けられたときの最後の砦です。

次に、自社の名前を使った偽メールが出回ったときの動き方も決めておきます。お客様への注意喚起の掲載場所、問い合わせ窓口、プロバイダーやフィッシング対策協議会への通報、ドメインの状況確認の担当者。事件の最中に決めようとすると間に合いません。

ID管理や端末の対策は、前編・後編の記事でまとめています。相次ぐ不正アクセスから学ぶ【後編】では、中小企業が優先してやる項目を並べているので、メール以外の入口もあわせて確認してください。

まとめ

SPF、DKIM、DMARCがすべてpassしても、メールの安全は保証されません。署名は、誰が再送しても有効だからです。リプレイへの備えは、署名の範囲を広げること、鍵を定期的に入れ替えること、確認の取れていない宛先に送るメールを本番のドメインから分けること、集計レポートを読み続けることで固めます。

今回の事象の原因は、公式には、まだ明らかになっていません。ドコモと楽天カードが事実を出して、注意を呼びかけていること自体は、適切な動きだと思います。続報が出たら、この記事を更新します。

最初の一歩としては、自社のドメインのDMARCレコードが、いまどのポリシーになっているかを見てください。p=noneのままなら、それは「監視中」であって、「守っている」状態ではありません。メールの運用や社内の周知の設計について相談したい方は、WARP SECURITYの個別相談からお声がけください。

参考

Footnotes

1. 不審メールに伴うお知らせ（ドコモメール公式アカウント） — NTTドコモ — 2026年10月15日 ↩ ↩² ↩³ ↩⁴

2. 楽天カードを装った不審なメール・電話について — 楽天カード — 2026年10月19日 ↩ ↩²

3. RFC 6376 DomainKeys Identified Mail (DKIM) Signatures — IETF — 5.4節、8.6節、3.5節 ↩ ↩² ↩³ ↩⁴ ↩⁵

4. RFC 7208 Sender Policy Framework (SPF) — IETF — 2.3節、2.4節 ↩ ↩²

5. M3AAWG DKIM Key Rotation Best Common Practices — Messaging, Malware and Mobile Anti-Abuse Working Group — 2019年3月改訂 ↩ ↩²

6. クレジットカード会社等に対するフィッシング対策強化の要請 — 総務省・警察庁・経済産業省 — 令和5年2月1日 ↩

7. フィッシング対策協議会「DMARC の導入状況と必要性について」を公開 — ScanNetSecurity — 2025年2月12日 ↩