日本の利用者に届いたフィッシングメールに、正規企業の公式アカウントマークやブランドロゴが表示されたと報告されています。2026年10月18日付とされるProofpointの解説は、正規の署名付きメールを入手し、署名対象外の情報を変えて別の受信者へ再送するという仕組みを取り上げています。
企業のDKIM署名が有効なまま残り、表示Fromと整合していれば、フィッシングに使われたメールでもDMARCは成功し得ます。問題は、送信側が実際に保護した範囲と、利用者がメール全体に寄せる信頼の間にあるずれです。
報告された事案で、何が起きたのか
Proofpointによると、ドコモは一部企業の送信ドメイン認証設定について注意喚起し、影響する公式アカウント表示を一時停止しました。この注意喚起の一次参照先が、ドコモの告知です。
第三者のヘッダー分析を基に説明されている流れは、次の5段階です。
- 正規の署名付きメールを入手する。 攻撃者が企業のDKIM署名を含むメールを取得します。具体的な入手経路は、今回確認した資料では確定していません。
- 保護された情報を残す。 分析で紹介された署名対象は
h=From:Fromでした。Fromは保護されますが、Subjectと最上位のContent-Typeは対象外です。 - 対象外の情報を変更する。 件名を変えれば依頼の印象が変わり、Content-Typeの変更で同じ本文の解釈が変わる場合があります。保護された本文を自由に置き換えられる、という意味ではありません。
- コピーを再送する。 受信側では元の署名を引き続き検証できます。新しい配送経路でSPFが整合しなくても、整合したDKIMが成功すればDMARCも成功します。
- ブランド表示で信頼感が増す。 ロゴや公式マークが依頼の信頼性を高く見せても、内容が安全であることまでは証明しません。
図1．報告で説明されている仕組みです。実際の配送ログを再現したものではありません。原寸で見る。
証拠上の限界： Proofpointが述べるのは、第三者分析から考えられる仕組みであり、関係企業による最終的な原因調査の結論ではありません。今回の確認では、実際の攻撃メールと完全なヘッダー分析は未入手です。また、ドコモ自身のメールサーバーや署名鍵が侵害されたことを示すものではありません。
何を変えて、何を残したのか
次はexample.comを使った架空の比較例です。実際の検体を再現せず、署名範囲の問題だけを示します。
| 項目 | 元のメール | 再利用されたコピー |
|---|---|---|
| From | notices@example.com |
同じ |
| 署名ドメイン | d=example.com |
同じ |
| 署名対象外のSubject | Monthly notice | Urgent: review your account |
| 署名対象外のContent-Type | text/plain |
text/html |
| 保護された本文 | 同じ無害なバイト列 | 同じ無害なバイト列 |
| 配送サーバー | 通常の企業の送信元 | 別のサーバー |
図2．署名対象を維持すれば、署名が有効なまま残る場合があります。表示への影響は元のメールとクライアントに依存します。原寸で見る。
Fromが2回列挙されていても、他のヘッダーまで保護されるわけではありません。重要なのは、意味や表示に影響する項目が署名から抜けていることです。全文を対象にしたDKIMは本文を保護しますが、最上位のMIME解釈用ヘッダーは別の変更対象になり得ます。
署名範囲を広げれば、このような変更を制限できます。ただし、無変更のメールの再送や、アプリケーションが攻撃者指定の内容を正規に署名してしまう濫用までなくなるわけではありません。
なぜDMARCとブランド表示だけでは判断できないのか
再利用されたメールは、整合したDKIMによってDMARCの条件を満たします。p=rejectが対象にするのはDMARCに失敗したメールです。このメールは成功するため、失敗時の拒否指示は適用されません。内容検査、レピュテーション、受信側のポリシーで引き続き評価する必要があります。
BIMIによる表示とドコモ独自の公式アカウントマークは、事業者ごとのルールが異なる仕組みです。報告されたロゴがすべてBIMIだったとは確認できていません。どちらも利用者の信頼感に影響しますが、URL、添付、支払い指示の安全性を保証しません。
図3．表示された送信者情報は、依頼された操作の承認ではありません。原寸で見る。
DMARCの強制ポリシーは維持します。SPFとDKIM両方の成功を一律に求めると、正規の転送に影響する場合があります。また、署名ドメインがすでにFromと完全一致している再利用は、厳格アラインメントだけでも防げません。
Enterprise Email Protection・TAPで確認すること
調査の目的は、どのメールが届き、署名は何を保護し、配送後に何が起きたかを明らかにすることです。Email Protectionから始め、TAPの証拠を突き合わせます。メニュー、検索項目、保存期間はテナントと権限に依存するため、契約環境のHelpで確認してください。
図4．2つの検索結果を、1つの調査に結び付けます。原寸で見る。
1．Email Protectionで配送を追跡する
場所： メッセージ検索。一般的には Logs and Reports → Smart Search です。
受信者と明示した受信時間帯で検索し、表示タイムゾーンを記録します。対応していれば正確なMessage-IDも使います。送信者と件名を照合しますが、署名されない件名は変更できるため、それだけで調査範囲を決めないでください。
該当記録を開き、ログID、接続元IP、エンベロープ送信者、取得できる表示From、経路、処理結果、適用ルールを残します。配送・隔離・拒否を区別してください。記録がなければ、保存期間、権限、その配送がゲートウェイを通ったかも確認します。
2．原本の署名範囲を確認する
場所： メッセージ詳細・原本ヘッダー表示。コンソールに原本がなければ、権限のある担当者がメールボックスから取得した.emlです。
原本は変更せず保全します。信頼できる受信ゲートウェイのAuthentication-Resultsと、実際のDKIM-Signatureを確認します。署名ドメインとセレクターを記録し、Subject、Reply-To、必要なMIMEヘッダーがh=に含まれるかを調べます。本文長制限や有効期限があれば、その設定も確認します。
送信側ログとも照合してください。有効な署名と説明のつかない送信元の組み合わせは手がかりであり、再送の証明ではありません。正規の転送や再試行でも似た結果になります。Smart Searchで全署名項目を検索できるとは限りません。
3．TAPで脅威と操作を突き合わせる
場所： TAP Threat Insight Dashboardの、利用できるメール・メッセージ脅威画面です。
受信者と時間範囲を照合し、対応していればメッセージ・脅威識別子も使います。関連する脅威の分類、判定、検知の時系列を記録します。URLは利用できるクリック時刻とブロック・許可の処理、添付は取得できるハッシュと解析結果を確認します。担当者自身で不審な宛先やファイルを開かないでください。
TAPの脅威画面は全配送の台帳ではないため、該当がなくても安全とは判断できません。リプレイが悪意あるURLや添付として認識されない場合もあります。クリックがあれば調査しますが、それだけで認証情報が盗まれたとは断定しません。
4．対象経路を封じ込め、修正を確認する
場所： 該当するEmail Protectionのポリシー・隔離機能、送信サービス責任者、実際の署名基盤です。
証拠に基づき、責任者と戻し方を決めた限定的な対処を行います。必要に応じて、悪用されたテンプレートやアカウントを停止します。DMARC成功を理由に送信者を許可したり、DKIM成功・SPF失敗をすべて拒否したりしないでください。
Proofpointが署名を付けているなら、対応する送信署名設定を確認します。ESP、Microsoft 365、Google Workspace、アプリケーションが署名しているなら、その管理者が範囲を修正します。TAPのURL設定では、第三者のDKIM署名を変更できません。
配送済みメールの対処は、メールボックス管理者と調整します。Enterprise Email Protection＋TAPに回収・削除機能が含まれるとは想定せず、未契約のTRAP・CLEARも前提にしません。変更後は管理下の宛先に無害なメールを送り、意図した署名範囲、整合性、配送、必要な転送経路を確認した新しい検体を保全します。
調査記録には、Email Protection＋TAPの作業チェックリストを利用できます。
企業として変えるべきこと
| 優先事項 | 対応 | 完了を確かめる証拠 |
|---|---|---|
| 署名範囲 | 全送信元で表示・MIMEヘッダーの保護と、対応するオーバーサイニングを確認 | 新しい原本のh=が意図した項目を含む |
| 署名付きメールの生成 | 利用者が指定する件名・本文・宛先、テンプレート、送信頻度を制限 | 任意のブランド付きメールを生成できないことを確認した業務フロー |
| 事業者の責任 | 署名元、ドメイン、セレクター、委託先、業務責任者を台帳化 | 各経路の責任者と、対応できる修正方法 |
| ライフサイクル | 鍵の保護・更新、本文長制限、有効期限を点検 | 正規配送を保つ試験結果。更新や期限だけで再送を防げるとはしない |
To/Ccへの署名はSMTPエンベロープの宛先を固定しません。専用サブドメインも、分離できたと判断する前にアラインメントを確認します。これらは実際の署名元で行う運用点検であり、受信認証を弱める理由ではありません。
修正後に監視すること
DMARC集計レポートを、Email Protectionの配送記録と送信側ログに突き合わせます。特に、見慣れない基盤から整合したDKIMの成功が増え、同じ署名が反復するのに対応する送信記録がない場合を調査します。
図5．見慣れない送信元を判定する前に、正規の転送があるかを確認します。原寸で見る。
集計レポートは遅れて届く要約であり、原本ではありません。どこが変わったのかを確かめるため、検体と信頼できるログを保全します。本記事では、この事案について独立に確認したIOCは公開していません。
図6．保全し、理由を説明し、封じ込め、確認します。原寸で見る。
調査で明らかにすべきなのは、署名した経路、保護された項目、そして署名済みコピーを悪用できた機能や配送経路です。その結果に基づいて修正箇所を決めます。
出典と確認記録
- Proofpoint — DKIMリプレイ攻撃に関する解説。提供された抜粋ではYukimi Sohta氏、2026年10月18日と記載されています。
- ドコモ — 公式アカウントに関する告知。
- RFC 6376の書誌情報とDKIM仕様。特に署名範囲とリプレイの注意点。
- RFC 7960 — DMARCと間接的な配送、RFC 7489 — DMARC原仕様、RFC 8601 — Authentication-Results。
- Proofpoint Help。テナントの画面、項目、権限を確認してください。
確認上の制約： 事案の説明は、提供されたProofpointの抜粋に基づき、出所を明示しています。確認時にProofpointとドコモの掲載ページを取得できていないため、完全な攻撃検体との照合はできていません。RFC本文は公開ミラーで確認しました。コンソール手順は顧客テナントでは実行していません。比較例と独自の図は説明用であり、実際の事案の証拠ではありません。元記事の図や製品画面はコピーしていません。
更新履歴： 2026年10月19日 — 初版公開。同日、報告された流れを中心に全面改稿し、比較例を追加、運用手順を短く整理し、カバーのキャプションを削除しました。