XEROTTA
セキュリティ公開日:

Microsoft 365のなりすましメールを検疫する

執筆:XEROTTA編集部

ITサービス・業務改善の実務チーム

Microsoft 365のなりすましメールを検疫する

Conclusion

この記事の結論

対象者に適用されるポリシーを特定し、なりすまし判定時の処理と検疫ポリシーを設定します。通知と解放権限を確認し、設定の読み戻しに加えて、実メールの判定・検疫・正常配送を別に検証します。

このガイドの対象

Microsoft 365のメール保護を管理する担当者。なりすましと判定されたメールを迷惑メールフォルダーではなく検疫へ送る場合に、適用範囲と利用者の確認手順を整理するためのガイドです。

検疫は、疑わしいメールを通常の受信箱から分離し、判定内容を確認して扱う仕組みです。誤判定された正規のメールへの対応も含めて設計します。

対応の流れ

対応手順を図で確認
  1. 01検出の種類と利用できる機能を確認する
  2. 02対象者とポリシーの優先順位を照合する
  3. 03検疫・通知・解放の運用を設定する
  4. 04設定の読み戻しと実メールの動作を確認する

確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認

詳しい手順

1. どの判定を変更するか決める

「なりすまし」という表現には、送信元の偽装を検出するスプーフィングと、人物名・類似ドメインなどを使う偽装が含まれます。Microsoft 365では、利用できる検出機能が契約によって異なります。スプーフィング保護と、Defender for Office 365のユーザー・ドメイン偽装保護を区別してください。

類似ドメインからのメールは、そのドメインのSPF・DKIM・DMARCを通過する場合もあります。認証の成功だけで送信者の意図や本文の安全性を判断しません。Microsoftのフィッシング対策ポリシー

変更対象を、検出機能、検出時の処理、適用する受信者の三つに分けて記録します。迷惑メール対策側のフィッシング判定など、別の設定まで一括して変更しないようにします。

2. 実際に適用されるポリシーを特定する

対象の受信者が、StrictまたはStandardのプリセット、カスタム、既定の各ポリシーに含まれているか確認します。同じ種類のポリシーでは、先に適用されるものが使われ、複数の設定が自動的に合成されるわけではありません。

StrictやStandardのプリセットはカスタムポリシーより優先されます。カスタムの優先度を0にしても、プリセットより先にはなりません。Microsoftの適用順序

例外が必要な場合は、試行対象を限定し、現在有効な保護と変更後の保護を比較します。適用先だけを移して、必要な検出やSafe Links・Safe Attachmentsなどの保護が抜けないようにします。変更前の設定と戻し方も保存してください。

3. 検疫と通知・解放の権限を分けて設定する

脅威対策ポリシーは、何を検出してどの処理へ送るかを決めます。検疫ポリシーは、利用者が検疫されたメールをどう確認できるか、通知を受け取るか、解放や解放依頼ができるかを決めます。Microsoftの検疫ポリシー

  • なりすまし判定時の処理を検疫にする。
  • 対応する検疫ポリシーの名称と利用者の権限を確認する。
  • 通知の有無と頻度、通知を確認する担当者を決める。
  • 保持期間と、誤判定時の連絡先・確認手順を記録する。

直接解放と、管理者への解放依頼は別の権限です。また、マルウェアや高確度フィッシングなどには、検疫ポリシーで権限を与えても利用者が直接解放できない種類があります。通知を有効にしただけで、すべてのメールを本人が取り出せるとは判断しません。

4. 設定を読み戻して差分を確認する

保存後に管理画面や管理用の取得結果を開き直し、対象受信者、除外、優先順位、検出時の処理、検疫ポリシーを確認します。変更前との差分を取り、予定した項目だけが変わっていることを確認してください。

画面上で「検疫」と表示されることは設定の証拠です。その時点で、メールが実際に検疫されたことや通知が届いたことまで証明したことにはなりません。

5. 実メールの判定と運用を確認する

承認された検証方法と対象メールを使い、検疫一覧の判定理由、適用された処理、受信者、時刻を照合します。通知の受信は別に確認し、利用者が許可された範囲で確認・解放依頼を実行できるかを確かめます。危険な添付ファイルや実際の攻撃メールを安易に開いて試さないでください。

正常な社外メールが通常どおり届くかも確認します。必要なメールが検疫された場合は、表示名だけで解放せず、送信元、業務上の経緯、判定理由を確認し、必要に応じて別の連絡手段で送信者へ照会します。

完了の確認

対象者へ意図したポリシーが適用され、他の受信者の保護を維持できていることを確認します。実メールの検疫、通知受信、解放依頼、正常メールの配送について、それぞれ実施した試験と結果を残してください。

XEROTTAでは2026年10月6日に、対象を限定してスプーフィング判定時の検疫と通知に関する設定を見直し、保存後の設定を照合しました。この対応で実施した設定の照合と、実メールによる検疫・通知配送の試験は別です。当該対応では後者の試験は実施していません。

うまく進まない場合

変更が効かない場合は、対象者の条件と除外、プリセットの優先、実際の検出理由を照合します。

通知が来ない場合は、検疫対象のメールが実際に存在するか、対応する検疫ポリシー、通知設定と頻度、受信側の振り分けを確認します。

必要なメールが止まる場合は、個別の判定を調査します。調査のために組織全体の保護を無効にしたり、広範囲な許可を追加したりせず、対象と期間を限定して対応します。

参考情報

関連するナレッジ

メール認証に関わるDNSの移行も行う場合は、Route 53へDNSを移行するで、Microsoft 365を含む移行前後の確認を整理しています。

よくある質問

Aいいえ。StrictやStandardのプリセットは、カスタムポリシーより優先されます。対象者が含まれるポリシーと除外条件を確認し、必要な保護が維持される構成を決めてください。

Aできません。検疫ポリシーの権限と、メールの検出理由によって異なります。直接解放と管理者への解放依頼は別の操作で、マルウェアや高確度フィッシングなどには本人が直接解放できない種類があります。

A設定の有効化だけでは完了しません。実際の検疫結果と判定理由、利用者への通知受信、許可された確認・解放依頼の操作、正常メールの配送を分けて検証します。

関連サービス

関連する支援例・参考費用

Contact

ITと業務の課題、
まずはお聞かせください。

「何から手を付けるべきか分からない」という段階からのご相談を歓迎します。現状の整理から、貴社に合った進め方をご提案します。