DMARCを「p=reject」に設定しても安心できない理由
2026年10月、国内で、正規企業を装ったフィッシングメールが送信ドメイン認証のDMARCを通過する事象が確認されました。メールの受信画面には、公式アカウントマークや企業のブランドロゴまで表示されていました。
NTTドコモは、一部企業の送信ドメイン認証の設定に脆弱性があるとして注意喚起しました。フィッシングメールにもかかわらず、ドコモメールの公式アカウントマークやBIMI（Brand Indicators for Message Identification）によるブランドロゴが表示されるケースがあるためです。これを受け、該当する企業の公式アカウント表示は一時的に停止されています。
本来、DMARCは企業のドメインを悪用したなりすましメールを防ぐための重要な技術です。とくに、DMARCポリシーを「p=reject」に設定していれば、送信ドメイン認証に失敗したメールを受信側で拒否できます。
それでは、なぜ今回、フィッシングメールがDMARC認証を通過してしまったのでしょうか。
この事象との関連で注目されているのが、正規のDKIM署名を悪用する「DKIMリプレイ攻撃（DKIM Replay Attack）」です。DKIMの暗号技術そのものを破るわけではありません。正規に署名されたメールを再利用して、送信ドメイン認証を通過させる手法です。
本ブログでは、DKIMリプレイ攻撃の仕組みと、企業が取るべき対策を解説します。
DKIMリプレイ攻撃とは何か
企業が送信するメールの正当性を確認する技術として、SPF、DKIM、DMARCの3つが広く利用されています。
SPFは、メールの送信元IPアドレスが、送信に使用されたドメインから許可されているかを確認する仕組みです。
DKIMは、送信側がメールに電子署名を付け、受信側がその署名を検証する仕組みです。これにより、署名ドメインによる認証と、署名対象が送信後に改変されていないことを確認します。
DMARCは、SPFまたはDKIMの認証結果に加えて、利用者に表示されるFromアドレスのドメインとの整合性（アライメント）を確認します。認証に失敗したメールの扱いを指定する仕組みでもあります。
ここで重要なのは、DKIMが検証するのは、メールに付けられた電子署名の正当性だという点です。そのメールを現在送信しているサーバーが正規のものかどうかは、確認しません。
たとえば、ある企業から正規のDKIM署名が付いたメールを受信した攻撃者が、そのメールを別のメールサーバーから第三者に再送したとします。DKIMの署名対象が改変されていなければ、受信側のDKIM認証は成功する可能性があります。
さらに、DKIMの署名ドメインとFromアドレスのドメインが一致している、またはDMARCのアライメント条件を満たしていれば、DMARCも認証成功となります。
つまり、攻撃者が正規企業のメール送信サーバーやDKIMの秘密鍵を直接侵害しなくても、正規の署名付きメールを再利用すれば、DMARC認証を通過できる場合があるのです。これがDKIMリプレイ攻撃の基本的な仕組みです。
今回のフィッシングメールでは何が起きたのか
第三者が公開しているメールヘッダーの分析では、次の可能性が指摘されています。攻撃者は正規のDKIM署名付きメールを入手し、署名を維持したままメールの一部を変更して再送したというものです。
とくに注目すべきなのが、DKIMの署名対象となるメールヘッダーがFromだけに限定されていた点です。
DKIMでは、どのヘッダーを電子署名の対象とするかを、DKIM-Signatureヘッダー内の「h=」タグで指定します。たとえば、次のような設定です。
h=From:From
この設定は、Fromヘッダーを署名対象とし、さらにFromヘッダーの不正な追加を検知するための指定です。一方で、Subject（件名）やContent-Type（メール本文の形式）などは署名対象に含まれていません。
このため、攻撃者はDKIM署名を維持したまま、件名など署名対象外のヘッダーを変更できます。
また、Content-Typeが署名対象外の場合、メール本文そのものは変更しなくても、MIME（Multipurpose Internet Mail Extensions）の構造を定義する情報を変更できます。これにより、メールソフトによる本文の解釈や表示に影響を与えられる場合があります。
ただし、DKIMでは通常、メール本文のハッシュ値も検証されます。署名対象がFromだけだからといって、攻撃者が本文を自由に書き換えられるわけではありません。今回のような攻撃では、本文のハッシュ値を維持しながら、署名されていないヘッダーを操作することが重要になります。
なお、具体的なメールの改変方法や送信経路は、公開された分析に基づくものです。関係企業による最終的な原因調査結果として確定したものではありません。
DKIMリプレイ攻撃の仕組み
図 1：正規のDKIM署名付きメールを再利用し、署名対象外のヘッダーを変更して再送するDKIMリプレイ攻撃の仕組み
図 1のように、攻撃者は正規企業から送られたDKIM署名付きメールを入手し、署名で保護されていないヘッダーなどを変更して再送します。受信側では、正規のDKIM署名が維持されているためDKIM認証が成功します。Fromドメインとのアライメントも成立すれば、DMARCも認証成功となります。
この結果、フィッシングメールにもかかわらず、正規企業のメールとして扱われてしまう可能性があります。
なぜDMARCの「p=reject」でも防げなかったのか
DMARCでは、SPFとDKIMの両方が認証に成功する必要はありません。次のいずれかの条件を満たせば、DMARCは認証成功となります。
- SPF認証が成功し、Fromドメインとのアライメントが成立する
- DKIM認証が成功し、Fromドメインとのアライメントが成立する
今回報告されている攻撃では、正規のDKIM署名が再利用されたことで、DKIM認証とアライメントが成立したと考えられます。そのため、SPFがFromドメインとのアライメントに失敗していたとしても、DMARC全体では認証成功となります。
ここで注意したいのは、DMARCの「p=reject」が、DMARC認証に失敗したメールを拒否するためのポリシーだという点です。認証に成功したメールの安全性を保証するものではありません。
正規のDKIM署名を悪用したメールは、DMARCの認証条件を満たしてしまう場合があります。そのため、DMARCを「p=reject」に設定していても、DKIMリプレイ攻撃を完全に防ぐことはできません。
これはDMARCの暗号技術が破られたということではありません。送信ドメイン認証の仕組みと、実際のメールの安全性を判断することは別だと示しています。
公式マークやBIMIのロゴが表示されることの問題
今回の事象でとくに注意が必要なのは、フィッシングメールに正規企業の公式アカウントマークやブランドロゴが表示されたことです。
BIMIは、DMARCなどの送信ドメイン認証を活用し、受信メールに企業のブランドロゴを表示するための仕組みです。また、ドコモメールの公式アカウントマークも、利用者が正規企業からのメールを識別しやすくするために提供されています。
いずれも、利用者がフィッシングメールを見分けるために役立つ仕組みです。ただし、メールの内容そのものが安全であることを保証するものではありません。
今回のように、正規の送信ドメイン認証を悪用できる状況では、攻撃者が送信したフィッシングメールにも、こうした信頼性を示すマークが表示される可能性があります。
利用者にとって、正規の企業ロゴが表示されたメールは、本物だと判断する大きな材料になります。そのため、今回の事象は、送信ドメイン認証だけでなく、認証結果に基づいたブランド表示の運用についても、重要な課題を示したといえます。
企業ロゴや公式マークの表示は、送信元を判断する際の参考にはなります。しかし、それだけでメールの安全性を判断することはできません。
DKIMリプレイ攻撃を防ぐために企業が取るべき対策
1．DKIMの署名対象を適切に設定する
もっとも重要なのは、DKIMの署名対象をFromだけに限定しないことです。DKIMの標準仕様であるRFC 6376では、Fromヘッダーへの署名を必須としています。一方、SubjectやToなど、その他のヘッダーへの署名は必須ではありません。
しかし、RFC 6376では、利用者に表示されるヘッダーや、メールの処理に影響するヘッダーも署名することが強く推奨されています。具体的には、以下のヘッダーを署名対象に含めることが望まれます。
| ヘッダー | 役割 |
|---|---|
| From | 送信者のメールアドレス |
| Subject | メールの件名 |
| To、Cc | 宛先 |
| Date | 送信日時 |
| Message-ID | メールの識別子 |
| Reply-To | 返信先 |
| Content-Type | 本文の形式 |
| MIME-Version | MIMEのバージョン |
加えて、必要に応じて、ヘッダーの不正な追加を防ぐオーバーサイニングも検討してください。とくにSubjectやContent-Typeを署名対象に含めることは、今回のようなメールの改変を伴うリプレイ攻撃に有効です。
2．外部メール配信サービスのDKIM設定を確認する
企業のメールは、必ずしも自社のメールサーバーから送信されているわけではありません。マーケティングメール、問い合わせフォームの自動返信、会員登録通知、請求書や決済通知など、多くのメールが外部のクラウドサービスから送信されています。
こうしたサービスでは、企業が所有するドメインを利用してDKIM署名を付与することがあります。自社のメール基盤でDKIMを適切に設定していても、外部のメール配信サービスの署名設定が不十分であれば、同様のリスクが生じる可能性があります。
自社が利用しているすべてのメール送信サービスについて、DKIMの署名対象やドメイン管理状況を確認することが重要です。
また、問い合わせフォームなどを通じて、第三者が任意のメールアドレスに正規のDKIM署名付きメールを送信させられないかも確認する必要があります。こうした自動返信メールは、重要な通知メールとは送信ドメインを分離するなど、リスクに応じた管理が求められます。
3．DMARCレポートを継続的に監視する
DMARCを導入しただけでは、メール送信環境の安全性を継続的に確保できません。今回のようなDKIMリプレイ攻撃では、DMARC認証が成功します。そのため、認証の成功率だけを監視していても、不審なメールを発見できない可能性があります。
注目すべきなのは、DMARC認証に成功しているメールが、どのIPアドレスやメール送信基盤から送られているのかという点です。
たとえば、通常は自社のメール配信サービスからしか送信されないはずのメールが、突然、無関係なIPアドレスから大量に送信されている場合には注意が必要です。
DKIM認証は成功していても、SPFのアライメントが成立していないケースや、通常とは異なる送信元からのメールが急増しているケースは、詳しく調査する価値があります。
ただし、正規のメール転送でも同様の認証結果が発生するため、送信元IPアドレスだけで攻撃を断定することはできません。DMARCの集計レポートに加えて、メール送信ログなどを組み合わせ、通常のメール送信状況との違いを継続的に確認することが重要です。
4．DKIM鍵の管理と署名の有効期間を適切に設定する
DKIMの秘密鍵を適切に管理し、定期的にローテーションすることも重要です。また、DKIM署名には、有効期限を設定するための「x=」タグが用意されています。
署名の有効期間を適切に制限すれば、古い正規メールが長期間にわたってリプレイ攻撃に利用されるリスクを軽減できます。
ただし、鍵のローテーションや署名の有効期限だけで、リプレイ攻撃を完全に防ぐことはできません。署名が有効な期間内に再送されたメールは、依然として認証に成功する可能性があります。
そのため、署名設定の見直し、送信経路の管理、異常な送信状況の監視を組み合わせることが必要です。
また、鍵のローテーションの運用性も重要です。送信サービスごとの鍵の作成・登録・削除は運用上の課題となりやすく、一元管理と設定ミスの防止が欠かせません。
DMARCは導入して終わりではない
DMARCは、企業のドメインを悪用したフィッシングメールやビジネスメール詐欺への対策として、重要な技術です。とくに、DMARCポリシーを「p=reject」に設定することは、送信ドメイン認証に失敗したなりすましメールの排除に大きく貢献します。
しかし、今回のDKIMリプレイ攻撃の事例は、DMARCを導入していても、それだけですべてのフィッシングメールを防げるわけではないことを示しています。
企業のメール送信環境は、年々複雑化しています。自社のメールサーバーだけでなく、マーケティングツール、顧客管理システム、問い合わせフォーム、クラウドサービスなど、さまざまなシステムが企業のドメインを利用してメールを送信しています。
これらの送信経路の中に不適切なDKIM設定があると、正規の送信ドメイン認証が攻撃者に悪用される可能性があります。
企業に求められるのは、DMARCを「p=reject」に設定することだけではありません。外部のメール配信サービスを含めたDKIM設定の確認、送信ドメインの適切な管理、DMARCレポートの継続的な監視によって、メール送信環境全体の信頼性を維持することが重要です。
また、受信側でも、SPF、DKIM、DMARCによる送信ドメイン認証だけでなく、メールの内容、URL、添付ファイル、送信者の振る舞いなどを組み合わせた多層的な脅威対策が求められます。
今回の事象は、送信ドメイン認証の重要性を否定するものではありません。認証技術を適切に運用し続けること、そして認証結果だけに依存しないセキュリティ対策が必要であることを、改めて示した事例といえるでしょう。
参考資料
- NTTドコモ「ドコモメール公式アカウントに関するお知らせ」
- RFC 6376「DomainKeys Identified Mail (DKIM) Signatures」
- RFC 7960「Interoperability Issues between DMARC and Indirect Email Flows」
- DMARCの仕組み（解説動画）
- DMARCスタートガイド（プルーフポイント）
- DMARC解説（プルーフポイント）