Intune のコンプライアンスポリシーで「非準拠になったら通知メールを送る」を設定したのに、プレビュー送信は成功して届く一方で、対象ユーザーや追加の宛先には届かない（または届くまでに非常に時間がかかる）──この症状は、Intune 側の設定だけでなく、非準拠判定のタイミング、受信側の迷惑メール判定、Exchange Online（EOP）やゲートウェイでの隔離など、複数レイヤーで発生します。ここでは原因の候補と、効率よく切り分けるための実務的な手順を整理します。
症状を正しく捉える：プレビュー送信と「実運用通知」は別物
まず前提として、Intune の「プレビュー送信（テスト送信）」が届くことと、実際にデバイスが非準拠になったときに飛ぶ通知が届くことは、同じように見えて挙動が一致しないケースがあります。切り分けの最初の一歩は「何が違うのか」を把握することです。
| 観点 | プレビュー送信 | 実運用（非準拠通知） |
|---|---|---|
| 発生条件 | 管理者が任意に実行 | デバイスが非準拠になり、かつアクション条件を満たした時 |
| 対象の判定 | 判定ロジックを経由しない（あくまでメール送信の疎通確認になりがち） | コンプライアンスポリシーの評価・割り当て・スコープが絡む |
| 遅延の起きやすさ | 比較的すぐ届くことが多い | 評価タイミングやバックグラウンド処理で遅延が出やすい |
| 詰まりやすいポイント | 宛先の入力ミス、受信側の迷惑メール判定 | アクション設定、対象ユーザーのメールボックス有無、DLの外部送信拒否、隔離/拒否、遅延 |
| 切り分けの要点 | 「送れる」ことの確認 | 「非準拠→アクション→配信」までのどこで止まるか確認 |
結論として、プレビューが届いても安心しすぎないのが重要です。実運用通知は「非準拠判定」と「アクション実行」の仕組みに依存するため、別の観点で確認が必要になります。
最短で原因に近づく切り分け方：「Intuneから出ていない」か「途中で止まっている」か
「届かない」を深掘りすると、原因は大きく2つに分かれます。
- そもそも Intune が通知メールを送る条件に到達していない（非準拠判定・割り当て・アクション設定の問題）
- Intune は送っているが、メール経路のどこかで止まっている／遅延している（EOP/ゲートウェイ/ルール/迷惑メール/隔離）
この2択を早く決めるために、次の順番で確認すると迷いが減ります。
| 手順 | 確認すること | 目的 | 次の分岐 |
|---|---|---|---|
| 1 | 対象デバイスが本当に「非準拠」か（評価済みか） | 通知のトリガーが成立しているか確認 | 非準拠でない→Intune側を見直す |
| 2 | コンプライアンスポリシーと「非準拠時のアクション」設定 | 送信条件（いつ送るか・誰に送るか）を確認 | アクション未設定/遅い→設定を修正 |
| 3 | 宛先（ユーザー/追加受信者）の受信要件 | 受信できるメールボックス/グループか確認 | DL等が外部拒否→許可設定へ |
| 4 | メッセージトレース（配信ログ） | 「送られたか」「どこで止まったか」を確定 | 拒否/隔離→EOP等の対策 |
| 5 | 遅延の可能性（時間軸の確認） | 即時性の期待値を調整し、誤判定を防ぐ | 遅延が常態化→運用・設計見直し |
Intune側の基本：通知が飛ぶまでの流れを押さえる
実運用通知が届かないとき、最も多いのは「設定したつもりでも、通知の条件が成立していない」パターンです。ざっくりした流れは次の通りです。
- デバイスがチェックインし、コンプライアンスポリシーが評価される
- 結果が「非準拠」になる（または猶予期間/状態遷移が進む）
- 「非準拠時のアクション」が、指定したタイミングで実行される（メール送信など）
- メールがテナントのメール経路（EOP/ゲートウェイ）を通り受信者へ配信される
つまり、非準拠判定・アクション実行・メール配信のどこかで止まっている可能性があります。以降は各ポイントでの具体的な確認方法です。
宛先・通知設定の確認：入力ミスだけでなく「受信できる宛先か」を見る
メールアドレスの形式・入力ルールを疑う
- 通知設定に入れたメールアドレスに誤字、全角/半角の混在、余計な空白がないか
- 区切り文字（カンマ）が全角「，」になっていないか（入力欄によっては想定外の扱いになることがあります）
- 追加の宛先に複数入れている場合、どれか1つでも不正な形式だと全体が失敗する挙動になっていないか（まずは1件だけにして再テスト）
配布リスト（DL）や共有メールボックスを宛先にする場合の落とし穴
「対象ユーザーには届かない」のと同じくらい多いのが「追加の宛先（DL/共有）に届かない」です。特にDLは設定によって外部送信者を拒否します。
| 宛先の種類 | よくある原因 | 確認ポイント | 対策の方向性 |
|---|---|---|---|
| 配布リスト（Distribution Group） | 外部送信者からの受信を拒否している | 「送信者の認証を必須」「外部送信者を許可」などの設定 | Intune通知が外部扱いになるなら、外部送信許可/特定送信者許可を検討 |
| メール有効なセキュリティグループ | 配信管理（許可送信者）が限定されている | 許可送信者リスト、受信制限 | 許可設定の見直し、検証用に一時的に緩めて切り分け |
| 共有メールボックス | 存在しない/アドレスが別/転送やルールで流れている | メールボックスの実体、エイリアス、受信ルール、転送設定 | まずはルール無効化・転送停止で単純化してテスト |
| 外部メールアドレス | 組織のメールセキュリティで外部宛を制限 | 送信コネクタ、外部送信制御、DLP | セキュリティ方針に沿って例外を検討（安易な常用は避ける） |
ポイント：「管理者のメールボックスには届くのにDLには届かない」場合、DL側の外部送信拒否が当たりやすいです。追加の宛先にDLを使う場合は、まずDLではなく単一の通常ユーザーを追加して届くかを見て、問題の層を分離してください。
本当に非準拠になっているか：状態・評価タイミング・スコープを確認
「非準拠」ではなく「未評価」「不明」のままになっていないか
テストで多いのが、意図した通りに非準拠を作ったつもりでも、実際には評価が走っていない（未評価）/結果が反映されていない（不明）状態です。
- 対象デバイスのコンプライアンス状態がNoncompliantになっているか
- 最終チェックイン時刻が古くないか（端末がオフラインだと評価が進みません）
- ポリシー適用対象のグループにユーザー/デバイスが確実に含まれているか（動的グループの反映遅延も要注意）
割り当ての見落とし：ポリシーとアクションが同じスコープに当たっているか
コンプライアンスポリシーは割り当てられているのに、非準拠時のアクションが期待通り動かない場合は、次を疑います。
- 複数ポリシーが当たっており、どれが非準拠理由になっているか分かっていない
- 「このポリシーに紐づく通知」を設定したつもりが、別ポリシーで非準拠になっている
- 除外グループが効いていて、対象ユーザーが除外されている
実務では、テスト用に対象を最小化した検証グループ（ユーザー1名・デバイス1台）を作り、ポリシーも「検証用1本」に寄せると原因が見えやすくなります。
「非準拠時のアクション」設定の落とし穴：送信タイミングが未来になっていないか
非準拠通知メールは、コンプライアンスポリシーの「非準拠時のアクション」で送信するのが一般的です。ここで特に確認したいのはいつ送る設定になっているかです。
- メール送信アクションが有効になっているか
- 送信タイミングが「非準拠になってからX日後」になっていないか（テストで見落としやすい）
- 猶予期間や「デバイスを非準拠としてマークする」アクションとの順序が不整合になっていないか
| よくある設定ミス | 起きる症状 | 見直しのコツ |
|---|---|---|
| 送信が「1日後」「3日後」などになっている | 数分〜数時間待っても届かない（実はまだ送信予定に達していない） | テスト時は送信を最短にし、検証後に運用値へ戻す |
| 非準拠の原因が別ポリシー | 通知が飛ばない／飛ぶタイミングが想定と違う | 非準拠理由（どのポリシーが原因か）を端末単位で確認 |
| 対象の割り当てがユーザー/デバイスで混乱 | 一部だけ届く、再現性がない | 検証はユーザー1・デバイス1の最小構成で固定 |
| テンプレートは編集したが有効化していない | 既定文が届く/届かないが揺れる | テンプレートの有効状態・言語を確認 |
通知テンプレートのチェック：届かない原因が「本文」側にあることも
通知メールのテンプレートをカスタマイズしている場合、次も確認対象です。
- テンプレートが有効になっているか
- 言語別テンプレートの設定で、対象ユーザーの言語に対応するテンプレートが空になっていないか
- 件名や本文に、迷惑メール判定されやすい要素が増えていないか（過剰な記号、短縮URLの多用、強い煽り文句など）
- 差し込み項目（プレースホルダー）を編集して、意図しない形式になっていないか
テンプレートが原因かを切り分けるには、一時的にシンプルな件名・本文に戻してテストするのが効果的です。HTMLを凝りすぎるより、まずは到達性を優先し、届くことを確認してから整えるのが安全です。
受信側の基本チェック：ユーザーに依頼する確認項目を用意しておく
対象ユーザーに「届いていないかも」と言われたとき、闇雲に調べると時間が溶けます。ユーザー向けに、次の確認をテンプレ化しておくと運用が安定します。
| 確認場所 | ユーザーがやること | 意外と多い原因 |
|---|---|---|
| 迷惑メールフォルダー | 該当時間帯で検索（件名/送信者/本文キーワード） | 迷惑メール判定で移動 |
| 「その他」（Focused Inbox） | 受信トレイが「優先/その他」に分かれていないか確認 | 重要度が低いと判定され別タブへ |
| Outlook ルール/自動仕分け | ルール一覧を確認し、一時的に無効化 | 古いルールが予期せぬフォルダーへ |
| 隔離（Quarantine） | 管理者に「隔離の有無」を確認してもらう | EOP/Defender で隔離 |
| 検索 | 「非準拠」「compliance」「Intune」など複数語で検索 | 件名変更や翻訳で見逃し |
ユーザー確認で見つからない場合、次は管理者側で「ログから事実を確定」します。
メッセージトレースで決着をつける：届かない原因の8割はここで見える
「Intuneから出ていないのか」「出たけど止まったのか」を確定させる最短手段が、Exchange の配信ログ（メッセージトレース）です。環境によって画面名は多少変わりますが、考え方は同じです。
メッセージトレースで見るべき情報
- 受信者：対象ユーザー/追加受信者のアドレスで検索
- 時間帯：非準拠になったと思われる時間から十分広めに
- 結果ステータス：配信済み／保留／失敗／隔離 など
- 詳細イベント：どの段階で止まったか（フィルター、ルール、コネクタなど）
| トレース結果の例 | 意味 | 次にやること |
|---|---|---|
| 該当メールが見つからない | 少なくともメール経路（Exchange）には入っていない可能性 | Intune側：非準拠判定・アクション設定・宛先（ユーザーにメールボックスがあるか）を再確認 |
| Failed / Rejected / Bounce | 拒否された | 拒否理由（外部送信拒否、存在しない宛先、ポリシー違反）を確認し、DL/宛先要件を修正 |
| Quarantined | 隔離された | 隔離理由を確認し、許可リストやポリシー調整を検討（安易な全面回避は避ける） |
| Delivered だがユーザーが見つけられない | 配信自体は成功 | ユーザー側ルール/フォルダー/アーカイブ/優先受信などを再確認 |
| Pending / Deferred（保留・遅延） | 配信待ち、または遅延中 | メールセキュリティ/ゲートウェイのキュー、サービス側遅延、混雑を疑う |
許可リスト（ホワイトリスト）を使う場合の注意点
「隔離される」「迷惑メール判定される」場合、許可リスト追加は有効ですが、やり方を誤るとセキュリティが下がります。
- ドメイン丸ごと許可より、可能なら送信者・条件を限定する
- テストは短期間の例外で実施し、恒久対応は根本原因（判定条件）を見て決める
- メールフロールールで SCL を強制的に下げる等の回避策は、運用チームと合意してから
遅延が起きる理由：失敗と決めつける前に「時間軸」を記録する
非準拠通知はリアルタイム配信を保証する仕組みではなく、端末のチェックインやサービス側の処理タイミングに左右されます。プレビューはすぐ届くのに実通知が遅いのは、この差が原因になりがちです。
遅延が発生しやすい場面
- 端末のチェックインが遅い（スリープ・オフライン・ネットワーク制限）
- ポリシーの評価からアクション実行までがバックグラウンド処理になっている
- 大規模環境での処理混雑や一時的なサービス負荷
- メールセキュリティ側の隔離・保留（スキャン待ち）
遅延が疑わしい場合は、次の「時系列ログ」を取っておくと、原因の層を特定しやすくなります。
| 記録する項目 | 例 | 分かること |
|---|---|---|
| 端末の最終チェックイン時刻 | Intune上の「Last check-in」 | 評価がそもそも進んでいるか |
| 非準拠になった時刻の目安 | 状態が Noncompliant に変わったタイミング | トリガー成立の時刻 |
| アクション設定（送信タイミング） | 非準拠から0日/1日など | 「まだ送信条件に達していない」を排除 |
| メッセージトレースで最初に見えた時刻 | Trace上の受信時刻 | Intune→メール経路に載った時点 |
| ユーザーの受信時刻 | 受信トレイに出た時刻 | 配信遅延がメール経路/クライアントどちらか |
この時系列が取れると、「Intune側の遅延」なのか「メール経路の遅延」なのかがはっきりします。
別のメールアカウントでテストする：送信元ではなく「受信側」を変えて検証する
「別のアカウントでテスト」と言われた場合、ポイントは送信元を変えるのではなく、受信側（宛先）を変えて挙動差を見ることです。Intune側で送信元アドレスを自由に変える運用は基本的にできません。
おすすめのテスト方法
- 追加受信者を単一の通常ユーザー（テスト用）にして送る（DL/共有を一旦外す）
- 対象ユーザーもテスト用に固定し、端末1台で再現させる
- 必要なら、組織のルールに従った上で外部宛（テスト用アドレス）も使い、メール経路の違いを比較する
これで「特定ユーザーだけ届かない」「DLだけ届かない」「特定ドメインだけ遅い」など、偏りが見えます。偏りが見えたら、その層（ユーザーのメールボックス、DL設定、ゲートウェイ方針）を重点的に見直すのが最短です。
ユーザー属性・ライセンスの観点：メールが届く前提条件を確認する
プレビュー送信が届くのに実運用通知が届かない場合、優先度は高くありませんが、次の条件も押さえておくと詰まりを避けられます。
- 対象ユーザーに実体のあるメールボックスがあるか（メールを受け取れる状態か）
- ユーザーのメールアドレス（主SMTP）が想定通りか（UPNとメールが一致していない環境では勘違いが起きやすい）
- 共有メールボックスやグループ宛の場合、受信制限・配信管理でブロックされていないか
- 検証対象ユーザーに必要なライセンスが付与されているか（端末管理・メールボックス）
特に「対象ユーザーがメールを受け取れない属性/状態」だと、Intuneの設定が正しくても結果的に届きません。メッセージトレースでバウンスや拒否理由が出ている場合は、ここが原因になりやすいです。
実務で使えるチェックシート：上から順に潰すだけで迷わない
最後に、現場でそのまま使えるチェックシートをまとめます。トラブル対応時は「確認順」を固定すると、対応品質がぶれにくくなります。
| チェック項目 | OKの基準 | NGだった場合 |
|---|---|---|
| 端末が非準拠になっている | 対象端末が Noncompliant、最終チェックインが新しい | 同期・チェックイン条件を見直し、テスト条件を作り直す |
| ポリシー割り当てが正しい | 対象ユーザー/端末が含まれ、除外されていない | 検証グループを最小化して再割り当て |
| 非準拠時のアクションが正しい | メール送信アクションが有効、送信タイミングが意図通り | テスト時は最短にし、届くことを確認してから運用値へ |
| 宛先が受信可能 | ユーザーのメールボックスが存在、DLが外部受信を拒否していない | DL/共有を外し単一宛先でテスト、DL設定を調整 |
| メッセージトレースで追える | 配信ログに記録され、Delivered/Quarantined等が判明 | 該当なしならIntune側へ戻る、隔離/拒否ならメール側で対策 |
| 遅延の可能性を評価 | 時系列が取れ、どの層の遅延か説明できる | 待機時間を含めた検証設計へ変更、メール経路の保留/隔離を確認 |
まとめ：原因は「設定ミス」よりも「層の違い」を見落としていることが多い
- プレビュー送信は届いても、実運用通知は非準拠判定とアクション条件に依存する
- まずは「非準拠になっているか」「送信タイミングが未来になっていないか」を確認する
- DLや共有宛は、外部送信拒否・配信管理で止まりやすいので単一宛先で切り分ける
- 最短で結論が出るのはメッセージトレース（送られた/止まった/隔離された/遅延中が分かる）
- 遅延は起こり得るため、テストでは時間軸の記録を取り、失敗と誤判定しない
コメント