Microsoft Defender for Office 365の「User reported settings」は、ユーザーがOutlookから報告したフィッシング、迷惑メール、正常なメールをどこへ送るかを決める重要設定です。結論から言うと、管理者は「Microsoftへ送る」「社内の報告メールボックスへ送る」「両方へ送る」のどれで運用するかを決めたうえで、報告メールボックス、DLP除外、PowerShell上のポリシーとルールの整合性まで確認する必要があります。公式情報では、Exchange Onlineメールボックスを持つMicrosoft 365組織で、ユーザー報告メッセージの送信先を内部メールボックス、Microsoft、またはその両方に構成できるとされています。(Microsoft Learn)
特に注意したいのは、この設定が単なる「報告先メールアドレスの指定」ではないことです。Outlookの組み込み報告ボタン、Microsoft以外の報告ツール、報告前後のポップアップ、ユーザーへの調査結果メール、検疫済みメールからの報告可否まで含むため、設定を誤るとSOCの分析フロー、ユーザー教育、フィッシング対応の初動に影響します。
Microsoft DefenderのUser reported settingsとは
User reported settingsは、Microsoft Defender for Office 365でユーザー報告メッセージの扱いを管理する設定です。対象は、Outlookからユーザーが報告する「フィッシング」「迷惑メール」「迷惑メールではない」などのメッセージです。
管理者は、ユーザーが報告したメールを次のいずれかに送るよう構成できます。
| 送信先 | 向いている運用 | 注意点 |
|---|---|---|
| Microsoftと報告メールボックス | Microsoftの分析もSOCの手元確認も使いたい場合 | 報告メールボックスの管理、DLP除外、容量管理が必要 |
| 報告メールボックスのみ | まず社内で内容を確認し、必要なものだけMicrosoftへ送信したい場合 | 管理者が手動送信しない限りMicrosoft分析に回らない |
| Microsoftのみ | 社内メールボックスで保管せず、Microsoft分析を優先したい場合 | 社内SOCで原本を見たい運用には不向き |
Microsoftに直接送らず、報告メールボックスに集約した場合、管理者はDefenderポータルの［申請］ページにある［ユーザーによる報告］タブから、必要なメッセージを選んでMicrosoftへ手動送信できます。(Microsoft Learn)
管理者が確認すべき主な変更点と影響範囲
2026年5月時点で確認すべきポイントは、User reported settingsが「報告先」「Outlook上のユーザー体験」「管理者レビュー」「サードパーティ報告ツール連携」を横断する設定になっている点です。
| 影響を受ける対象 | 確認すべき内容 |
|---|---|
| エンドユーザー | Outlookの報告ボタン、報告前確認、報告後メッセージ、結果通知メール |
| セキュリティ管理者 | 報告メッセージの送信先、User reportedタブでの確認、手動送信フロー |
| SOC/CSIRT | 報告メールボックスの監視、Microsoft分析との切り分け、AIR連携 |
| Exchange管理者 | 報告メールボックス、DLP除外、Exchange Online PowerShell設定 |
| 開発者・外部ツール管理者 | Microsoft以外の報告ツールで必要なメッセージ形式、ヘッダー、件名プレフィックス |
Defenderポータルでは、［設定］>［メールとコラボレーション］>［ユーザーによる報告設定］から設定します。Outlookで報告されたメッセージの監視が無効の場合、メール報告に関する設定や検疫からの報告機能は構成できません。(Microsoft Learn)
Outlookの組み込み報告ボタンとMicrosoft以外のアドインの違い
User reported settingsでは、Outlookの組み込み［報告］ボタンを使う場合と、Microsoft以外のアドインボタンを使う場合で、選べる設定が異なります。
| 項目 | Outlookの組み込み報告ボタン | Microsoft以外のアドインボタン |
|---|---|---|
| Microsoftのみへ送信 | 選択可能 | 選択不可 |
| Microsoftと報告メールボックスへ送信 | 選択可能 | 選択可能 |
| 報告メールボックスのみへ送信 | 選択可能 | 選択可能 |
| 報告前・報告後のポップアップ | 構成可能 | Defender側では主に報告先・通知設定を管理 |
| ユーザーへの結果メール | 構成可能 | 構成可能 |
| 検疫済みアイテムからの報告 | 構成可能 | 構成可能 |
組み込み報告ボタンでは、ユーザーが報告する前の確認ポップアップ、報告後の成功メッセージ、最大7言語までのカスタムメッセージを設定できます。Microsoft以外のアドインでは「Microsoftのみ」が選べず、報告メールボックス、または報告メールボックスとMicrosoftの組み合わせで運用します。(Microsoft Learn)
実務では、次のように判断すると失敗しにくくなります。
| 状況 | 推奨される考え方 |
|---|---|
| これから標準化する | Outlookの組み込み報告ボタンを優先して検討する |
| 既にサードパーティ報告ボタンを全社展開済み | メッセージ形式要件を満たせるか確認してからDefender連携する |
| SOCが全件を先に確認したい | 報告メールボックスのみ、または両方送信を検討する |
| Microsoftの自動分析を重視したい | Microsoftと報告メールボックス、またはMicrosoftのみを検討する |
報告メールボックスの設定で必ず確認すること
報告メールボックスを使う場合、最初に確認すべきことは「そのメールボックスが通常の保護機能で処理されてしまわないか」です。Microsoftの公式情報では、ユーザー報告メッセージがフィルター処理されずに配信されるよう、報告メールボックスをSecOpsメールボックスとして識別し、DLPを使っている場合はDLPから除外する必要があるとされています。(Microsoft Learn)
特にフィッシングシミュレーションを実施している組織では、報告メールボックスをSecOpsメールボックスとして構成しないと、ユーザー報告メッセージがシミュレーション製品側のトレーニング割り当てを誤ってトリガーする可能性があります。(Microsoft Learn)
報告メールボックスで確認すべき項目は次のとおりです。
| 確認項目 | 理由 |
|---|---|
| Exchange Onlineメールボックスを使う | 配布グループ、外部メールボックス、オンプレミスメールボックスへのルーティングは許可されない |
| SecOpsメールボックスとして登録する | 報告メールが通常のフィルターで処理されるのを避ける |
| DLPから除外する | 調査用メッセージがDLPでブロック・隔離されるのを防ぐ |
| 共有メールボックスの監視体制を決める | 報告だけ集まって分析されない状態を防ぐ |
| 容量と保持期間を決める | 添付付き報告メールが増えると容量を圧迫しやすい |
デフォルトの報告メールボックスはグローバル管理者のExchange Onlineメールボックスです。ただし、組織内の最初のユーザーがOutlookからメッセージを報告するまでは、DefenderポータルやPowerShellの出力に報告メールボックスとして表示されない場合があります。(Microsoft Learn)
Defender for Office 365 Plan 2ではAIR連携も確認する
Defender for Office 365 Plan 2を利用している組織では、ユーザーがフィッシングとして報告したメッセージに対して、自動調査と対応であるAIRが自動的にトリガーされます。AIRの結果に応じて、フィッシングまたはマルウェア、迷惑メール、脅威なしといった結果通知をユーザーへ送信する設定も利用できます。(Microsoft Learn)
この機能を有効にする場合は、単に「便利だからオン」にするのではなく、ユーザーに届く通知文面を確認してください。たとえば、ユーザーが本物のフィッシングを報告した後に何が起きたのか分からないと、次回以降の報告率が下がる可能性があります。反対に、通知が多すぎると「Defenderからのメールもまた通知」と見なされ、読まれなくなります。
おすすめは、次の3パターンで文面を分けることです。
| 結果 | ユーザー向け文面の方向性 |
|---|---|
| フィッシングまたはマルウェア | 報告が有効だったこと、今後も不審メールを報告してよいことを伝える |
| 迷惑メール | 危険度は限定的だが、報告により分類精度向上に役立つことを伝える |
| 脅威なし | 誤報を責めず、迷ったら報告してよいことを明記する |
PowerShellで確認すべきポリシーとルール
User reported settingsは、DefenderポータルだけでなくExchange Online PowerShellでも管理できます。基本になるのは、レポート提出ポリシーとレポート提出ルールです。公式情報では、レポート提出ポリシーがOutlookでの報告、Microsoftへの送信、報告メールボックスへの送信などを管理し、レポート提出ルールが報告メールボックスのメールアドレスを指定すると説明されています。(Microsoft Learn)
まず、現在の状態を確認します。
Get-ReportSubmissionPolicy
Get-ReportSubmissionRuleポリシーとルールをまとめて確認したい場合は、次のように実行できます。
Write-Output -InputObject `r`n,"Report Submission Policy",("-"*79)
Get-ReportSubmissionPolicy
Write-Output -InputObject `r`n,"Report Submission Rule",("-"*79)
Get-ReportSubmissionRule注意点は、User reported settingsページを一度も開いたことがない場合、ポリシーもルールも存在しないことがある点です。初めてページを開くと、設定を変更しなくてもDefaultReportSubmissionPolicyが作成され、報告メールボックスを指定して保存した後にDefaultReportSubmissionRuleが作成されます。(Microsoft Learn)
報告メールボックスを変更する場合は、ルールだけを書き換えないようにしてください。レポート提出ルールで変更できる実質的な設定はSentToのメールアドレスですが、メールボックスを変える場合は、レポート提出ポリシー側のThirdPartyReportAddresses、ReportJunkAddresses、ReportNotJunkAddresses、ReportPhishAddressesも対応させる必要があります。(Microsoft Learn)
Microsoft以外の報告ツールを使う場合の開発・移行上の注意点
Microsoft以外の報告ツールをDefender for Office 365の報告体験に統合する場合、開発者やツール管理者はメッセージ形式を必ず確認する必要があります。形式が合っていないと、Defenderポータルの［ユーザーによる報告］タブで正しく識別されません。
公式情報では、報告メールボックスへ送るメッセージについて、元のユーザー報告メッセージを変更せず、非圧縮の.EMLまたは.MSG添付ファイルとして含める必要があるとされています。元メッセージを単に転送してはいけません。また、複数の添付メッセージを含むメッセージは破棄されます。(Microsoft Learn)
必要なヘッダーは次のとおりです。
X-Microsoft-Antispam-Message-Info
Message-Id
X-Ms-Exchange-Organization-Network-Message-Id
X-Ms-Exchange-Crosstenant-Id件名には、報告理由を識別するためのプレフィックスも必要です。
| 報告種別 | 件名プレフィックス | |
|---|---|---|
| 迷惑メール | 1 |またはJunk: | |
| 迷惑メールではない | 2 |またはNot junk: | |
| フィッシング | 3 |またはPhishing: |
プレフィックスがないメッセージは、常にフィッシングとして識別されます。サードパーティツールから移行する場合は、テスト用メールで「迷惑メール」「迷惑メールではない」「フィッシング」の3パターンを送信し、Defenderポータル上の分類結果が想定どおりになるか確認してください。(Microsoft Learn)
展開前に確認したい設定チェックリスト
本番展開前には、次の順序で確認すると手戻りを減らせます。
| 手順 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | 既存の報告ボタン、報告先、SOCの確認フローを棚卸しする | Outlook標準ボタンと外部アドインが重複する |
| 送信先決定 | Microsoftのみ、報告メールボックスのみ、両方のいずれかを決める | 「社内にも残る」と思っていたがMicrosoftのみだった |
| メールボックス準備 | Exchange Onlineメールボックスを用意する | 配布グループや外部メールアドレスを指定しようとする |
| セキュリティ例外 | SecOpsメールボックス登録、DLP除外を実施する | 報告メールが検疫・DLPで止まる |
| ユーザー体験 | 確認ポップアップ、成功メッセージ、結果通知を確認する | 通知文が英語のまま、または社内ルールと合わない |
| PowerShell確認 | ポリシーとルールの値を確認する | ルールだけ更新してポリシーと不整合になる |
| テスト | フィッシング、迷惑メール、正常メールを報告する | 1種類だけテストして分類ミスに気づかない |
| 運用化 | SOCの確認手順、Microsoftへの手動送信条件を文書化する | 報告は集まるが誰も処理しない |
よくある設定ミスと対処法
User reported settingsでよくあるミスは、セキュリティ設定そのものよりも「運用の前提違い」です。以下は特に注意してください。
| よくあるミス | 起きる問題 | 対処 |
|---|---|---|
| 報告メールボックスをSecOpsメールボックスにしていない | 報告メールがフィルター処理やシミュレーション処理の対象になる | 高度な配信ポリシーでSecOpsメールボックスとして構成する |
| 報告メールボックスのみを選んだのにMicrosoft分析されると思っている | 管理者が送信しない限りMicrosoft分析に回らない | 両方送信にするか、手動送信の基準を決める |
| サードパーティ報告ツールでMicrosoftのみ送信を想定している | Microsoft以外のアドインではMicrosoftのみを選べない | 報告メールボックスを前提に設計する |
| 元メールを転送して報告している | User reportedタブで正しく識別されない可能性がある | .EMLまたは.MSG添付形式にする |
| 件名プレフィックスを付けていない | すべてフィッシング扱いになる | Junk:、Not junk:、Phishing:などを付ける |
| PowerShellでルールだけ変更する | Defenderポータル表示やポリシー値とずれる | ポリシーとルールの両方を確認・更新する |
管理者が今すぐ取るべき対応
まず、Defenderポータルで［Outlookで報告されたメッセージをモニタリングする］が有効か確認してください。無効の場合、Outlookのメール報告関連設定や検疫からの報告設定は構成できません。(Microsoft Learn)
次に、報告先を決めます。SOCで全件を確認する文化があるなら、報告メールボックスを使う構成が現実的です。Microsoftの分析と社内確認を両立したいなら「Microsoftと報告メールボックス」が候補になります。社内で原本を保持しない方針なら「Microsoftのみ」も選択肢ですが、外部アドイン利用時には選べない点に注意してください。
最後に、PowerShellでGet-ReportSubmissionPolicyとGet-ReportSubmissionRuleを確認し、報告メールボックスのアドレスがポリシーとルールで一致しているか確認します。報告メールボックス、通知文面、サードパーティツールの形式まで確認できれば、User reported settingsは単なる通報機能ではなく、ユーザー参加型のフィッシング対策基盤として活用できます。
コメント