What this check looks at
Checks that the standard and strict preset policies protect sensitive accounts against user impersonation, the organisation’s domains against domain impersonation, and key partners’ domains too.
The Standard and Strict preset security policies include impersonation protection, but it protects only what you list: up to 350 users (people whose names attackers would borrow) and up to 50 custom domains (partners whose domains attackers would imitate), plus a setting for the organisation’s own domains. Until people and partner domains are added, user and partner domain impersonation protection does nothing.
The check is not applicable without Defender for Office 365. For each of the Standard and Strict presets it fails if the preset is not set up, if no sensitive accounts are protected against user impersonation, if the organisation’s own domains are not protected, or if no partner domain (one that is not the organisation’s own) is protected, listing every gap.
Impersonation attacks rely on a near match: the managing director’s name on a Gmail address, an accounts address on a domain with an extra hyphen, a supplier’s domain with one letter changed. Without the names and domains to compare against, the filter has nothing to measure the near match by, and judges the message on its content alone, which in invoice fraud is perfectly ordinary.
Why it matters
Lookalike addresses of a director, the company’s own domain or a big supplier are the raw material of invoice fraud. Naming them in the preset policies lets Defender quarantine the lookalikes.
A manufacturer’s accounts team receives an email from its main steel supplier’s finance manager, sent from a domain registered last week that differs from the real one by a hyphen, asking for this month’s payment to go to a new account. It reads like a hundred earlier emails. With the supplier’s domain protected, Defender quarantines it as domain impersonation; without it, it lands in the inbox.
Supplier and director impersonation drives most invoice fraud against UK businesses, and the money is rarely recovered once it has moved on. Adding the names and domains is a short one-off task, plus a review whenever key people or suppliers change.
CISA SCuBA MS.DEFENDER.2.1, 2.2 and 2.3 ask, in both presets, for user impersonation protection for sensitive accounts, domain impersonation protection for the organisation’s own domains, and protection for key partners’ domains. ISO 27001 A.8.7 and A.5.14, CIS Controls v8 9.7, NIST CSF 2.0 PR.PS-01 and NCSC CAF B4.b cover the same ground.
How to fix it
Where: Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Preset security policies
Before you start
- List the senior people and key partner domains to protect (up to 350 users and 50 domains per policy).
Step by step
- Agree the lists with the client. List the people most likely to be impersonated (directors, finance, HR and anyone who approves payments) with their display names and addresses, and the external domains they deal with most: main suppliers and customers, the bank, accountants, solicitors and your own MSP domain. Keep within 350 users and 50 domains per preset.
- Open the Standard preset. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Preset security policies and, under Standard protection, select Manage protection settings. Step through to the impersonation protection pages.
- Add the people to protect. On the page for users to protect, add each person from the list. External people can be included too, such as a key supplier’s finance contact whose name attackers might borrow.
- Add the partner domains. On the page for domains to protect, add each partner domain. Check on the review page that the organisation’s own domains are protected as well, as the check requires both.
- Add trusted senders only where needed. On the trusted senders and domains page, add only senders that are genuinely flagged by mistake, such as a partner sending from a similar-looking subsidiary domain. Finish the wizard and select Confirm, keeping the policy on.
- Repeat for the Strict preset. Under Strict protection select Manage protection settings and add the same users and domains; the check needs them in both presets. Finish and select Confirm.
- Confirm the entries. Open each preset again and review the impersonation pages, or in Exchange Online PowerShell run Get-AntiPhishPolicy | Where-Object { $_.RecommendedPolicyType -in "Standard","Strict" } | Format-List Name, TargetedUsersToProtect, TargetedDomainsToProtect, EnableOrganizationDomainsProtection. The next assessment passes when both presets list users, the organisation’s own domains and at least one partner domain.
What users will notice
Messages impersonating the protected people or domains are quarantined; safety tips appear on look-alike senders.
How to confirm it worked
Preset security policies, Standard and Strict, Impersonation protection: the users, the organisation’s domains and the partner domains are listed.
Frameworks and controls
This check maps to controls in 15 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B4.b Secure configuration |
| DSPT | Standard 9: IT protection |
| DORA | Art. 9 Protection and prevention |
| NIS2 | Art. 21(2)(g) Basic cyber hygiene practices and training |
| Microsoft Cloud Security Benchmark | ES-2 Use modern anti-malware software |
| Zero Trust | Applications |
| SOC 2 | CC6.8 Preventing or detecting unauthorised or malicious software |
| PCI DSS 4.0.1 | 5.4.1 Personnel are protected against phishing attacks |
| NIST SP 800-171 | 3.14.2 Provide protection from malicious code |
| CMMC Level 2 | SI.L2-3.14.2 Malicious Code Protection |
| ISO 27001:2022 | A.8.7 Protection against malwareA.5.14 Information transfer |
| CISA SCuBA | MS.DEFENDER.2.1v1 User impersonation protection for sensitive accounts in both presetsMS.DEFENDER.2.2v1 Domain impersonation protection for the organisation’s domains in both presetsMS.DEFENDER.2.3v1 Domain impersonation protection for key partners in both presets |
| CIS Controls v8.1 | 9.7 Deploy and maintain email server anti-malware protections (IG3) |
| NIST CSF 2.0 | PR.PS-01: Configuration management practices are established and applied |
| NCSC 10 Steps | Architecture and configuration |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Impersonation settings in anti-phishing policies (Microsoft Learn)