Microsoft Defender for Office 365 の Advanced Delivery（フィッシング シミュレーション）を設定したのに、GoPhish から送った訓練メールが「High confidence phishing（高確信フィッシング）」として隔離されてしまう――そんな状況は、ルールの入れ方ではなく「Microsoft 365 が何を見ているか」とのズレで起こります。本記事では、その仕組みと具体的なチェック手順を、ヘッダー解析を軸に分かりやすく解説します。
事象の整理：GoPhish 訓練メールが「高確信フィッシング」で隔離される
まず、よくある相談内容を整理します。
- GoPhish サーバーから社内ユーザー宛にフィッシング訓練メールを送信
- Microsoft Defender for Office 365 の Advanced Delivery > Phishing simulation に
- 送信ドメイン（訓練用ドメイン）
- 送信 IP（GoPhish サーバー or ベンダーの送信 IP）
- SPF / DKIM / DMARC も一応は
passしている - しかしユーザーの受信トレイには届かず、「High confidence phishing（高確信フィッシング）」として隔離される
- セーフセンダー、Tenant Allow/Block List（TAL）、メール フロールール（ETR）で許可しても状況は変わらない
この状態になる最大の理由は、
- Advanced Delivery の一致条件（ドメイン + 送信 IP）が 実際に Microsoft 365 が認識している値とずれている
- あるいは Advanced Delivery の対象外ルーティング になっている
です。単なる「ホワイトリスト不足」ではなく、設計上わざと許可が無視されるのがポイントになります。
前提知識：Advanced Delivery と Secure by Default の関係
Advanced Delivery は何をしているのか
Advanced Delivery（Phishing simulation タブ）は、特定の送信元からのメールを「フィッシング訓練」として扱い、スパム／フィッシング判定をスキップするための仕組みです。Microsoft Learn では以下のように定義されています。
- 設定に必要な情報
- Domain
- SMTP 通信で使われる MAIL FROM（
5321.MailFrom / smtp.mailfrom） のドメイン - または DKIM 署名のドメイン（
header.d）
- SMTP 通信で使われる MAIL FROM（
- Sending IP
- 送信元 IP（単一 / 範囲 / CIDR いずれか）
- （任意）メール以外の訓練向け Simulation URLs to allow（Teams メッセージや Office 文書内リンクなど）
- Domain
- 少なくとも 1 つの Domain と 1 つの Sending IP が一致すれば、訓練メールとして扱われる
- Domain と IP の間の「組み合わせ」は管理されない（どの Domain とどの IP のペアであっても良い）
このとき、該当するメールは内部的に 「System override: Phishing simulation」 として扱われ、Threat Explorer やレポートでフィルタ可能です。
Secure by Default と「許可設定が無視される」理由
一方で Microsoft 365 には Secure by Default という考え方があり、
- マルウェア
- High confidence phishing（高確信フィッシング）
と判定されたメールについては、以下のような許可設定は無視されます。
- Outlook のセーフセンダー / セーフドメイン
- アンチスパム ポリシーの Allowed sender / Allowed domain
- Connection filter の IP Allow List
- メール フロールール（SCL を下げる / Bypass spam filtering など）
つまり、「高確信フィッシングで隔離されているメール」を通すために使える正式な手段は、ほぼ Advanced Delivery（または SecOps mailbox override）だけと考えた方が安全です。
旧情報：「カスタムヘッダーで許可」は現行仕様では使わない
以前は「特定のカスタムヘッダーが付いたメールは SCL:-1 にする」など、ヘッダーベースのメール フロールールで訓練メールを通す手法がよく紹介されていました。しかし、現在の Microsoft Learn の公式手順では、非 Microsoft 製フィッシング シミュレーションの許可は Advanced Delivery で行う前提になっており、ヘッダー条件は出てきません。
そのため、「カスタムヘッダーを付けているから大丈夫なはず」と考えるのは NG です。ドメインと送信 IP がズレていれば、容赦なく高確信フィッシングとして隔離されます。
原因候補の全体像
まずは「どこでズレやすいか」を俯瞰しておきましょう。
| 症状 | 主な原因候補 | 確認するポイント | 対処の方向性 |
|---|---|---|---|
| 常に高確信フィッシングで隔離 | Advanced Delivery の Domain / Sending IP が実際の値と不一致 | Authentication-Results と X-Forefront-Antispam-Report の CIP / smtp.mailfrom / header.d | ヘッダーに出ているドメイン・IP をそのまま Advanced Delivery に登録し直す |
| 第三者ゲートウェイ経由だと隔離、直送だと成功 | MX が Microsoft 365 以外を向いており、ゲートウェイの IP が評価されている | CIP がゲートウェイ IP になっていないか | Enhanced Filtering for Connectors（スキップリスティング）で本来の送信元 IP を評価させる |
| 社内の Exchange 経由にすると効かない | DIR:INT（内部）扱いになり、Advanced Delivery 非対応ルートになっている | DIR:INT になっていないか | 訓練メールだけ MX を直接 Microsoft 365 に向ける / 認証しない専用 Receive Connector を用意 |
| 許可リストや ETR を追加しても隔離されたまま | Secure by Default により高確信フィッシングへのオーバーライドが無効 | 隔離理由が「High confidence phishing」になっているか | 許可リストではなく Advanced Delivery で制御する |
| SPF / DKIM / DMARC は pass だが隔離される | 認証はあくまで要素の一部であり、訓練と認識されていない | compauth、spf、dkim、dmarc の値 | 認証は前提条件として整えつつ、Advanced Delivery のマッチ条件を優先的に見直す |
ステップバイステップでの切り分けと解決
ステップ 1：ヘッダーから「Microsoft 365 が見ている送信元」を把握する
最初にやるべきことは、隔離された訓練メールの メッセージヘッダーを取得することです。Microsoft はヘッダーのうち、特に次の 3 つを重視するよう案内しています。
Authentication-Results（SPF / DKIM / DMARC / compauth）X-Forefront-Antispam-Report（CIP / DIR / SCL / SFV / SFTY など）X-Microsoft-Antispam（追加のスパム / フィッシング情報）
典型的なヘッダーの一部は次のような形になります。
Authentication-Results: spf=pass (sender IP is 203.0.113.10)
smtp.mailfrom=training.example.jp;
dkim=pass (signature was verified) header.d=phish.example.jp;
dmarc=pass action=none header.from=phish.example.jp;
compauth=pass reason=100
X-Forefront-Antispam-Report: CIP:203.0.113.10; CTRY:JP; DIR:INB;
SCL:9; SFV:SPM; SFTY:9.25; CAT:HPHISH; ...
ここで特に重要なのは次の 4 点です。
| フィールド | 意味 | Advanced Delivery との関係 |
|---|---|---|
CIP | 接続元 IP（Connecting IP Address） | Sending IP と一致している必要がある |
smtp.mailfrom | エンベロープ From（MAIL FROM / 5321.MailFrom） | Domain に指定できる候補の 1 つ |
header.d | DKIM 署名のドメイン | Domain に指定できるもう 1 つの候補 |
header.from | ユーザーに見える From アドレスのドメイン（5322.From） | DMARC と整合しているかどうかに使われるが、 Advanced Delivery の Domain には直接は使わない |
この 4 つを控えてから、Advanced Delivery の設定画面と見比べていきます。
ステップ 2：Domain 条件（送信ドメイン）の再確認
Advanced Delivery の Domain には、次のいずれか（必要であれば両方）を登録します。
Authentication-Resultsのsmtp.mailfrom=◯◯◯のドメインAuthentication-Resultsのdkim=... header.d=◯◯◯のドメイン
よくある間違いは、
- 画面上に表示される From アドレス（
header.from）のドメインだけを登録してしまう - GoPhish の設定を変えた結果、
smtp.mailfromのドメインが別の値になっている - DKIM だけ別ドメイン（例：
gophish.example.net）で署名しているのに、そのドメインを登録していない
というパターンです。
おすすめの確認手順は次のとおりです。
- 隔離された訓練メールのヘッダーから
Authentication-Resultsをコピー smtp.mailfrom=行のドメインとheader.d=行のドメインを探す- Advanced Delivery の Domain に、少なくともどちらか一方（安全のために両方）を登録する
- 似たスペル・別サブドメイン（
phish.example.comとphishing.example.com）になっていないかをダブルチェック
特に、GoPhish 側で「Envelope Sender」と「表示用 From」を分けている場合、画面上の From ドメインと smtp.mailfrom のドメインが異なることがよくあります。必ずヘッダー上の値で確認しましょう。
ステップ 3：Sending IP 条件（送信 IP）の再確認
次に、Advanced Delivery の Sending IP が正しいかを確認します。
Advanced Delivery では、「Authentication-Results ヘッダーに記録された送信元 IP」 が、設定した Sending IP に一致する必要があります。MX が Microsoft 365 以外（オンプレミス Exchange やサードパーティ製ゲートウェイ）を向いている場合、ヘッダーの IP が異なることがあるため、公式ドキュメントでも注意喚起されています。
確認ポイントは次のとおりです。
X-Forefront-Antispam-ReportのCIP:（Connecting IP）Authentication-Resultsのspf=pass (sender IP is ...)の IP
これらの IP アドレスが、Advanced Delivery に登録した Sending IP（またはその範囲 / CIDR）と一致していることを確認してください。
| メール経路 | ヘッダーの CIP | Advanced Delivery に登録すべき IP | 補足 |
|---|---|---|---|
| GoPhish サーバー → Microsoft 365 MX（直送） | GoPhish サーバーのグローバル IP | そのグローバル IP | 最もシンプルでトラブルが少ない構成 |
| GoPhish → サードパーティ ゲートウェイ → Microsoft 365 | ゲートウェイの IP | 原則は GoPhish の IP を登録したいが、そのためには Enhanced Filtering が必要 | Enhanced Filtering for Connectors（スキップリスティング）を有効化し、元の送信 IP を評価させる |
| インターネット → Microsoft 365 → オンプレ Exchange → Microsoft 365 | 多くの場合オンプレの IP | Advanced Delivery 非対応ルート（後述） | このルートは設計上サポートされないため、経路の見直しが必要 |
もし CIP が「思っていた IP」と違う 場合は、次を検討します。
- テナントの MX レコードを Microsoft 365 へ直接向ける
- やむを得ずサードパーティ ゲートウェイを挟むなら、Enhanced Filtering for Connectors を使って Microsoft 側に「本来の送信元 IP」を認識させる
ステップ 4：メール経路（ルーティング）が Advanced Delivery 対象外になっていないか
Advanced Delivery には、そもそも仕組みとして対応していないメール経路が存在します。公式ドキュメントで代表例として挙げられているのが、次のような「往復ルーティング」です。
Internet → Microsoft 365 → オンプレ/サードパーティ → Microsoft 365
この場合、Microsoft 365 から見て「どこが本当の送信元なのか」を正しく判定できず、Advanced Delivery で訓練として扱うことができません。
また、同一テナント内送信（DIR:INT） のシミュレーションも注意が必要です。ドキュメントでは、特に次のように記載されています。
- 現在、Advanced Delivery は 内部扱い（
DIR:INT）のフィッシング シミュレーションをサポートしない - Exchange ハイブリッド構成でオンプレサーバーを経由する場合などは、訓練メールが内部メールとして認証されやすい
- 回避策としては、
- 訓練メールだけ 直接 Microsoft 365 の MX（例：
tenant.mail.protection.outlook.com）に配信する - シミュレーション用に 認証しない専用 Receive Connector を用意し、内部扱いにしない
- 訓練メールだけ 直接 Microsoft 365 の MX（例：
ヘッダーの X-Forefront-Antispam-Report にある DIR: の値を確認し、
DIR:INB（Inbound）になっている → Advanced Delivery の対象になり得るDIR:INT（Internal）になっている → 経路の見直しが必要
と判断します。
ステップ 5：Advanced Delivery が適用されているかをヘッダーと Defender で確認
設定を見直した後は、本当に Advanced Delivery による「システム オーバーライド」が効いているかを確認します。
ヘッダー上での確認（SCL / SFV / CAT など）
Microsoft は、X-Forefront-Antispam-Report のうち次の値に注目するよう案内しています。
SCL（Spam Confidence Level）- -1: スパム フィルタリングをスキップ（何らかの設定で許可）
- 0～1: 非スパム
- 5～9: スパム寄り～スパム確定
SFV（Spam Filtering Verdict）SFV:NSPM: 非スパムSFV:SPM: スパムSFV:SKN: スパム フィルタリングをスキップ（SCL -1 等）SFV:SKA: アンチスパム ポリシーの Allowed sender / domain によるスキップ
CAT（カテゴリ）CAT:HPHISHorCAT:HPHSH: 高確信フィッシングCAT:SPM: スパム
おおまかな見方を表にすると次のようになります。
| SCL | SFV | CAT | 状態の目安 |
|---|---|---|---|
| -1 | SKN / SKA / SFE など | （空 or PHSH 等） | 何らかのオーバーライドでフィルタリングがスキップされている（訓練メールなら理想的） |
| 5～9 | SPM | PHSH / HPHISH など | スパムまたはフィッシングとして判定され、Junk / 隔離へ |
| 5～9 | SPM | HPHISH | 高確信フィッシングとして隔離。Secure by Default により許可リスト無効 |
Advanced Delivery が正しく働いている訓練メールであれば、通常は SCL:-1 と SFV:SKN など「スキップ系」の値になり、隔離されずに受信トレイへ届きます。
Defender ポータルでの確認（System override: Phishing simulation）
より分かりやすいのは、Defender ポータルの Threat Explorer / Threat protection status レポートで System override を確認する方法です。公式ドキュメントでは、Advanced Delivery の対象になったメールは以下のように扱われると説明されています。
- Advanced Delivery で許可された訓練メールは、Threat Explorer などで System override source = Phishing simulation として表示される
- SecOps mailbox の場合は System override source = SecOps mailbox となる
- これらは「組織ポリシーにより許可されたメール」として可視化される
したがって、
- Defender ポータル > Email & collaboration > Explorer（または Real-time detections）を開く
- フィルタで System override source = Phishing simulation を選択
- GoPhish から送った訓練メールが表示されるか確認
表示されない場合は、まだ Advanced Delivery の条件にマッチしていないと考えるべきです。
ステップ 6：SPF / DKIM / DMARC を「合格 + 整合」させる
Advanced Delivery の直接の条件は「Domain + Sending IP」ですが、SPF / DKIM / DMARC がきちんと整っていることも非常に重要です。Microsoft は、クラウド環境でのメール保護において、SPF・DKIM・DMARC を組み合わせた認証を強く推奨しています。
SPF のポイント
- SPF レコードには、Microsoft 365 を正規の送信元として示す
include:spf.protection.outlook.comを含める - GoPhish サーバーなど、訓練で使う外部 IP も SPF に明示的に含める（例：
ip4:203.0.113.10） - 最終的には
-all（hard fail）で締めることが推奨
シンプルな構成の例：
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all
DKIM のポイント
- 訓練で使うドメインに対して DKIM を有効化し、From ドメイン（
header.from）と同じ or サブドメインで署名する Authentication-Resultsのdkim=pass header.d=◯◯のドメインが DMARC の From ドメインと整合していることを確認- Microsoft 365 から送るメールについては、Defender ポータルの「Email authentication settings > DKIM」から簡単に有効化できる
DMARC のポイント
DMARC については、Microsoft も 段階的な導入 を推奨しています。
p=noneで開始し、レポートを収集（ruaに集計レポート送付先を指定）- 問題がなければ
p=quarantineに引き上げ、さらにp=rejectへ - 訓練用ドメインについても同様に段階的に適用
例：
v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
SPF / DKIM / DMARC が正しく設定されていても、訓練メールは「中身だけ見れば怪しいメール」です。そのため、認証が pass でも高確信フィッシングになることは十分あり得ます。認証は、あくまで「正しい送信者」だと Defender に理解させるための前提条件と考えましょう。
設定例：GoPhish で独自ドメイン訓練を行う場合のベストプラクティス
ここまでの内容を、具体的な構成例で整理します。
想定構成
- 訓練用ドメイン：
phish-training.example.jp - GoPhish サーバーのグローバル IP：
203.0.113.10 - メール経路：GoPhish → Microsoft 365 MX（
tenant.mail.protection.outlook.com）直送 - From アドレス：
[email protected] - Envelope From（MAIL FROM）：
[email protected]
DNS 側の設定
- SPF
phish-training.example.jp. IN TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all" - DKIM
- GoPhish 側で DKIM を有効化し、
d=phish-training.example.jpで署名 - 対応する公開鍵を DNS に登録
- GoPhish 側で DKIM を有効化し、
- DMARC
_dmarc.phish-training.example.jp. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Advanced Delivery の設定
Defender ポータル > Threat policies > Advanced delivery > Phishing simulation タブで、次のように登録します。
- Domain
phish-training.example.jp（MAIL FROM と DKIM の両方で使うドメイン）
- Sending IP
203.0.113.10
- Simulation URLs to allow
- メール内リンクであれば不要
- Teams や Office 文書などメール以外で訓練する場合だけ登録
テスト送信時に確認したいヘッダーの理想形
再度テスト送信し、次のようなヘッダーになっていれば成功に近い状態です（値はあくまで例）。
Authentication-Results: spf=pass (sender IP is 203.0.113.10)
smtp.mailfrom=phish-training.example.jp;
dkim=pass (signature was verified) header.d=phish-training.example.jp;
dmarc=pass action=none header.from=phish-training.example.jp;
compauth=pass reason=100
X-Forefront-Antispam-Report: CIP:203.0.113.10; CTRY:JP; DIR:INB;
SCL:-1; SFV:SKN; CAT:PHSH; ...
- CIP が 203.0.113.10（GoPhish サーバー）
- smtp.mailfrom / header.d / header.from のドメインが一致
- SCL:-1 & SFV:SKN などスキップ系
- Threat Explorer で System override source = Phishing simulation として表示
これらが揃っていれば、訓練メールはユーザーの受信トレイに配信され、かつ Defender 上では「訓練として許可された」メールとして追跡できる状態になります。
ありがちなつまずきと NG パターン
「Tenant Allow/Block List やセーフセンダーで許可すれば良い」は誤解
高確信フィッシングについては、前述のとおり Secure by Default により許可リストが無視されます。
- TAL の Allow エントリ
- アンチスパム ポリシーの Allowed sender / Allowed domain
- Outlook のセーフセンダー
- IP Allow List やメール フロールール
これらは「通常のスパム」や「誤検知」には有効ですが、高確信フィッシング（High confidence phishing）には効きません。訓練メールを通したい場合は、必ず Advanced Delivery を使いましょう。
「メール フロールールで SCL を -1 にしているのに隔離される」
過去のノウハウでは、「特定のヘッダーを持つメールは SCL:-1 にする」というルールで訓練メールを通す例が多く紹介されていました。しかし、Secure by Default の拡張により、高確信フィッシング判定に対してはメール フロールールのオーバーライドも無視されるようになっています。
そのため、「ルールでは SCL:-1 にしているはずなのに隔離される」といった現象が起きます。これもやはり、Advanced Delivery への移行が推奨されています。
「社内（同一テナント）から送れば簡単に訓練できる」は危険
同じテナント内のユーザーやアプリケーションから訓練メールを送ると、メッセージが DIR:INT（Internal）扱い になりやすく、Advanced Delivery の対象外になります。
この場合、
- 内部メールを丸ごとスキップするような設定を入れてしまい、本物の攻撃メールまですり抜ける
- 訓練メールだけを狙って制御することが難しくなる
といったリスクが高まります。訓練専用の外部ドメインと外部 IP を用意し、外部からのメールとして Microsoft 365 に届ける構成の方が、安全かつトラブルシューティングもしやすくなります。
URL 許可の場所を間違える
訓練メール内の URL についても注意が必要です。Advanced Delivery のドキュメントでは次のように整理されています。
- メール内リンク
- Safe Links によってラップ（書き換え）はされる
- しかし Advanced Delivery が効いていれば ブロックはされない
- メール以外（Teams や Office 文書など）の訓練リンク
- Simulation URLs to allow に登録することで、URL ブロックやアラートを抑制
- Tenant Allow/Block List の URL Allow とは別物として管理される
「Safe Links の URL 許可」や「TAL の URL 許可」に訓練 URL を登録しても、本来 Advanced Delivery 側で制御すべき部分とは別のレイヤー なので、期待通りに動作しないことがあります。訓練 URL については、極力 Advanced Delivery の設定に寄せて管理するのが安全です。
まとめ：最短ルートで問題を解消するための実践フロー
ここまでの内容を、「今まさに GoPhish 訓練が高確信フィッシングで隔離されている」状況からの最短ルートとして整理します。
- 隔離メール 1 通のヘッダーを取得
Authentication-ResultsとX-Forefront-Antispam-ReportをコピーCIP/smtp.mailfrom/header.d/header.from/SCL/SFV/CATをメモ
- Advanced Delivery の Domain をヘッダーと突き合わせ
smtp.mailfromのドメイン、またはheader.dのドメインを そのまま Domain に登録- 表示用 From（
header.from）は目安程度と考える
- Advanced Delivery の Sending IP を CIP と一致させる
CIP:に出ている IP / 範囲 / CIDR を Sending IP に登録- MX が Microsoft 365 以外を向いている場合は、Enhanced Filtering for Connectors も検討
- メール経路を確認し、DIR:INB で届くようにする
- ヘッダーの
DIR:がINBになっているか確認 INTであれば、訓練メールだけでも Microsoft 365 MX への直送を検討
- ヘッダーの
- 再送信し、SCL / SFV / System override を確認
- ヘッダーで SCL:-1 かつ SFV:SKN 等スキップ系になっているかを見る
- Defender ポータルで System override source = Phishing simulation で絞り込み、訓練メールが表示されるか確認
- SPF / DKIM / DMARC を「合格 + 整合」に整える
- SPF に GoPhish IP と
include:spf.protection.outlook.comを含める - DKIM 署名の
header.dが From ドメインと整合するようにする - DMARC は
p=noneから段階的にquarantine/rejectへ
- SPF に GoPhish IP と
最終的には、
- Advanced Delivery で Domain + Sending IP が正しく一致
- メール経路が Advanced Delivery 対応ルート（外部→Microsoft 365）
- Defender 上で 「Phishing simulation」システム オーバーライド として認識
という状態になれば、GoPhish の訓練メールは安定してユーザーの受信トレイに届くようになります。
逆に言えば、許可リストやメール フロールールだけでの対応は限界があり、高確信フィッシングには通用しない、という点さえ押さえておけば、トラブルシューティングの方向性を早い段階で絞り込むことができます。
コメント