AD2.4 Anti-Phishing Policies Beyond Defaults

Building the anti-phishing policy

Navigate to security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Anti-phishing. Click "Create" to build a new policy.

Name: "Anti-phishing — Impersonation Protection"

Users and domains: Include → All recipients.

Phishing threshold: Set to 2 — Aggressive. The default is 1 (Standard). Level 2 increases detection sensitivity for impersonation attempts. Level 3 (More aggressive) and Level 4 (Most aggressive) increase false positives significantly — start at 2 and increase only if you're still seeing impersonation attempts getting through.

Impersonation — Users to protect: Enable user impersonation protection and add your high-value targets. At minimum, add your CEO, CFO, finance director, and any senior leader whose name could be used to authorize payments or request sensitive data. You can protect up to 350 users. Add them with both their display name and email address:

• James Morrison — j.morrison@northgateeng.com
• Sarah Chen — s.chen@northgateeng.com (CFO)
• The managing director, HR director, and IT director

When an email arrives with a display name that closely matches one of these protected users but comes from a non-company domain, the policy triggers.

Impersonation — Domains to protect: Enable domain impersonation protection. Add your primary domain (northgateeng.com) and any domains you frequently receive email from — key vendors, partners, banks, and legal firms. Domain impersonation catches lookalike domains: northgateeng.co, northgate-eng.com, northgateengineering.com.

Mailbox intelligence: Enable this. Mailbox intelligence uses machine learning to learn each user's normal communication patterns — who they email, how often, and the typical content. When an email arrives that claims to be from a regular contact but doesn't match the established pattern, mailbox intelligence flags it. This catches impersonation attempts that use the correct display name and a plausible domain but haven't previously communicated with the target user.

Actions — If a message is detected as user impersonation: Set to "Quarantine the message." Don't set it to "Move to Junk" — BEC emails in the Junk folder can still be opened by users who check their Junk folder regularly. Quarantine keeps the message out of the user's mailbox entirely, and you can release it if it's a false positive.

Actions — If a message is detected as domain impersonation: Set to "Quarantine the message."

Safety tips: Enable all safety tips:

• First contact safety tip: Shows a banner on emails from senders the user has never communicated with before. This is particularly effective for BEC — when the "CEO" emails the finance clerk for the first time, the banner flags it.
• User impersonation safety tip: Shows when the sender's display name matches a protected user but the email address doesn't match.
• Domain impersonation safety tip: Shows when the sender domain is similar to a protected domain.
• Unusual characters safety tip: Shows when the sender address contains unusual characters that might be used for visual spoofing.

Click "Submit" to create the policy.

Handling false positives

Impersonation protection generates more false positives than Safe Links or Safe Attachments because it's matching patterns rather than scanning content. The most common false positive: a protected user has a personal email account with the same display name (e.g., the CEO sends an email from their personal Gmail to a colleague — the display name matches the protected user, but the domain is Gmail, so impersonation protection triggers).

When a user reports a quarantined email that's legitimate, release it from quarantine and add the sender to the "Trusted senders and domains" list in the anti-phishing policy. Navigate to the policy → Trusted senders → add the specific email address (not the entire domain — adding gmail.com as a trusted domain would defeat the purpose).

Track false positives for the first two weeks after deployment. If a specific protected user generates frequent false positives because they communicate from personal addresses, add those personal addresses to the trusted senders list. After the initial tuning period (typically 2-3 weeks), false positives should be rare.

Verifying your anti-phishing configuration

After creating the policy, verify it's active and configured correctly with PowerShell:

Connect-ExchangeOnline
Get-AntiPhishPolicy | Select-Object Name, Enabled, PhishThresholdLevel,
    EnableTargetedUserProtection, EnableTargetedDomainsProtection,
    EnableMailboxIntelligence, TargetedUserProtectionAction,
    TargetedDomainProtectionAction | Format-List

Check that EnableTargetedUserProtection and EnableTargetedDomainsProtection are both True, PhishThresholdLevel is 2, and the actions are set to Quarantine. If any setting is wrong, update it:

Set-AntiPhishPolicy -Identity "Anti-phishing — Impersonation Protection" `
    -PhishThresholdLevel 2 `
    -EnableTargetedUserProtection $true `
    -TargetedUserProtectionAction Quarantine

To see your protected users list:

Get-AntiPhishPolicy -Identity "Anti-phishing — Impersonation Protection" |
    Select-Object -ExpandProperty TargetedUsersToProtect

This returns the list of users you configured for impersonation protection. Verify your CEO, CFO, and other executives are on the list. If someone is missing, add them:

$currentUsers = (Get-AntiPhishPolicy -Identity "Anti-phishing — Impersonation Protection").TargetedUsersToProtect
$currentUsers += "New User;newuser@northgateeng.com"
Set-AntiPhishPolicy -Identity "Anti-phishing — Impersonation Protection" -TargetedUsersToProtect $currentUsers

Review this list quarterly — executive turnover, promotions, and new hires change who should be protected. A departing CFO no longer needs impersonation protection, but the new CFO does. Add VIP list review to the quarterly security report cadence (AD7.5).

Spoof intelligence tuning

Beyond impersonation protection, Defender for Office 365 includes spoof intelligence — the ability to detect and handle emails where the sender domain doesn't match the actual sending infrastructure. Navigate to security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Anti-phishing → Spoof intelligence.

The spoof intelligence page shows senders that have been detected spoofing domains — both your domain and external domains. Each entry shows: the spoofed domain, the sending infrastructure, the volume of messages, and whether you've allowed or blocked the spoofing.

Review this page during initial deployment. You'll likely see legitimate entries — third-party services that send email on behalf of your domain (marketing platforms, CRM systems, helpdesk ticketing systems). These are "allowed to spoof" because they're authorized senders. You'll also see illegitimate entries — unknown infrastructure sending as your domain. These should be "not allowed to spoof."

The spoof intelligence feed is self-learning. Microsoft pre-populates it based on observed traffic patterns. Your job is to review it, confirm the "allowed" entries are genuinely legitimate, and ensure "not allowed" entries are actually blocked. Do this review once at deployment and then quarterly.

Testing impersonation detection before full deployment

Before expanding the policy to all users, test it with your own account. Create a test by sending yourself an email from a personal Gmail or Outlook.com account where you set the display name to match one of your protected users (your own name works for this test).

Check what happens: Does the email arrive normally, go to junk, or get quarantined? Check the message headers for the X-MS-Exchange-Organization-AuthAs and X-Forefront-Antispam-Report headers — these show whether the anti-phishing policy evaluated the email and what action was taken. If the email arrives without any impersonation flag, the policy may not be applied to your account — verify the policy scope includes your recipient address.

Navigate to security.microsoft.com → Email & collaboration → Explorer (if available) or the quarantine to see the detection details. The quarantine entry shows the specific reason for quarantine: "User impersonation" (display name matched), "Domain impersonation" (lookalike domain detected), or "Mailbox intelligence" (unusual sender pattern). This information helps you understand what the policy catches and at what sensitivity level.

For ongoing monitoring, run a weekly check of impersonation detections:

# Check quarantine for impersonation detections in the last 7 days
Get-QuarantineMessage -QuarantineTypes "HighConfPhish","Phish" -StartDate (Get-Date).AddDays(-7) |
    Where-Object { $_.QuarantineTypes -like "*Impersonation*" -or $_.PolicyName -like "*Anti-phish*" } |
    Select-Object ReceivedTime, SenderAddress, Subject, QuarantineTypes |
    Format-Table -AutoSize

This shows you every email quarantined by your anti-phishing policy in the last week — both true positives (BEC attempts) and false positives (legitimate emails from senders whose names match your protected users). Review each one: release false positives and add the sender to trusted senders. Leave true positives quarantined and block the sender domain if you see repeated attempts.