Email is still the way in. The overwhelming majority of intrusions I am called to clean up began with a message that someone opened, and nothing about that has changed in the fifteen years of promises that it would. What has changed is the part you configure. The mail filter you used to build by hand, policy by policy, has become a layered platform that Microsoft tunes on your behalf, and the interesting question is no longer how to set the knobs. It is who holds authority over each layer, what that authority costs, and what is genuinely left for you to own.
Three layers, and only one of them was ever yours
Defender for Office 365 is best understood as three layers stacked on the same mail flow, and the distinction between them is a distinction of authority rather than of features. The bottom layer is the built-in protection that every cloud mailbox receives the moment it exists. Microsoft now calls this the built-in security features for all cloud mailboxes, which is a mouthful, but the renaming matters, because it stopped pretending this layer was a product you buy and started treating it as the floor beneath everything. Anti-malware, anti-spam in both directions, connection filtering, the spoofing half of anti-phishing, zero-hour auto purge, quarantine, and the whole apparatus of email authentication live here. You do not license this layer separately and you cannot turn most of it off. It is simply true of any mailbox in Exchange Online.
The first layer you actually pay for is Plan 1, and it is worth being precise about what it adds, because the marketing has always blurred it. Plan 1 is where prevention stops being about reputation and starts being about intent. Safe Attachments detonates files that no signature has seen. Safe Links checks a URL at the moment someone clicks it, not merely at the moment it arrived. And impersonation protection, the set of controls that notices when a message is dressed up to look like your chief financial officer or your bank, exists nowhere below this line. The floor catches what is already known to be bad. Plan 1 is the first layer that reasons about what is trying to look good.
Plan 2 adds a different kind of thing entirely. It does not, for the most part, prevent more. It lets you see and respond. Threat Explorer, campaign views, automated investigation, advanced hunting across your mail, and attack simulation training are the instruments of an operations team, not additional filtering. I make this point early because it reframes the licensing decision that most organizations rush. Plan 1 is a prevention purchase. Plan 2 is an operations purchase. A company with no one to work an alert queue is buying instruments it will never read.
Plan 1 is a prevention purchase. Plan 2 is an operations purchase. A company with no one to work an alert queue is buying instruments it will never read.
The floor rose under everyone, on purpose
The licensing map for this product has always had one trap in it. I set it out in the suite anchor for this series, but it is worth restating because it catches sophisticated buyers. Enterprise Mobility and Security E5, the bundle that so many organizations think of as their security license, contains no Defender for Office 365 at all. It carries identity, device management, and cloud app security, and it stops there. Having it tells you nothing about whether your mail is protected. The rights to Plan 1 and Plan 2 arrive through the Microsoft 365 and Office 365 enterprise suites, through the Defender Suite add-on that Microsoft renamed from E5 Security in late 2025, or through the standalone plans. Office 365 E5 on its own carries Plan 2, which matters for the many organizations that bought the mail suite and never the full Microsoft 365 bundle.
The more consequential shift is recent and quiet. From the middle of 2026 Microsoft began folding Plan 1 into Microsoft 365 and Office 365 E3, a tier that had always sat below the Defender for Office 365 line. This is not a promotion you opt into. Where the entitlement lands it turns on by itself, applying built-in protection to every licensed user, and the rollout is expected to finish over the back half of the year. The presets remain a deliberate choice, but the baseline arrives on its own. I flag it because it inverts an assumption that a great many designs were built on. If your architecture treated the E3 population as unprotected mail that had to be routed somewhere or licensed up, that assumption is expiring, and the safer reading now is that the floor has risen under your whole estate whether or not anyone planned for it.
The tuning stopped being yours, and that is the right outcome
For most of this product’s history, configuring it meant building policies by hand. You created an anti-spam policy, an anti-malware policy, an anti-phishing policy, a Safe Links policy, a Safe Attachments policy, you set several dozen values inside each, and then you owned those values forever. The trouble with owning them is that the threat landscape does not hold still, and a setting that was correct when you chose it quietly becomes wrong as attackers change what they do. Every hand-built policy is a small standing debt, a promise to revisit settings whose reasoning you will not remember.
Microsoft’s answer is the preset security policies, Standard and Strict, and the honest way to describe them is that they take the tuning away from you. Nearly every value inside a preset is fixed, set from what Microsoft observes across its own datacenters, and updated over time without asking. This sounds like a loss of control, and people reflexively reach for custom policies to keep the control they think they are surrendering. My position, after enough of these engagements, is that the reflex is wrong. Adopting the presets is the more defensible design, because the alternative is signing yourself up to chase Microsoft’s threat intelligence by hand for the life of the tenant, and almost no one does that well past the first quarter.
Every hand-built policy is a small standing debt, a promise to revisit settings whose reasoning you will not remember.
This does not make the presets effortless, and pretending otherwise is how people get surprised. There are two things a preset cannot decide for you. The first is scope, meaning who the protection applies to, assigned separately for the built-in layer and the Defender layer, which is more flexibility than it first appears. The second is the impersonation lists, the specific people and domains you want watched for lookalike attacks, because Microsoft cannot know that your chief financial officer is worth protecting or that a particular partner domain is one you actually trade with. Those lists are the real work the presets leave on your desk, and they are exactly the work worth doing carefully rather than quickly.
Secure by default, and the discipline of exceptions
There is a sentence in Microsoft’s own documentation that I treat as the governing principle for this whole product. To keep your organization secure by default, the platform does not allow allowlists or filtering bypass for messages identified as malware or high confidence phishing. Read that as a design commitment rather than a limitation. It means the system is built to refuse the very thing administrators most want to do under pressure, which is to punch a hole for a sender that someone important is complaining about.
The consequence is that overrides become a discipline rather than a habit. There are two sanctioned places for them and no others. The Tenant Allow/Block List is the override plane for senders, URLs, files, and spoofed identities, and its entries are scoped to a verdict and, for the riskier kinds, made to expire, so that a hole you open does not stay open after everyone has forgotten why. The advanced delivery policy is the narrow exception for security operations mailboxes and third-party phishing simulations, where the messages are marked and stay visible in reporting rather than silently whitelisted. What does not belong in the override business is the Exchange transport rule, the connection filter allow list, or the per-user safe sender list. The current product will now show you, on its own dashboard, exactly how much risky mail your legacy allow entries are letting through. When the platform starts scoring your exceptions as risk, the case for keeping them in disciplined, expiring, auditable places is no longer mine to argue. It is made for you.
What is left to own
If Microsoft tunes the filter, licenses the floor automatically, and refuses your worst overrides, then a fair question is what the job actually consists of now. The answer is that the work moved rather than disappeared. It moved to scope, to the exceptions the presets leave open, and to operations, meaning the submissions your users report, the quarantine your policies fill, and the investigations that a real attack sets off. That is a better job than turning knobs, because it is the part that demands judgment, and judgment is the thing you are actually paid for.
The next piece takes the policy architecture apart in detail: how the presets, the custom policies, and the built-in protection stack against one another, which one wins when they overlap, and where the impersonation work has to be done by hand. From there the series moves through the protection stack itself and then into the operational surface. The licensing and the layering are the map. What follows is the terrain.
Defender XDR
‹ Previous: [D 3.4.1] Build Sheet: Proving and Reporting on the Cloud End
Next: [D 4.1] Policy Architecture: Presets, Precedence, and the Work That Remains ›
