title: “Anti Phishing Policy Office 365: Set the User Impersonation Tab the Way Auditors Want to See It” description: “How Datapath configures the Defender for Office 365 anti-phishing policy for finance, K-12, healthcare, and CJIS-regulated Central Valley and Ohio tenants, with a focus on the user impersonation tab and the 350-address limit.” topic: “Anti Phishing Policy Office 365” route: “/blog”
Anti Phishing Policy Office 365: Set the User Impersonation Tab the Way Auditors Want to See It
An anti phishing policy in Office 365 is the Defender for Office 365 blade where spoof protection, user/domain impersonation, and mailbox intelligence live. The default Standard preset catches spoofing, but most Business Email Compromise walks through. Here are the three tabs we change and the order we change them in.
It was 11:42 a.m. on a Tuesday. The AP supervisor at a Modesto-area credit union was finishing the wire batch when a “reply” thread from the CFO appeared asking her to re-cut that morning’s ACH to a “temporary” custodial account. The signature was perfect, the display name matched, and the domain had three of the same letters - but one was off. She forwarded it to our Dublin, Ohio service desk and asked for a second pair of eyes. We pulled headers. The message had passed SPF because it was impersonating, not spoofing. SPF and DMARC could not see it, the spam policy would not have flagged it. Why? Because the anti phishing policy in Office 365 was on the default Standard preset with no names on the protected-users list and no domains on the protected-domains list.
That gap is the most common BEC entry point we see in Central Valley finance: Defender for Office 365 licensed, but the policy set to “we have it enabled” - which in practice means “the impersonation tab is empty.” This post is the conversation we have on day one of an onboarding with a regulated tenant.
What an anti phishing policy in Office 365 actually controls
An anti-phishing policy is a Defender for Office 365 policy object - not an Exchange cmdlet, not a transport rule. It lives at Email & collaboration -> Policies & rules -> Threat policies -> Anti-phishing under our managed Microsoft 365 baseline [^1]. Inside one policy you get five blades; the default tenant has only two turned on:
- Spoof intelligence - on by default for every cloud mailbox.
- Unauthenticated sender indicators - the “via” tag and the question mark on the sender photo - on by default.
- Mailbox intelligence - off unless you turn it on, and only with a Defender for Office 365 Plan 1 or Plan 2 license.
- User impersonation protection - off. You populate a “users to protect” list, capped at 350 addresses per policy [^1].
- Domain impersonation protection - off. You populate a “domains to protect” list, capped at 50 domains per policy [^1].
The 350 ceiling is what catches most admins off guard. Many assume M365 protects “any address in this org.” It does not. If the AP supervisor and the CFO are not on the protected list, the policy will not block a wire-fraud email that names either of them.
”How do I know if the default Standard preset is actually enough?”
Open the anti phishing policy. If the toggle says Standard preset security policy, here is what is happening on each blade, straight from Microsoft’s own recommendations page [^2]:
| Blade | What Standard Does | What Strict Does | Who We Put On This |
|---|---|---|---|
| User impersonation protection | Quarantine the message | Quarantine the message | AP, AR, treasury, CFO, exec assistant, wire-desk custodians |
| Domain impersonation protection | Quarantine the message | Quarantine the message | Accepted domain, top ten partner domains, top bank and EHR vendors |
| Mailbox-intelligence impersonation | Move to Junk Email | Quarantine the message | Finance, AR, payroll, and exec roles |
| Spoof protection | Move to Junk Email | Quarantine the message | Whole tenant (already on) |
Two things jump off that table. First, on the impersonation of specific users or domains Microsoft sets the same action (Quarantine) on Standard and Strict - so a properly populated Standard covers Tiers 1 and 2. The presets differ on the AI-derived signals - mailbox intelligence and spoof - which are exactly the BEC and vendor-impersonation paths that drove most of the $3.046 billion the FBI IC3 reported for Business Email Compromise losses in 2025 [^3]. Second, on Standard an AI-flagged mailbox-intelligence hit lands in Junk; on Strict it lands in Quarantine where an admin can release it. For finance we default to Strict because “let the user click Allow on Junk” is the pattern in every BEC recovery we have done.
Most admins miss one more thing: priority. Custom policies run by numeric priority, and the default sits at the lowest priority. The first matching policy wins; no other policy runs [^1]. So your priority-1 custom policy with a populated protected-users list is doing real work. If that list is empty on the Strict preset, it is not.
Why the 350 cap shows up first in K-12 and county government
The 350 limit is a Microsoft product constraint, not a Datapath limit [^1]. We see it hit in K-12 districts with many building admins and substitutes, and in county governments with many sworn and civilian staff. Our rule is “we have a role-based priority stack”:
- Tier 1 - never miss. AP, AR, treasury, CFO, controller, exec assistant, AP shared mailbox, wire-desk custodian. Keep it under twenty.
- Tier 2 - almost never miss. HR, payroll, benefits, K-12 superintendent, CIO/CTO, anyone on the public org chart.
- Tier 3 - defended by domain impersonation. Every other employee, covered by the 50-domain list, not the user list.
Why split Tier 3 that way? Domain impersonation protects display names on a look-alike domain - the AI-era BEC pattern the FBI flagged when it noted that chat generators quickly create official-sounding emails mimicking a company’s CEO or other officials [^4]. It does not catch a look-alike local-part on a real authenticated domain ([email protected]), but mailbox intelligence covers that.
Anti-impersonation and mailbox intelligence are not redundant
Both tabs are off in the default tenant. Both sit in the same policy blade. They do different jobs. User impersonation fires on a hardcoded address list - precise, but exhaustive to maintain. Domain impersonation fires on a hardcoded domain list - same lesson scaled. Mailbox intelligence is the AI path: it watches each mailbox’s contact graph and flags messages that look plausible but the graph says the recipient has not actually heard of. Hits surface in the Impersonation insight panel, which tracks the prior seven days of detected messages [^5].
For any tenant above roughly 100 employees the production configuration is:
- Custom anti phishing policy Office 365 at priority 1, with users-to-protect populated per the tier stack and domains-to-protect set to your accepted domain plus ten to twenty top partner domains.
- Mailbox intelligence: On, with the impersonation action at Quarantine (Strict-level), and “Enable intelligence-based action for impersonation” also On.
- All other employees covered by domain impersonation and mailbox intelligence, not by a user-list entry we have no slot for.
False positives will happen. The audit-friendly configuration is Quarantine as the action, retention matched to your longest regulated discovery window, and the Quarantine digest on so users can self-release.
”What does the impersonation insight tell our team inside that seven-day window?”
Impersonation insight is most admins’ blind spot. On week one of a rollout we look at three things:
- A spike in Domains - look-alike domains that just started sending. Most are legitimate (a partner switched providers); one or two are usually the campaign.
- A spike in Users - look-alike display names hitting execs. Almost always suspicious.
- Mailbox-intelligence hits above the receiver’s normal contact frequency.
A real walk-through from last quarter: a Stanislaus County public-safety tenant saw three impersonation-insight hits in two days, all targeting the records clerk from look-alike domains. None reached her because they were quarantined. The county’s CJIS Security Policy obligates literacy training on recognizing and reporting potential and actual instances of social engineering and social mining [^6]. We used those three hits as the next month’s training artifact - the better outcome for the auditor, the clerk, and the Sheriff’s Chief Deputy.
How this maps to a regulated tenant in our territories
Running an anti phishing policy Office 365 in production for a regulated tenant means three things, not a single enable-button: a regulated scope (AP/finance and records on a priority-1 custom policy, routine staff on the Strict baseline), an evidence trail (default Defender policy stays on so missing-state is unavoidable; the custom policy on top adds monitoring and review), and a documented acceptance test (synthetic impersonation email across protected and unprotected roles, quarantine observed, result recorded in the change ticket).
For California credit-union and Central Valley banking tenants we also turn on ACH positive pay at the bank so the M365 tenant and the bank reconcile independently [^7]. Anti-impersonation catches the email before the wire is initiated; positive pay catches it before funds settle. Two controls, two different operators, the same end point.
For Ohio healthcare and clinic tenants the policy lives inside our HIPAA-aligned Microsoft 365 baseline, with the users-to-protect list scoped to the EHR access-control admin, the privacy officer, and the billing manager whose name sits in the public Notice of Privacy Practices. For K-12 districts, the policy lives inside our A5 Education Tenant configuration with the superintendent and AP supervisor on the list, principals covered by domain impersonation, and a monthly synthetic impersonation test in the change-management ticket.
FAQ
Is the anti phishing policy Office 365 the same as enabling Defender for Office 365? No. Defender licensed is the prerequisite that lets the impersonation and mailbox-intelligence blades appear [^2]. Configuring the protected-users list is the actual control.
Can one custom policy do all of this tenant-wide? Yes - and the default Office 365 policy does the bare minimum tenant-wide. A single priority-1 custom policy on top of the default is our recommendation. Additional policies split shapes, but priority drives behavior.
Does this replace SAT-style training? No. CJIS and most regulated frameworks treat social-engineering literacy training as a documented requirement [^6]. The policy is the infrastructure under that training: quarterly training, daily policy.
We are on Business Premium - is this available? The user/domain impersonation and mailbox-intelligence blades require Defender for Office 365 Plan 1 or Plan 2 (or M365 E5/F5) [^2]. Most Datapath-managed tenants run E3 with the Plan 1 add-on, or E5.
When this becomes a Datapath conversation
If you read this and recognized your own tenant, the next step is a 30-minute walk-through of Email & collaboration -> Policies & rules -> Threat policies in your M365 tenant. We will show you the live state of your anti phishing policy Office 365 alongside your spoof settings, your SPF/DKIM/DMARC posture, and your protected/empty users list. We do this for credit unions in the Central Valley, dispatch centers in Stanislaus County, clinics in Dublin and Columbus, K-12 districts across our service area, and mid-market businesses of roughly 100-plus employees.
Our existing Microsoft 365 Tenant Hardening Checklist for Mid-Market Businesses covers the adjacency: phishing-resistant MFA, SPF/DKIM/DMARC, basic Defender for Office 365 enablement. What that post does not cover is the impersonation tab specifically - the most important part of any BEC-with-positive-pay story. If your tenant has no name on the protected-users list for AP, AR, and exec roles, that is the gap to close first.
For tenant shapes that see high-volume vendor impersonation we deploy Ironscales as a Datapath-managed AI email layer on top of Microsoft, paired with ACH positive pay at the bank and quarterly social-engineering literacy training. Four independent layers between an impersonated email and a settlement.
If you run a regulated tenant in Modesto, Ceres, Manteca, Merced, Fresno, Irvine, Dublin, Columbus, New Albany, Grove City, Hilliard, or Delaware - or anywhere in between - reach out from our Modesto desk or call 800-838-1488. We will walk your anti phishing policy Office 365 with you, show you the impersonation insight panel live, and tell you exactly where the gaps are.
