How to Configure Anti-Phishing Policies in Exchange Online Protection

Why Anti-Phishing Policies Matter

Phishing isn't slowing down—it's evolving. Attackers spoof trusted domains, impersonate executives, and craft lures convincing enough to fool even cautious users, all in pursuit of credentials and sensitive data. Exchange Online Protection (EOP) stands as your first line of defense, delivering baseline anti-phishing capabilities to every Microsoft 365 organization with cloud mailboxes.

Out of the box, EOP provides spoof intelligence, first contact safety tips, and unauthenticated sender indicators—no additional licensing required [1]. Organizations running Microsoft Defender for Office 365 gain a significantly more advanced toolkit: AI-powered impersonation detection for users and domains, mailbox intelligence, customizable phishing thresholds, and machine learning-based detection [1].

Every Microsoft 365 tenant ships with a default anti-phishing policy covering all recipients [2]. But default coverage is just the starting point. Administrators can layer custom policies on top, targeting specific users, groups, or domains with protections calibrated to their actual risk profile.

This guide covers anti-phishing policy configuration end to end—portal-based setup, PowerShell automation, Microsoft's recommended settings across protection tiers, and the precedence model that determines which policy governs when multiple policies overlap.

Anti-Phishing Policy Architecture and Precedence

Getting the architecture right matters more than any individual setting. Anti-phishing policies follow a strict evaluation order: the Strict Preset Security Policy takes precedence, followed by Standard Preset, then custom policies sorted by priority number (lower number = higher priority), and finally the default policy, which always sits at the bottom [12]. The moment a recipient matches a policy, evaluation stops—no subsequent policies apply.

This "first match wins" behavior carries real consequences. If an executive falls within both a Strict preset policy and a custom policy, only the Strict preset settings take effect. Design your scoping accordingly.

Under the hood in PowerShell, each anti-phishing policy actually consists of two objects: an anti-phish policy (protection settings and actions) and an anti-phish rule (recipient filters and priority). The *-AntiPhishPolicy cmdlets manage settings; the *-AntiPhishRule cmdlets manage scoping and priority [2].

A practical note: Microsoft recommends relying on Standard and Strict preset security policies rather than building custom policies from scratch. Presets automatically apply Microsoft's recommended settings and stay current as those recommendations evolve [7]. To create, modify, or delete anti-phishing policies, you'll need Organization Management or Security Administrator role group membership [2].

Configuring Policies via the Microsoft Defender Portal

To create or edit anti-phishing policies through the portal, navigate to Email & Collaboration > Policies & rules > Threat policies > Anti-phishing, or go directly to https://security.microsoft.com/antiphishing [2].

Spoof Intelligence and Authentication

Spoof intelligence is enabled by default across all anti-phishing policies [1]. For the authentication failure action, Microsoft's Standard recommendation routes spoofed messages to Junk Email, while the Strict recommendation quarantines them outright [3].

Honoring DMARC Records

The Honor DMARC record policy setting governs how EOP responds to messages that fail explicit DMARC checks. For domains publishing p=quarantine, administrators choose between Quarantine and Move to Junk. For p=reject, the options are Quarantine and Reject [1].

One important caveat: when your MX records point to a third-party service in front of Microsoft 365, this setting only takes effect if Enhanced Filtering for Connectors is enabled on the inbound connector [1]. You can view your connectors at https://security.microsoft.com/skiplisting .

Safety Tips and Sender Indicators

The first contact safety tip warns recipients when they hear from an unfamiliar sender for the first time—a simple but effective guard against impersonation attacks targeting users who don't scrutinize sender addresses closely [1]. Pair this with unauthenticated sender indicators and the "via" tag to surface visual cues directly in Outlook, giving end users a clear signal before they engage with potentially dangerous content [2].

Recipient Scoping

Define each policy's reach by specifying individual users, distribution groups, or domains. Leave the default policy unscoped so it functions as the catch-all for every recipient. Bear in mind that new or updated policies may take up to 30 minutes to propagate across the organization [2].

Configuring Impersonation Protection (Defender for Office 365)

Organizations licensed for Microsoft Defender for Office 365 unlock impersonation protection capabilities that go well beyond basic spoofing defense. This is where anti-phishing configuration gets both more powerful and more nuanced.

One important prerequisite: impersonation protection and advanced anti-phishing features require Microsoft Defender for Office 365 Plan 1 or Plan 2, or Microsoft 365 E5. If you only have basic EOP, you won't see these options.

User Impersonation Protection

Each policy supports up to 350 protected users for impersonation detection [1]. Focus on C-suite executives, finance leaders, HR directors, and other high-value individuals whose identities attackers are most likely to abuse. One critical detail: user impersonation detection only fires when there is no prior communication history between the sender and recipient. If the two parties have exchanged emails before, the detection won't trigger [1].

Domain Impersonation Protection

Administrators can protect up to 50 custom domains per policy [1]. Enable organization domains protection to automatically cover all accepted domains in your tenant. For partners or vendors whose domains attackers commonly spoof, add those as custom protected domains. Note that subdomains require separate entries—protecting a parent domain does not extend coverage to its subdomains [1].

Mailbox Intelligence

Mailbox intelligence leverages AI to map each user's communication patterns with frequent contacts, building a graph that distinguishes legitimate senders from impersonators [1]. Enable both mailbox intelligence and mailbox intelligence protection to ensure detection results translate into actual enforcement actions.

Phishing Email Thresholds

Defender for Office 365 offers four phishing threshold levels controlling detection sensitivity [1]:

• Level 1 (Standard) — The default
• Level 2 (Aggressive) — Heightened sensitivity
• Level 3 (More aggressive) — Recommended for Standard preset policies [3]
• Level 4 (Most aggressive) — Recommended for Strict preset policies [3]

Each step up treats lower-confidence phishing signals as higher confidence, expanding threat coverage at the cost of increased false positive risk.

Actions and Trusted Entities

For Standard presets, Microsoft recommends quarantining user and domain impersonation detections while routing mailbox intelligence detections to Junk. Strict presets quarantine across the board [3]. The trusted senders and domains list supports up to 1,024 entries, with subdomains requiring individual entries [1].

Recommended Settings: Default vs. Standard vs. Strict

Microsoft publishes recommended anti-phishing settings across three tiers. The following comparison helps you choose the right balance between protection strength and false positive tolerance.

Standard delivers solid protection for the majority of users. Strict is the right choice for high-risk roles—executives, finance, and anyone with elevated access. Higher thresholds catch more threats but generate more false positives. Start with Standard and escalate to Strict only where the risk warrants the added scrutiny.

For maximum effectiveness, pair your anti-phishing configuration with robust email authentication. CISA's Secure Cloud Business Applications (SCuBA) project provides detailed security configuration baselines for Microsoft 365, including specific guidance on SPF, DKIM, and DMARC deployment that directly complements anti-phishing policies [5].

Best Practices and Troubleshooting

Lead with presets. Deploy Standard preset security policies for most users and Strict for executives and sensitive roles before building any custom policies. This approach prevents configuration drift and ensures you automatically inherit Microsoft's latest recommended settings [7].

Review spoof intelligence regularly. The spoof intelligence insight in the Defender portal surfaces spoofed senders that EOP has flagged. Review these findings periodically and adjust the tenant allow/block list to correct false positives for legitimate senders.

Expect propagation delays. Policy changes can take up to 30 minutes to propagate [2]. If a newly saved policy doesn't seem to be working, give it time before troubleshooting.

Pilot before you deploy. Test new policies with a scoped pilot group before rolling them out organization-wide. Catching false positives early with a small group is far better than discovering them across the entire workforce.

Monitor quarantine actively. Aggressive thresholds (Level 3 and 4) will catch more threats—but also more legitimate mail. Establish a regular quarantine review cadence so valid messages don't languish unnoticed.

Document your policies. Maintain a consistent naming convention and document every custom configuration. As your policy count grows, clear documentation prevents overlap, confusion, and unintended coverage gaps.