8.2 Anti-Phishing Policies

90 minutes · Module 8

Anti-Phishing Policies

By the end of this subsection, you will be able to configure impersonation protection for executives and domains, enable mailbox intelligence, set phishing thresholds, and monitor policy effectiveness with KQL.

Anti-phishing policies in Defender for Office 365 go beyond basic spam filtering. They use machine learning and heuristic analysis to detect impersonation attempts, spoof emails, and sophisticated phishing that passes signature-based checks.

Impersonation protection — users and domains

User impersonation protects specific high-value users. The attacker sends an email that appears to come from the CFO (e.g., “John Smith” but from john.smith@attacker-domain.com). The policy detects the display name match against the protected user list.

Domain impersonation protects your organization’s domains and partner domains. The attacker uses a lookalike domain (northgateeng.co instead of northgateeng.com). The policy detects the visual similarity.

Protection type	What to configure	Recommended action
Protected users	Add executives, finance team, IT admins (up to 350 users)	Quarantine the message
Protected domains	Add your domains + key partner/vendor domains	Quarantine the message
Mailbox intelligence	Enable (learns each user’s communication patterns)	Move to Junk folder
Mailbox intelligence impersonation	Enable (combines MI with impersonation detection)	Quarantine the message

Protect your finance team first

BEC attacks target finance team members by impersonating executives or vendors requesting payment changes. Add every member of your finance and accounts payable team to the protected users list, plus every executive whose name an attacker might impersonate. This directly prevents the follow-on attack that the Module 13 attacker was preparing for (financial reconnaissance for BEC).

First contact safety tip

When a user receives an email from a sender for the first time, a safety tip appears: “You don’t often get email from this sender.” This is a low-friction security awareness mechanism — it does not block the email but alerts the user to verify the sender.

Enable this for all users. It is especially effective against first-wave phishing where the sender domain has never been seen before (exactly the Module 13 scenario — northgate-voicemail.com was a first-time sender for every recipient).

Spoof intelligence

Spoof intelligence detects emails where the “From” address domain does not match the actual sending infrastructure (SPF/DKIM failure or domain mismatch). Defender maintains a spoof intelligence insight showing which senders are spoofing your domain and whether they are legitimate (marketing platforms, third-party services) or malicious.

Review the spoof intelligence insight monthly. Legitimate spoofing senders (your email marketing platform sending “from” your domain) should be explicitly allowed. Everything else should be blocked.

Phishing threshold

The anti-phishing threshold controls how aggressively Defender classifies emails as phishing:

Threshold	Behavior	Best for
1 — Standard	Default sensitivity	Starting point
2 — Aggressive	More emails classified as phishing	Most organizations after initial tuning
3 — More aggressive	Significantly more phishing detections	Organizations with high phishing volume
4 — Most aggressive	Maximum detection, higher FP risk	Only if you have a dedicated team reviewing quarantine

Start at threshold 2, not 1

The default threshold (1) misses a meaningful percentage of sophisticated phishing. Threshold 2 catches significantly more with minimal false positive increase. Move to 3 only after running 2 for 30 days and confirming quarantine volume is manageable. Threshold 4 generates enough quarantine volume to require daily admin review.

Monitoring anti-phishing effectiveness

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
EmailEvents
| where TimeGenerated > ago(30d)
| where ThreatTypes has "Phish"
| summarize
    TotalPhish = count(),
    Delivered = countif(DeliveryAction == "Delivered"),
    Blocked = countif(DeliveryAction == "Blocked"),
    Junked = countif(DeliveryAction == "Junked"),
    ZAPRemoved = countif(DeliveryAction == "Replaced")
    by bin(TimeGenerated, 1d)
| sort by TimeGenerated asc

Expected Output

Date	TotalPhish	Delivered	Blocked	Junked	ZAPRemoved
Mar 15	47	8	31	4	4
Mar 16	23	3	17	2	1
Mar 17	142	19	108	8	7

What to look for: The "Delivered" column is your exposure metric — these phishing emails reached user inboxes. March 17 shows a campaign (142 phishing emails, 19 delivered). Your goal is to minimize the Delivered count. If Delivered consistently exceeds 10% of TotalPhish, your anti-phishing threshold needs to be more aggressive.

Spoof intelligence management

Review the spoof intelligence insight monthly in the Defender portal (Email & collaboration → Policies → Anti-phishing → Spoof intelligence insight).

What you will see:

Senders that appear to be spoofing your domain or partner domains
Whether each sender passed or failed authentication
Whether you have allowed or blocked each sender

Common legitimate spoofers to allow:

Marketing platforms (Mailchimp, HubSpot) sending “from” your domain
CRM systems (Salesforce) sending notifications “from” your domain
Ticketing systems (ServiceNow, Zendesk) sending “from” your domain
Third-party email signatures services

Action: Allow known legitimate senders. Block everything else. Review monthly — new third-party services are onboarded regularly.

Try it yourself

Your anti-phishing monitoring query shows 19 phishing emails delivered to inboxes in one day. You are currently on phishing threshold 1 (Standard). Walk through the investigation and policy adjustment steps.

1. Investigate the 19 emails: Are they from a single campaign (same domain/URL pattern)? Use Threat Explorer or the KQL campaign scope query.

2. Remediate: Soft-delete from all affected mailboxes via Threat Explorer.

3. Check clicks: Query UrlClickEvents — did anyone click?

4. Contain compromised users: For anyone who clicked + entered credentials, execute the Module 13.7 containment sequence.

5. Block future waves: Transport rule for the URL pattern or sender domain.

6. Tune policy: Increase anti-phishing threshold from 1 to 2. Re-run the monitoring query after 7 days — did the Delivered count decrease?

7. If threshold 2 still shows high delivery: Increase to 3 and monitor quarantine volume for false positives.

Check your understanding

1. Why protect individual users (executives, finance) in anti-phishing policy instead of just protecting domains?

Attackers impersonate specific people, not just domains. An email from "John Smith" at a lookalike domain targets the CFO's identity. Domain protection catches the domain similarity; user protection catches the display name match. Both are needed because attackers use both techniques.

User protection is stronger

Domain protection has too many false positives

Impersonation attacks target identity at two levels: "who sent it" (display name = user impersonation) and "where did it come from" (domain = domain impersonation). Protecting both levels catches both attack variants.

2. Your anti-phishing monitoring shows 19 phishing emails delivered to inboxes on a single day. What is your immediate action?

Investigate: are these from a single campaign (same sender domain or URL pattern)? If yes, use Threat Explorer to identify all recipients and soft-delete the emails. Then create a transport rule or tenant block to prevent additional waves. Finally, review whether increasing the phishing threshold would have caught them.

Increase the threshold immediately

19 is an acceptable number

The response is investigate first, then remediate, then harden. Investigate the specific campaign to understand what bypassed protection. Remediate by removing the emails. Harden by adjusting policies to catch future similar campaigns. This is the same investigate-contain-harden cycle from Module 13.

← 8.1 Email Threat Landscape and Architecture 8.3 Safe Links Policies →