2026年4月6日時点で参照すべき Microsoft Defender for Office 365 の最新ガイダンスは、テナントの許可/ブロック リストを「単なるホワイトリスト」ではなく、「どの From アドレスが、どの送信インフラから届くのか」を組み合わせで管理するスプーフィング制御として扱うべきだと、かなり明確に示しています。特に重要なのは、スプーフ送信者の Allow / Block は自動で期限切れにならず、Spoof intelligence の判定を上書きすると管理場所も変わることです。つまり、一度設定して終わりではなく、日々の判断と月次の棚卸しが前提のコントロールだと理解するのが正解です。 (GitHub)
本記事では、2026年2月23日付の現行 Microsoft Learn ガイドと、2026年3月31日に公開履歴で確認できる権限要件の見直しを踏まえて、今回の更新で何が実務的に重要なのか、どんな場面で [Spoofed senders] タブを使うべきか、どこから先は Submissions や anti-phishing policy で対処すべきかを、運用目線で整理します。 (GitHub)
今回のガイダンス更新で押さえるべきこと
ポータル権限の前提がより明確になった
現行ガイドの公開履歴では、2026年3月31日に「Revise permissions for email spoofing configuration」として、Defender XDR の統合 RBAC でテナントの許可/ブロック リストを操作するには、Email & collaboration の Defender for Office 365 だけでなく Exchange Online 権限も有効であることが明記されました。Exchange Online 権限側で運用する場合は、Organization Management や Security Administrator に加え、Security Operator は Exchange admin center で直接付与したときに機能する点も注意が必要です。画面は開けるのに追加や編集だけできない、といった混乱を防ぐ意味で、この更新は見逃せません。 (GitHub)
スプーフ送信者は domain pair で扱うと理解する
今回のガイドで実務的に大きいのは、スプーフ送信者を <Spoofed user>, <Sending infrastructure> の domain pair で扱う前提がより明瞭になったことです。Spoofed user には個別メール アドレス、ドメイン、ワイルドカードを指定でき、Sending infrastructure には PTR の逆引きドメイン、IP/24、検証済み DKIM ドメイン、ワイルドカードを使えます。ただし *, * は不可で、PTR 解決に失敗する環境ではドメイン指定が効かないため、IP/24 を使うよう補足されています。つまり「gmail.com を全部許可する」のではなく、「gmail.com を名乗り、tms.mx.com から届くメールだけを許可する」といった粒度で管理する設計です。 (GitHub)
spoofed senders は自動で失効しない
ここが運用上いちばん大事です。Domains & addresses の Allow には「45日 after last used」「1日」「7日」「特定日」などの期限管理がありますが、spoofed senders の Allow / Block は自動失効しません。上限は 1024 件で、変更は通常 5 分以内に反映されます。Microsoft は allow 手段の中で Tenant Allow/Block List を最も推奨していますが、公式ブログでも「TABL は一時的で安全な例外に向く一方、spoof overrides は失効しない」と明記しています。スプーフ対策だけは、「作る」より「減らす」運用が重要です。 (GitHub)
なぜスプーフィング制御は日々の Defender for Office 365 管理タスクなのか
composite authentication が fail しただけでは自動で終わらない
Microsoft は、composite authentication の失敗だけで機械的にブロックするのではなく、メッセージ全体の不審性や悪意を含む総合評価で判断すると説明しています。Spoof intelligence insight の Action が Allowed / Blocked でも、それは「スプーフとして識別したかどうか」を示すもので、必ずしも最終的な配信結果と一致しません。だからこそ、正規の SaaS や委託配信サービスの false positive も、実際の攻撃メールも、最終的には管理者の Allow / Block 判断が必要になります。 (Microsoft Learn)
override した瞬間に、管理対象が別タブへ移る
Spoof intelligence insight で Allow to spoof / Block from spoofing を実行すると、その項目は insight から消え、[Spoofed senders] タブ側の手動エントリになります。見た目としては「一覧から消えた」ように見えますが、解決したのではなく、永続的に管理すべき例外へ移っただけです。Insight だけを見ている運用だと、例外が静かに増えていきます。 (Microsoft Learn)
短期監視と棚卸しで、見る場所が違う
可視性にも癖があります。Spoof intelligence insight は 7 日分、Get-SpoofIntelligenceInsight は 30 日分、Spoof detections report は 90 日分まで見られますが、レポートの最新データは 3〜4 日遅れます。さらに Microsoft の Defender for Office 365 ブログでは、spoof intelligence review を月次チェックリストに入れるよう勧めています。実務では、日々の判断は insight とメール個票、月次の棚卸しは report と PowerShell で回すのが現実的です。 (Microsoft Learn)
どの制御を使うべきか
正規メールがスプーフ扱いされたとき
正規ベンダー、外部配信サービス、メーリング基盤などが spoof intelligence に引っかかるなら、第一候補は [Spoofed senders] の Allow です。まだ誤検知が出ていなくても事前に登録できますし、すでに spoof intelligence がブロックしたメールであれば insight からの override や Submissions からの Allow も使えます。大事なのは、From と sending infrastructure の組み合わせだけを許可することです。Microsoft も allow 方法の中では Tenant Allow/Block List を最優先に位置付け、ほかの bypass 手段は代替がない場合だけ検討すべきだとしています。なお、Outlook の via 表示を消したいだけなら allow で消せますが、根本対応としては送信側の認証整備も併記されています。 (Microsoft Learn)
明らかなスプーフを止めたいとき
特定の From を名乗り、特定の送信インフラから繰り返し届くスプーフを止めたいなら、[Spoofed senders] の Block が向いています。Block は domain pair 単位で効き、エントリは自動失効しません。同じ pair に Allow と Block が重なれば Block が優先です。逆に、スプーフを止めたいだけなのに [Domains & addresses] でドメイン全体を block すると、そのドメイン宛ての送信も組織側からできなくなるので、やりすぎになりやすい点に注意が必要です。 (Microsoft Learn)
高信頼フィッシングやマルウェアの誤検知のとき
高信頼フィッシングやマルウェアの誤検知は、Tenant Allow/Block List に直接 Allow を足す運用ではありません。Microsoft は、Submissions page から「I’ve confirmed it’s clean」として送信し、Allow this message / URL / file を作成する流れを前提にしています。直接 TABL で作れる Allow は Bulk、Spam、High confidence spam、Phishing（高信頼ではない）までで、malware と high confidence phishing の上書きは submission 経由が必要です。 (Microsoft Learn)
impersonation の誤検知のとき
ユーザー偽装やドメイン偽装、いわゆる impersonation の誤検知は、spoofed senders の Allow と同じ器ではありません。Defender for Office 365 では、そのような誤検知を送信しても Tenant Allow/Block List に Allow が作られるのではなく、検出した anti-phishing policy の Trusted senders and domains 側に反映されます。ここを混同すると、「TABL に出てこないから設定されていない」と誤解しやすくなります。 (Microsoft Learn)
設定前に確認したいチェックポイント
設定前に、次の 5 点を押さえておくと失敗がかなり減ります。
- [Domains & addresses] の送信者エントリは
5322.From、つまり表示上の From アドレスに対して効きます。spoofed sender の Spoofed user も同じく From 基準です。5321.MailFromを見て登録すると外しやすいポイントです。 (Microsoft Learn) - Sending infrastructure は、PTR 逆引きドメイン、
IP/24、検証済み DKIM ドメインのどれが実態に合うかをメッセージ ヘッダーや spoof intelligence の詳細で確認します。PTR が壊れているなら、最初からIP/24を使う方が安全です。 (GitHub) - accepted domain を名乗るなら Spoof type は Internal、それ以外は External です。internal spoof を mail flow rule の safe sender 的な発想で逃がすより、spoofed senders の Internal 管理で扱う方が筋が通ります。 (GitHub)
p=reject/p=quarantineの DMARC failure は spoof intelligence insight に出ないので、anti-phishing policy 側の DMARC honoring 設定と分けて考える必要があります。spoof intelligence だけ見ていると、明らかな失敗系を取りこぼします。 (Microsoft Learn)- 変更は通常 5 分以内に反映されるので、作ったら終わりにせず、portal または PowerShell で効きを確認します。 (GitHub)
Get-SpoofIntelligenceInsight
Get-TenantAllowBlockListSpoofItems
Get-TenantAllowBlockListSpoofItems -Action Block -SpoofType External
New-TenantAllowBlockListSpoofItems -Identity Default -Action Allow `
-SpoofedUser contoso.com `
-SendingInfrastructure 192.168.100.100/24 `
-SpoofType External定期確認の起点としては、Get-SpoofIntelligenceInsight と Get-TenantAllowBlockListSpoofItems があれば十分実務に乗ります。変更は Set-TenantAllowBlockListSpoofItems、削除は Remove-TenantAllowBlockListSpoofItems で行えます。 (Microsoft Learn)
やってはいけない運用
- 自社ドメインや
microsoft.comのような一般的なドメインを allow / block list に安易に入れること。Microsoft の公式ブログでも、自社ドメインや common domain を allow / block list に入れないよう明言しています。 (TECHCOMMUNITY.MICROSOFT.COM) - sender domain だけを条件にした mail flow rule で spam filtering を bypass すること。Microsoft はこのやり方を明確に非推奨としており、スプーフや impersonation を一気に通しやすくなります。 (Microsoft Learn)
- スプーフ対策のつもりで [Domains & addresses] 側の block を使い、結果として組織から相手ドメイン宛ての送信まで止めてしまうこと。pair 単位で済むなら [Spoofed senders] を選ぶべきです。 (Microsoft Learn)
- spoof override は永続例外だという前提を忘れ、棚卸ししないこと。TABL 全体は「安全な一時例外」として推奨されますが、spoof override だけは失効しないため、月次レビューを仕組みに組み込まないと確実に積み上がります。 (TECHCOMMUNITY.MICROSOFT.COM)
いま取るべき次の一手
結論として、Microsoft の最新ガイダンスが示しているのは、テナントの許可/ブロック リストのスプーフィング制御を「広い許可設定」ではなく「From と送信インフラの組み合わせに限定した例外管理」として扱うことです。Spoof intelligence、Submissions、anti-phishing policy は役割が違います。特に spoof overrides は自動で消えないので、4月時点の見直しでは、まず権限要件を確認し、現行エントリを棚卸しし、恒久対応として送信元の認証修正を促すところから始めるのが実務的です。 (GitHub)
今日やるなら、この順番が失敗しにくいです。
- [Spoofed senders] タブと Spoof intelligence insight を開き、理由を説明できない手動 Allow / Block を洗い出す。 (Microsoft Learn)
- 統合 RBAC を使っているなら、Defender for Office 365 と Exchange Online の両方の権限トグルを確認する。 (GitHub)
- broad な mail flow rule や anti-spam allow を残しているなら、domain pair の例外か、送信元の SPF / DKIM / DMARC / PTR 修正へ置き換える。 (Microsoft Learn)
コメント