SPFやDKIMが失敗していれば、フィッシングと断定できますか？

断定できません。転送やメーリングリスト、設定の不備によって、正規のメールが失敗する場合もあります。認証結果の一つだけで決めず、リンク先、返信先、依頼の内容、別経路での本人確認を合わせて判断します。

リンク先のURLに自社のドメイン名が含まれていれば、正規のサイトですか？

正規とは限りません。ホスト名のうち、どこが登録ドメインかを確認します。自社のドメイン名がサブドメインの一部として含まれているだけで、実際には別の登録ドメインの配下にある場合があります。

症例演習：フィッシングメールとサイトを見破る

フィッシングの判断は、自然な文章、差出人名、認証結果の一つだけではできません。この演習では、受信側が確認したヘッダ、リンク先、依頼内容、別経路の確認を合わせ、開かずに報告する判断を学びます。

すべて合成の証跡です。ドメインは予約されたexample.com・example.netの配下、IPは文書用TEST-NETを使います。実在の対象へアクセスする必要はありません。

状況設定

状況設定情シス担当者

自社の正規ドメインはexample.comです。経理担当者から、同僚の伊藤さんを名乗るメールの相談がありました。事前に登録した社内連絡先で伊藤さんへ確認すると「送っていない」と回答しました。受信者はリンクを開かず、返信もしていません。

自社の受信サーバーからヘッダ付き原本を取得しました。以下のAuthentication-Resultsは、自社サーバーが評価・付与したことを確認できた、という演習上の前提です。

証跡の提示

text 自社受信サーバーから取得したヘッダ（合成）

1	Return-Path: <[email protected]>
2	Received: from mail.examp1e.example.net (unknown [203.0.113.77])
3	by mx.example.com; Mon, 20 Jul 2026 09:14:01 +0900
4	Authentication-Results: mx.example.com;
5	spf=fail smtp.mailfrom=examp1e.example.net;
6	dkim=fail header.d=examp1e.example.net;
7	dmarc=fail header.from=example.com
8	From: "伊藤健（経理部）" <[email protected]>
9	Reply-To: [email protected]
10	To: [email protected]
11	Subject: 【至急】請求書の支払い期限に関する確認依頼

text 本文の抜粋（合成・無害化URL）

1	本日中に口座情報を確認してください。
2	請求書確認ポータル：
3	hxxps://billing.example[.]com.account-verify.examp1e.example[.]net/invoice
4	確認が取れない場合、取引を停止します。

認証結果をどう判断するか

Q1 SPF・DKIM・DMARCのfailだけで、攻撃だと断定できるか？

他の証跡と照合する

断定できません。SPFは送信元IPとエンベロープ送信元の許可、DKIMは署名の検証、DMARCはFromとのアライメントを含めた評価です。転送やメーリングリスト、設定不備で正規のメールが失敗する場合もあります。

この例は三つともfailですが、本人が送っていないという別経路の回答や不自然な依頼と合わせて判断します。逆にpassでも、侵害された正規アカウントや悪意ある別ドメインからのメールはあり得ます。

リンク先の構造をどう読むか

Q2 本文のリンクは、自社のexample.comへ向いているか？

自社ドメインではない

ホスト名は「billing.example.com.account-verify.examp1e.example.net」です。この合成例の登録ドメインはexample.netで、example.comという文字列は左側のサブドメインに含まれるだけです。自社ドメインではありません。

「右から常に二つのラベルを取る」と一般化しないでください。co.jpなど、登録ドメインの境界はサフィックスによって異なります。例では綴りを似せたexamp1eというラベルも含みますが、見た目よりホスト全体と正規連絡先の照合が重要です。

URLを開いて確認しません。コピーする場合も、誤ってブラウザで開かない操作を選び、所定の報告先で扱ってください。

判定と次の指示

Q3 この演習の状況では、どの対応を取るべきか？

フィッシングとして報告・対応

本人が送信を否定し、正規でないリンク先、異なる返信先、認証失敗、急がせる依頼が重なっています。演習ではフィッシングとして報告・対応します。ただし、実際の被害や侵害の成功まで確認されたわけではありません。

受信者には、開かない・返信しない・添付を実行しないことを伝えます。原本を保持し、専用の報告ボタンや所定窓口へ連絡します。組織が指示する原本提出と、同僚への広い転送は区別してください。

認証結果の信頼境界とアライメント

Authentication-Resultsというヘッダ名があるだけでは信頼できません。自社の受信側で付与された結果と、外部から持ち込まれたヘッダを区別します。RFC 8601は、この信頼境界を扱っています。

DMARCのpassには、SPFかDKIMの少なくとも一方の認証成功と、その識別子のFromとのアライメントが必要です。両方failなのにアライメントだけでpassする、という説明は誤りです。RFC 9989で仕組みを確認できます。

認証結果だけで、配送先フォルダーや依頼の正当性まで断定しません。Return-Path・From・Reply-Toが異なるのも、正規の配信サービスでは起こり得ます。既知の取引経路と照合します。

受信側の証跡
ヘッダの付与元、認証結果、受信時刻を確認。
依頼の確認
リンク先、返信先、業務上の必要性を照合。
報告
既知の窓口へ連絡し、原本と操作を記録。

メール認証の結果は、一つの証跡として依頼・連絡先と照合する。

初動チェックリスト・記録・やってはいけないこと

原本、受信時刻、対象者、別経路の確認結果、利用者の操作を記録する。
同様のメールが届いていないか、権限のある担当者がメールログを確認する。
遮断は、正規の配信・共有インフラへの影響を管理者が確認して判断する。
入力・承認・ファイル実行があった場合は、アカウントと端末の確認へ進める。
証跡保全と、必要なセッション失効・封じ込めは並行して判断する。

メール内の連絡先へ確認の返信を送らず、正規の窓口を使います。証跡を先に消したり、単独のIPを根拠に広範な遮断を行ったりしません。秘密情報や回復コードを報告文へ含めないでください。

フィッシングメール点検、報告プレイブック、メール認証の学習、ヘッダ解析演習へ進めます。

公式情報・参考情報

RFC 8601: Authentication-Results — 認証結果と信頼境界
RFC 9989: DMARC — 認証とアライメント
DMARC.org — メール認証の解説
MITRE ATT&CK: T1566 — フィッシングの分類
CISA: Avoiding Social Engineering and Phishing Attacks — 確認・報告の指針