The policy layer decides which protections apply to whom. This is about what those protections do when they run. There are three engines that do the real catching in Defender for Office 365, and the useful way to approach each is not as a wall of settings but as a single consequential decision surrounded by defaults you can mostly leave alone. Get the one decision right in each, and the rest is detail. Get it wrong, and no amount of tuning elsewhere recovers the loss. Teams, which used to sit outside all of this, is now inside the same blast radius, and I will come to why that matters.
Safe Links, and the quiet retreat from rewriting
Safe Links has always worked by rewriting the URLs in your mail, wrapping each one so that a click passes through Microsoft’s checking service before it reaches the destination. That is still the behavior most people picture, and it is still what the presets do. But the platform has been moving, quietly and without a headline, toward a different model, and the choice between the two is the decision that matters in this engine.
The alternative is to leave the URL untouched and check it through an interface at the moment of the click instead, what Microsoft describes as doing the checks by the Safe Links interface rather than by rewriting. The scanning still happens. The link is still evaluated before delivery and again at click time. What changes is that the user sees the real URL rather than a wrapped one, and the tenant avoids the small but real friction that wrapping introduces. Microsoft has made this the default for its built-in protection and for new policies created in the portal, which tells you the direction of travel. The reason it is not simply the answer everywhere is the failure case, and it is worth understanding before you adopt it. The click-time check depends on the mail client being one that supports the interface. In a current, supported version of Outlook it works. In something older or unusual, a link that was clean at delivery and weaponized afterward can be clicked with no check at all. Rewriting does not have that gap, because the wrapped URL routes through the service no matter what opens it.
So the decision is a reading of your own estate. For a population on modern, managed Outlook, the no-rewrite model is clean and defensible. For a population with mixed or legacy clients, rewriting is the more conservative choice precisely because it does not depend on the client cooperating. This is exactly the kind of decision the presets cannot make for you, because they cannot see your client estate, and it is worth making per population rather than tenant-wide.
The scanning still happens either way. What you are choosing is whether protection depends on the mail client cooperating.
Safe Attachments, and the door left open in SharePoint
Safe Attachments detonates files that no signature recognizes, opening them in isolation to watch what they try to do before your users can. For mail, the decision inside it is small and the presets settle it well: unknown attachments are blocked, and the detonation adds latency measured in minutes, which is the price of catching what signatures miss. The more interesting part of this engine is not in the mail at all. It is the same detonation extended to the files sitting in SharePoint, OneDrive, and Teams, and there it hides a door that is open by default.
When you turn on the collaboration protection, detected files are locked in place. A user cannot open, copy, move, or share a file the system has judged malicious. This sounds complete, and it is nearly so, with one gap that Microsoft states plainly and that almost no one closes. By default, a person can still download the blocked file. The lock stops every action except the one that takes the file out of the environment entirely and onto a device where your controls no longer reach. Closing that gap is a single deliberate setting on the SharePoint side, and the reason it is not closed for you is presumably caution about breaking legitimate downloads, but the effect is that a great many tenants run collaboration protection that stops everything except the exfiltration it most needs to stop. Naming and closing that door is the difference between enabling the feature seriously and enabling it nominally.
Anti-phishing, and the intelligence that watches without acting
The anti-phishing engine is where impersonation is caught, and I raised in the policy piece that it ships watching rather than acting. This is where that matters concretely. Mailbox intelligence is the capability that learns each person’s normal pattern of correspondents, so that a message from a sender who has never written to them before, dressed as someone who has, stands out. In the default configuration this learning is switched on and the acting on it is switched off. The system builds the model of normal and then declines to do anything when the model is violated, because the action is a separate setting that defaults to off.
That is the single most common way I find impersonation protection underperforming: not misconfigured, but half configured, learning diligently and acting never. Turning on the action is the decision that matters, and it comes with a companion choice, the phishing threshold, which governs how aggressive the engine is about treating a message as an impersonation attempt. The presets set this for you, more aggressive under Standard and most aggressive under Strict, and those are sound. The point to carry is that impersonation protection is not a switch you flip once. It is a learning system whose output you have to explicitly authorize it to use, and the protected-user and protected-domain lists from the policy piece are what tell it who to watch in the first place.
Underneath all of this sits email authentication, which the built-in layer handles and which is worth one clear statement. Since the middle of 2023, the platform has honored a sending domain’s own published DMARC policy by default, which means that a domain telling the world to reject mail that fails authentication will have that mail rejected rather than quietly delivered to junk. This is on at every level, and it moves a large class of spoofing off your plate entirely, because you are no longer the one deciding what to do with a forged sender. The sender’s own published policy decides, and the platform obeys it.
Teams is now inside the blast radius
For most of this product’s life, Teams was a separate world with its own weak protections, and mail security stopped at the mailbox. That is no longer true, and the change happened faster than most organizations noticed. The same Safe Links and Safe Attachments engines now cover Teams messages and the files shared in them. Zero-hour auto purge, the mechanism that reaches back into already-delivered mail to remove a message that turned out to be malicious, now does the same for Teams chats, pulling a bad message out of a conversation for everyone in it up to two days after it landed.
What makes this worth a section rather than a footnote is that the protections moved down the licensing stack at the start of 2026. Capabilities that were confined to Plan 2, the purge of Teams messages and the administrative quarantine of them, became Plan 1 features applied by default, and user reporting of Teams messages followed shortly after. The practical meaning is that the collaboration surface is now inside the same protection model as mail, governed by the same engines and, increasingly, available at the same tier. Any design that still treats Teams as out of scope for message security is working from a map more than a year out of date. The blast radius grew, and the licensing to cover it grew with it, mostly without anyone having to buy anything new.
Prevention, across all three engines and now across Teams, is the part you buy and configure once. What you do with what it catches, the reports your users file, the quarantine that fills, the investigations a real attack sets off, is the part that never stops, and it is where the product either earns its place or gathers dust. That is operations, and it is next.
Defender XDR
‹ Previous: [D 4.1.1] Build Sheet: Standing Up the Policy Baseline
Next: [D 4.2.1] Build Sheet: Configuring the Protection Stack ›
