The anchor made the case for letting Microsoft own the tuning. This is where that decision meets the machinery, because delegating the values does not relieve you of understanding the structure. The mail policy layer is not a pile of settings to be adjusted. It is a precedence order, and its defining behavior is that the first policy to match a recipient wins outright, with no blending of one policy into another. The whole discipline comes down to knowing which policy speaks for a given person, and making sure it is the one you intended.
What a preset actually is
It helps to be precise about what you are turning on, because the word preset suggests a template you copy and then edit, and that is not what these are. When you enable the Standard or Strict preset, the platform creates real, live policies on your tenant, one set for the built-in security layer and one set for the Defender layer, and it assigns them to the recipients you name. The values inside are fixed and maintained by Microsoft, but the policies themselves are as real as anything you would build by hand. They occupy the precedence order. They win or lose against other policies by the same rules. A preset is a delegation of the settings, not an abstraction floating above the system.
The assignment is where the first useful nuance lives. A preset asks you to name its recipients twice, once for the Exchange Online Protection layer and once for the Defender for Office 365 layer, and these two populations need not be the same. That is more control than most people expect from something billed as a preset, and it is worth using deliberately. You might extend the built-in anti-spam and anti-malware protections to every mailbox while scoping the heavier Defender protections, the detonation and the impersonation work, to the populations that warrant them.
First match wins, and nothing merges
The precedence order runs from most specific to least. The Strict preset sits at the top, then Standard, then any evaluation policies from a trial, then your custom policies in the priority order you assign them, and finally, tied at the bottom, the built-in protection and the default policies. What matters is not the list itself but the rule that governs it. For each type of policy, anti-spam, anti-malware, anti-phishing, Safe Links, Safe Attachments, only the first one that matches a recipient applies to them, and the settings of every other policy of that type are ignored. There is no merging. A user does not receive the strict setting from one policy and the lenient setting from another. They receive exactly one policy of each type, the first to claim them, in full.
This is the rule that surprises people, and it surprises them expensively. An administrator builds a careful custom anti-phishing policy, assigns it, and cannot understand why its settings are not taking effect. The answer is almost always that a preset above it in the order already claimed those users. The resolution runs independently for each policy type, so the same person can draw their anti-spam settings from the Standard preset and their Safe Links settings from a custom policy at the same time, which sounds contradictory until you hold the per-type rule in mind. The mental model that keeps you out of trouble is to stop thinking about settings and start thinking about which single policy of each type owns each person.
Stop thinking about settings and start thinking about which single policy of each type owns each person.
Built-in protection is a floor, not a posture
The built-in protection preset deserves particular suspicion, precisely because it is the one that is on by default and therefore the one people never look at. It provides Safe Links and Safe Attachments to everyone who is not covered by a higher policy, which sounds reassuring until you read what it actually sets. Under built-in protection, users are allowed to click through the warning page to a link the system flagged. Internal mail is not scanned by Safe Links at all. Links are not rewritten. These are not Microsoft’s recommended values. They are the minimum the platform will assert on your behalf so that a licensed mailbox is never left with nothing, and they are meaningfully weaker than what the Standard preset would apply to the same person.
The practical consequence is that relying on built-in protection alone is a posture decision you did not consciously make. If you license Defender for Office 365 and never enable Standard or Strict, your users are protected, but at the floor, with click-through permitted and internal mail unexamined. That may be an acceptable interim state while you stage a rollout. It is not an acceptable destination, and the distinction is worth naming in any design, so that the floor is understood as a floor rather than mistaken for a decision.
The work a preset cannot do
If the presets own the values, the residual work is the part that requires knowledge Microsoft does not have. The largest piece of it is impersonation protection. A preset will protect against lookalike attacks, but it cannot know which of your people are worth impersonating or which external domains you actually do business with. Those lists, the specific executives and finance staff to watch, the domains you own and the partner domains you trade with, are yours to supply, and they are the difference between impersonation protection that fires on the right targets and impersonation protection that is technically enabled and practically blind.
There is a related subtlety that the mechanics piece takes up in full, which is that mailbox intelligence, the feature that learns each person’s normal correspondents, ships in a state where it observes but does not act. The learning is on. The acting on what it learns is a separate switch, and in the default configuration that switch is off. I mention it here because it is the same pattern as built-in protection: a capability that is present, that looks enabled, and that is doing less than its presence implies until you make a deliberate choice.
When custom is justified, and the cost of it
None of this is an argument that custom policies are wrong, only that they are a debt to be taken on deliberately. The legitimate reasons to leave the presets are specific. You might need a particular quarantine experience, where users receive notifications and can request release on their own, which the presets wire in a fixed way you cannot alter. You might need to block mail from certain regions or in certain languages, which presets do not offer. You might want the newer arrangement that routes low-priority bulk mail into a Promotions folder, a capability that is deliberately off inside the presets, so that the only way to give it to a population is to exclude them from the preset and govern them with a custom policy instead. Each of these is a real reason. None of them is a reason to abandon presets wholesale.
When you do go custom, the cost is drift, and the instrument for managing it is the configuration analyzer, which compares your custom policies against the Standard and Strict baselines and tells you where you have fallen behind Microsoft’s current recommendation. It also keeps a history of who changed what and whether the change raised or lowered your posture. Treat that tool as the running audit of the debt you took on when you chose to hand-build, because a custom policy set that no one compares against the baseline is exactly the standing liability the anchor warned about, quietly decaying while everyone assumes it is fine.
The structure is the half of the policy layer that governs authority. The other half is what the individual protections actually do when they fire, and each of them, Safe Links, Safe Attachments, and the anti-phishing engine, carries one decision inside it that matters more than all the others. That is the protection stack, and it is next.
Defender XDR
‹ Previous: [D 4] Defender for Office 365: What Email Security Became
Next: [D 4.1.1] Build Sheet: Standing Up the Policy Baseline ›
