If you've worked with me on Microsoft 365 security lately, you know my view: CEO fraud is still the most effective phishing tactic, however good your user training or technical controls are. In almost every tenant I review, impersonation protection is switched on, but it's rarely tuned to the actual risk. Defender's preset anti-phishing policies alone won't cover executives or finance staff. To stop targeted attacks, you have to work out who needs special protection, which domains are at risk and what action Defender should take. You also need to understand why the preset policies leave your VIPs out by default.
Real impersonation protection starts with a custom anti-phishing policy
Start in the Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Anti-phishing. This is where you create a custom policy for your key people, such as executives, board members, finance or HR. Defender does not build the list of protected users and domains from your actual VIPs. You maintain it by hand. That's the main difference from Defender's preset security policies, which apply generic recommendations but never include your organization's own leadership or high-risk mailboxes by default.
In many tenants, better protection is only a few clicks away. You list the critical mailboxes and the domains attackers are likely to spoof. You can also turn on mailbox intelligence for these groups, so senders who don't normally write to your staff stand out more easily.
flowchart TD
Start["Defender portal"] --> Policies["Anti-phishing policies"]
Policies --> VIPs["Add users/domains"]
Policies --> Intelligence["Enable mailbox intelligence"]
Policies --> Actions["Actions (quarantine)"]
Policies --> Tips["Safety tips"]
Policies --> Trusted["Trusted senders"]
VIPs --> Review["Review impersonation insight"]
Figure: The main steps for setting up impersonation protection policies.
Executives are not the only people who need impersonation protection
The most important decision is who gets special protection and for what reason. The CEO is the obvious one, but an attacker after money will impersonate anyone who can trigger a payment: the CFO, finance, HR, and functional mailboxes like "finance@," "board@," or "hr@." In larger environments I usually create several policies, for example one for executives with the strictest quarantine action and a separate one for finance. Add all your internal email domains as well, so attempts to spoof internal addresses are flagged and blocked.
One trap I run into a lot is a list of protected users and domains that goes stale. Executives leave, new finance mailboxes show up, and the anti-phishing policy never changes. A regular review, ideally done together with IT and HR, makes a real difference. If you want help setting priorities, my post Microsoft 365 security baseline: My practical 2025 checklist goes into more detail.
Mailbox intelligence, quarantine and safety tips belong in every VIP policy
Mailbox intelligence is a Defender feature that learns who each user normally corresponds with. That helps it catch a spoofed sender who has never emailed that person before. If you turn it on for VIPs in your anti-phishing policy, Defender has a much better chance of catching a CEO fraud attempt from an attacker with no prior contact with the target.
For the action, I always pick "quarantine" for suspicious impersonation messages. A warning to the user isn't enough for high-risk groups. Safety tips in emails are still useful, because they teach your staff something when a message does get through.
Pro tip: Review your policies on a schedule. After leadership changes or when new shared mailboxes are created, critical addresses are easy to miss, and that's one of the most common reasons CEO fraud attempts get through.
Microsoft documents the policies and settings in Anti-phishing policies in Microsoft Defender and Configure anti-phishing policies.
Trusted senders and the Impersonation insight dashboard need regular attention
Be careful with your trusted senders, the addresses exempted from impersonation detection (external partners with similar names, for instance). It's a trade-off. Add too many and you lose protection, add too few and false positives go up.
The Impersonation insight dashboard is easy to overlook, but it's worth your time. It shows how many VIP impersonation attempts were detected, where blocks happened and where you might need to improve. I check it after major attacks and whenever I change policy settings. Quite often I find something like a CEO alias address that isn't protected because nobody added it to the protected users list. Aliases have to be included explicitly.
Preset policies do not give you VIP protection
A lot of admins rely on Microsoft's preset anti-phishing policies. These do not protect custom VIP lists. They give you a baseline, but not the detail you need against targeted attacks on your leadership or finance team. For impersonation protection that actually works, you have to create your own policies and list every address and domain you want covered.
In most tenants I see, this step is done half-heartedly or not at all, and people only rush to fix it after an incident. Doing it before anything happens can prevent real losses. This is how I usually set it up:
- Custom policy for VIPs and finance with quarantine action
- Review protected users/domains regularly
- Enable mailbox intelligence
- Show safety tips in suspicious emails
- Use trusted senders sparingly
Impersonation protection only works when someone owns it
You can't configure anti-phishing policies once and forget about them. Impersonation protection only does its job if someone maintains it, updates it when the organization changes and checks it regularly, above all for leadership and critical teams. Preset policies are a reasonable starting point, but they will never stop CEO fraud on their own. If this is your responsibility, spend time with the Defender policy options and look at the "impersonation insight" dashboard often. That keeps the risk under control and helps you avoid costly social engineering attacks.
