Microsoft Defender for Office 365 の「Remove blocked users from the Restricted entities page」は、送信制限されたユーザーを管理者が安全に解除するための公式手順です。結論から言うと、ユーザーが Restricted entities page に追加された場合は、単に「Unblock」を押すのではなく、アカウント侵害の確認、MFA・パスワード対応、アラート設定の確認までをセットで実施する必要があります。公式ページは 2026年6月25日に更新されており、Microsoft Defender ポータルと Exchange Online PowerShell の両方から解除できる点が整理されています。(Microsoft Learn)
この変更は、メール送信が突然できなくなったユーザーへの一時対応だけでなく、Microsoft 365 の送信保護、アウトバウンドスパム対策、インシデント対応手順に関わります。特に、営業部門の一括送信、外部向け通知、業務アプリからの SMTP 送信を Exchange Online の通常メールボックスで運用している組織では、解除手順だけでなく「なぜ制限されたのか」を確認することが重要です。
Microsoft Defender の Restricted entities page とは
Restricted entities page は、Microsoft Defender ポータル上で、送信が制限されたユーザーアカウントやコネクタを確認するための画面です。ユーザーがサービスのアウトバウンド送信制限やアウトバウンドスパムポリシーの制限に抵触すると、そのユーザーはメールを送信できなくなります。ただし、受信は引き続き可能です。(Microsoft Learn)
Microsoft の説明では、Restricted entity は「侵害の兆候によってメール送信をブロックされたユーザーアカウントまたはコネクタ」とされています。ユーザーが該当する場合、Restricted entities page では Entity の値が Mailbox として表示されます。(Microsoft Learn)
ユーザー側では、送信時に NDR、いわゆる配信不能通知が返ることがあります。代表的なエラーは「550 5.1.8 Access denied, bad outbound sender」で、Microsoft のサポートページでも、管理者がアカウントを保護したうえで Restricted entities page から解除する流れが案内されています。(Microsoft Learn)
今回の更新ポイント
2026年6月25日に更新された公式情報の要点は、送信制限されたユーザーを Microsoft Defender ポータルまたは Exchange Online PowerShell から解除する手順を、管理者向けに明確化している点です。新しいライセンス購入や大規模な移行作業を求める内容ではなく、インシデント対応の運用手順を整えるべき更新と見るのが実務的です。(Microsoft Learn)
| 確認項目 | 更新内容・実務上の意味 |
|---|---|
| 対象画面 | Microsoft Defender ポータルの Email & collaboration > Review > Restricted entities で確認する |
| 対象ユーザー | 送信制限されたメールボックス。Restricted entities page 上では Entity が Mailbox として表示される |
| 解除方法 | ポータルの Unblock 操作、または Exchange Online PowerShell の Remove-BlockedSenderAddress を使用する |
| 解除前の前提 | アカウント侵害の可能性を確認し、必要に応じて MFA 有効化やパスワードリセットを実施する |
| 解除反映 | 多くの場合は 1時間以内。技術的な一時問題がある場合でも、合計待機時間は 24時間以内と説明されている |
| 管理者通知 | 既定のアラートポリシー「User restricted from sending email」を確認する |
重要なのは、「送信できないから解除する」では不十分という点です。Microsoft は、アウトバウンド送信制限の超過をアカウント侵害の兆候として扱い、解除前にアカウントの制御を取り戻す手順を実施するよう明記しています。(Microsoft Learn)
影響範囲：誰が何に困るのか
この更新の影響を受けるのは、Microsoft 365 のクラウドメールボックスを利用する組織です。公式ページでは、Built-in security features for all cloud mailboxes、Microsoft Defender for Office 365 Plan 1 / Plan 2、Microsoft Defender XDR が対象として示されています。(Microsoft Learn)
送信制限の影響は、主に次のように現れます。
| 立場 | 起こること | 管理者が見るべき場所 |
|---|---|---|
| 一般ユーザー | メール送信が失敗し、NDR が返る。受信はできる | NDR のエラーコード、ユーザーからの申告 |
| メール管理者 | Restricted entities page に該当ユーザーが表示される | Microsoft Defender ポータル |
| セキュリティ担当 | アカウント侵害、外部転送、不審な送信の調査が必要になる | Defender のアラート、監査ログ、サインイン履歴 |
| 情シス運用担当 | 解除手順、通知先、再発防止策の整備が必要になる | アラートポリシー、アウトバウンドスパムポリシー |
| 業務部門 | 一括メールや外部通知が止まる可能性がある | 送信設計、配信ツール、利用者教育 |
特に注意したいのは、正規の業務メールであっても、送信量や送信パターンによって制限に近づく可能性がある点です。Exchange Online には 24時間あたりの受信者数、1分あたりのメッセージ数、テナント外部受信者数などの送信制限があり、ニュースレターや大量通知のような用途には専用の配信基盤を使うことが推奨されています。(Microsoft Learn)
解除前に確認すべきセキュリティ観点
Restricted entities page からユーザーを削除する前に、まず「本当に正規利用だったのか」を確認します。Microsoft の侵害アカウント対応ガイドでは、メールボックスが送信ブロックされている状態、不審な Inbox ルール、未知の外部アドレスへの自動転送、送信済み・削除済みアイテム内の不審なメッセージなどが、侵害の兆候として挙げられています。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを減らせます。
| 確認対象 | 見るポイント | 放置した場合のリスク |
|---|---|---|
| サインイン履歴 | 通常と異なる国、IP、端末、時間帯からのサインイン | 攻撃者が再ログインする |
| パスワード | 既に漏えいしていないか、再利用されていないか | 解除後に再び迷惑メール送信に使われる |
| MFA | 有効化されているか、攻撃者に MFA 手段を追加されていないか | パスワード変更後も侵害が続く |
| Inbox ルール | 外部転送、削除、RSS・Notes フォルダー移動などの不自然なルール | 重要メールの窃取や隠蔽が続く |
| 送信済みアイテム | 大量送信、金銭要求、フィッシングらしき文面 | 組織ドメインの信頼低下 |
| アプリ連携 | 不審な OAuth アプリや委任権限 | パスワード変更だけでは止まらない可能性 |
「本人が大量送信しただけ」と思える場合でも、まず侵害を疑うのが安全です。攻撃者は短時間で大量送信した後、痕跡を隠すために削除ルールや転送ルールを作成することがあります。解除作業は復旧対応であると同時に、再発を防ぐためのセキュリティ確認でもあります。
Microsoft Defender ポータルで制限ユーザーを解除する手順
Microsoft Defender ポータルからの解除は、管理者が画面上で確認しながら進められるため、単発の復旧対応に向いています。公式手順では、Email & collaboration > Review > Restricted entities に移動し、該当ユーザーを選択して Unblock を実行します。(Microsoft Learn)
| 手順 | 操作 | 実務上の注意点 |
|---|---|---|
| 1 | Microsoft Defender ポータルを開く | 必要な権限を持つ管理者アカウントで作業する |
| 2 | Email & collaboration > Review > Restricted entities を開く | 直接 Restricted entities page に移動することもできる |
| 3 | 対象ユーザーを検索する | ユーザーの場合、Entity が Mailbox であることを確認する |
| 4 | チェックボックスでユーザーを選択し、Unblock を選ぶ | 間違ったユーザーを解除しないよう UPN と表示名を確認する |
| 5 | Unblock user の Overview を確認する | Recommendations の内容を確認し、侵害対応が済んでいるか判断する |
| 6 | MFA やパスワード変更の項目を確認して Submit する | 未対応なら解除前に実施する |
| 7 | 警告ダイアログで Yes を選ぶ | アカウントが保護済みであることを確認してから実行する |
公式情報では、ほとんどの場合、解除後 1時間以内にすべての制限が削除されるとされています。一時的な技術問題で長くかかる場合でも、合計の待機時間は 24時間以内と説明されています。(Microsoft Learn)
解除直後に送信テストをして失敗しても、すぐに同じ操作を繰り返すのは避けます。まず反映待ちの時間を考慮し、1時間程度を目安に再確認します。24時間を超えても送信できない場合は、別の制限、再度の侵害、不完全な復旧、またはサービス側の問題を切り分ける必要があります。
Exchange Online PowerShell で確認・解除する方法
複数ユーザーの確認、運用手順書への組み込み、監査証跡を残したい場合は、Exchange Online PowerShell の利用が便利です。公式ページでは、制限されているユーザーの一覧取得、特定ユーザーの詳細確認、制限解除のコマンドが示されています。(Microsoft Learn)
制限ユーザーの一覧を確認します。
Get-BlockedSenderAddress特定ユーザーの詳細を確認します。
Get-BlockedSenderAddress -SenderAddress [email protected] | Format-List制限を解除します。
Remove-BlockedSenderAddress -SenderAddress [email protected]PowerShell で解除する場合も、ポータル操作と同じく「解除前にアカウントを保護する」ことが前提です。スクリプト化する場合は、解除コマンドの前に、チケット番号、承認者、調査結果、MFA・パスワード対応の有無を記録する運用にしておくと、後からインシデントレビューをしやすくなります。
必要な権限と最小権限の考え方
Restricted entities page の操作には、Microsoft Defender XDR Unified RBAC、Exchange Online の役割グループ、Microsoft Entra の管理者ロールなど、いくつかの権限パターンがあります。公式情報では、ユーザーを Restricted entities page から削除するには Organization Management または Security Administrator の役割グループ、読み取りのみなら Global Reader、Security Reader、View-Only Organization Management などが示されています。(Microsoft Learn)
実務上は、Global Administrator で日常運用するのは避けるべきです。Microsoft も最小権限の原則を推奨しており、Global Administrator は高権限ロールであるため、緊急時や他のロールで対応できない場合に限定する考え方が示されています。(Microsoft Learn)
おすすめの分担は次のとおりです。
| 役割 | 推奨される担当 | 理由 |
|---|---|---|
| 一覧確認 | セキュリティ運用担当、ヘルプデスク上位担当 | 送信不可の一次切り分けができる |
| 解除判断 | メール管理者、セキュリティ管理者 | 誤解除を防ぎ、侵害確認を含められる |
| ポリシー変更 | メール基盤管理者 | 送信制限や通知設定への影響を判断できる |
| 監査確認 | セキュリティ担当、コンプライアンス担当 | 事後調査と証跡確認ができる |
アラート設定で確認すべきポイント
Restricted entities page にユーザーが追加されたことを管理者が早期に把握するには、アラート設定が重要です。公式手順では、既定のアラートポリシー「User restricted from sending email」が、ユーザーがメール送信をブロックされたときに管理者へ通知すると説明されています。(Microsoft Learn)
確認すべき設定は、主に次の3つです。
| 設定 | 確認内容 | 実務上の判断基準 |
|---|---|---|
| Status | アラートがオンになっているか | オフの場合、送信制限の発見が遅れる |
| Recipients | 通知先が適切か | TenantAdmins だけでなく、メール運用・SOC・情シス窓口を含める |
| Daily notification limit | 通知上限が業務に合っているか | 大量通知を避けつつ、見逃しが起きない値にする |
アラートが機能するには監査ログが有効である必要があります。Restricted users の公式手順では監査ログは既定で有効と説明されていますが、Microsoft Purview の監査ログに関する公式情報では、Microsoft 365 Business Basic、Business Standard、Business Premium などの SMB ライセンスでは既定で有効ではない場合があるとされています。対象テナントでは、実際に監査が有効かを確認するのが安全です。(Microsoft Learn)
監査ログの状態は、Exchange Online PowerShell で次のように確認できます。UnifiedAuditLogIngestionEnabled が True なら監査が有効です。(Microsoft Learn)
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabledアウトバウンドスパムポリシーで見直すべき設定
Restricted entities page への追加は、アウトバウンドスパムポリシーや送信制限と密接に関係します。Microsoft 365 は、クラウドメールボックスから送信されるメールを自動的に確認し、不審なアウトバウンドメールや異常な送信活動を検出します。組織内ユーザーからのアウトバウンドスパムは、一般的にアカウント侵害を示すものとして扱われます。(Microsoft Learn)
アウトバウンドスパムポリシーでは、外部受信者数、内部受信者数、1日あたりの受信者数などのメッセージ制限を設定できます。値は 0 から 10000 の範囲で、既定値の 0 はサービス既定値を使う設定です。(Microsoft Learn)
| 設定項目 | 見直しポイント | 注意点 |
|---|---|---|
| Set an external message limit | 外部宛て送信が多い部門やアプリに合っているか | 緩めすぎると侵害時の拡散被害が大きくなる |
| Set an internal message limit | 社内一斉通知やシステム通知の運用に合っているか | 内部フィッシングの拡散も考慮する |
| Set a daily message limit | 1日あたりの送信量の実態に合っているか | 正規送信と大量送信の境界を把握する |
| Restrict the user from sending mail until the following day | 一時的な超過を翌日まで止める | 既定動作として扱いやすいが、侵害調査は別途必要 |
| Restrict the user from sending mail | 管理者が解除するまで止める | 復旧に管理者作業が必要だが、安全性を高めやすい |
| No action, alert only | 通知のみ行う | 業務影響は減るが、不審送信を止められない可能性がある |
「Restrict the user from sending mail」を選ぶと、ユーザーは Microsoft Defender ポータルの Restricted users に追加され、管理者が削除するまでメール送信できません。解除後、その日は再び制限されないという説明もあります。(Microsoft Learn)
自動外部転送の設定も見落としやすいポイントです。アウトバウンドスパムポリシーの Automatic forwarding rules は、既定の Automatic – System-controlled が現在は Off – Forwarding is disabled と同じ動作になっていると説明されています。外部転送は情報漏えいや侵害継続の経路になりやすいため、例外を作る場合は対象者と理由を明確にしておくべきです。(Microsoft Learn)
移行期限や強制変更はあるのか
今回の公式ページから読み取れる範囲では、特定日までに移行が必要な変更、クライアント更新、エージェント入れ替え、ライセンス移行のような期限は示されていません。2026年6月25日の更新は、Restricted entities page からブロックされたユーザーを削除する手順、権限、アラート、PowerShell 操作を確認するための運用系ドキュメント更新と捉えるのが自然です。(Microsoft Learn)
ただし、期限がないから後回しでよいわけではありません。送信制限は、ユーザーの業務を止めるだけでなく、アカウント侵害や組織ドメインの評判低下に直結します。次のような内部期限を設けて、運用整備を進めると現実的です。
| 対応 | 推奨タイミング | 理由 |
|---|---|---|
| Restricted entities page の確認権限を棚卸し | 直近の運用レビュー時 | 送信不可発生時に担当者が画面を見られない事態を防ぐ |
| アラート通知先の見直し | すぐに実施 | TenantAdmins だけでは検知後の対応が遅れる場合がある |
| 解除手順書の更新 | 次回の月次運用まで | ヘルプデスクとメール管理者の判断を揃える |
| 大量送信の洗い出し | 次回のメール基盤レビューまで | 正規の大量送信が制限の原因になる前に設計を見直す |
| インシデント対応訓練 | 四半期ごと | 解除前の侵害確認を形骸化させない |
よくある失敗と回避策
解除を最優先してしまう
最も危険なのは、ユーザーから「メールが送れない」と連絡を受けて、調査せずに Unblock する対応です。送信制限は、単なる利用制限ではなく侵害の兆候として扱うべきです。公式手順でも、解除前にアカウントの制御を取り戻すための必要な手順を実施するよう説明されています。(Microsoft Learn)
回避策は、解除前チェックリストを必須化することです。少なくとも、サインイン履歴、MFA、パスワード、Inbox ルール、送信済みアイテム、不審な外部転送は確認対象に含めます。
Restricted users と Restricted entities を混同する
Microsoft の画面や関連ドキュメントでは、Restricted users と Restricted entities の表現が混在して見える場面があります。現在の操作としては、Microsoft Defender ポータルの Email & collaboration > Review > Restricted entities で対象を確認し、ユーザーの場合は Entity が Mailbox であることを見ます。(Microsoft Learn)
コネクタが制限されている場合は別の対応になります。ユーザーの解除手順とコネクタの解除手順を混ぜると、原因調査や復旧対象を誤る可能性があります。
通知先が管理者だけになっている
アラートポリシーの通知先が TenantAdmins のみだと、実際にメール運用を担当するチームに情報が届かないことがあります。公式手順では、User restricted from sending email アラートの Status、Recipients、Daily notification limit を確認する流れが示されています。(Microsoft Learn)
運用上は、グローバル管理者だけでなく、メール基盤担当、セキュリティ運用担当、ヘルプデスク上位窓口を通知先に含めると、初動が速くなります。
Exchange Online を大量メール配信基盤として使い続ける
正規のキャンペーンメールやニュースレターでも、Exchange Online の通常メールボックスで大量配信すると、送信制限やレピュテーションの問題につながります。Microsoft は、正規の大量商用メールを送る必要がある場合、こうした用途に特化したサードパーティプロバイダーの利用を推奨しています。また、外部向けの高ボリューム送信が必要な場合には Azure Communication Services email への言及もあります。(Microsoft Learn)
大量送信が必要な業務は、通常の個人メールボックスではなく、配信専用サービス、認証済みドメイン、適切な配信停止機能、送信レピュテーション管理を備えた構成に分けるべきです。
管理者が今すぐ確認すべきチェックリスト
次の項目を確認しておくと、送信制限が発生したときに慌てず対応できます。
| チェック項目 | 確認内容 |
|---|---|
| 画面アクセス | Microsoft Defender ポータルで Restricted entities page を開けるか |
| 権限 | 解除できる担当者と、読み取りだけの担当者が分かれているか |
| アラート | User restricted from sending email がオンになっているか |
| 通知先 | 実際に対応するチームに通知が届くか |
| 監査ログ | 監査が有効で、必要なログを検索できるか |
| 解除手順 | MFA、パスワード、Inbox ルール、送信履歴の確認が手順に入っているか |
| PowerShell | Get-BlockedSenderAddress と Remove-BlockedSenderAddress を実行できる管理端末があるか |
| 大量送信 | Exchange Online の通常メールボックスで大量配信している業務がないか |
| 再発防止 | 解除後に送信量、送信先、外部転送、侵害原因をレビューしているか |
実務での対応フロー
送信制限が発生した場合は、次の流れで対応します。
| フェーズ | 実施内容 | 判断ポイント |
|---|---|---|
| 検知 | ユーザー申告、NDR、Defender アラートを確認 | 550 5.1.8 や User restricted from sending email を確認 |
| 一次確認 | Restricted entities page で対象ユーザーを確認 | Entity が Mailbox か、対象ユーザーに間違いがないか |
| 侵害調査 | サインイン、MFA、パスワード、Inbox ルール、送信済みを確認 | 攻撃者の継続アクセスが残っていないか |
| 保護 | パスワードリセット、MFA 対応、必要に応じたアカウント停止 | 解除してよい状態か |
| 解除 | Defender ポータルまたは PowerShell で解除 | 解除作業の記録を残す |
| 確認 | 1時間程度を目安に送信状況を確認 | 反映待ちと再制限を切り分ける |
| 再発防止 | ポリシー、通知先、大量送信設計を見直す | 業務都合とセキュリティのバランスを調整する |
まとめ：解除手順ではなく、送信保護の運用として見直す
Microsoft Defender の「Remove blocked users from the Restricted entities page」は、送信制限されたユーザーを解除するための手順ですが、本質は「制限された理由を確認し、安全に復旧する」ための運用です。解除だけなら数クリックまたは PowerShell 1コマンドで実行できますが、侵害確認を省くと、同じアカウントが再び悪用される可能性があります。
管理者は、まず Restricted entities page を確認できる権限、User restricted from sending email アラートの通知先、監査ログの状態を確認しましょう。そのうえで、送信制限が発生した際の手順書に、MFA、パスワードリセット、Inbox ルール確認、送信履歴確認、解除後の再発防止レビューを組み込むことが重要です。
また、正規の大量送信が原因になりそうな業務は、Exchange Online の通常メールボックスで続けるのではなく、専用のメール配信基盤や適切な送信サービスへ分離することを検討してください。今回の更新は、単なる管理画面の操作確認ではなく、Microsoft 365 のメール送信を安全に維持するための運用見直しのきっかけになります。
コメント