By the end of this you have the collaboration protection turned on with the download door closed, a deliberate Safe Links rewrite decision applied where it needs to differ from the preset, and the anti-phishing engine acting on what mailbox intelligence learns rather than merely watching. If you adopted the Standard preset in the previous build, much of the protection stack is already configured for you, so this sheet concentrates on the parts a preset does not cover and the deliberate deviations worth making by hand. Portal walk-through first, then the Exchange Online PowerShell equivalent, and self-tests at the end that prove each engine is live rather than merely configured. Written against the mid-2026 portal and cmdlet set; confirm labels and parameters before a production change.
Before Step 1: the Security Administrator or Organization Management role for the mail policies, the ExchangeOnlineManagement module for the scripted path, and, for the SharePoint step, the SharePoint administrator role and the Microsoft.Online.SharePoint.PowerShell module. Note that the mail and SharePoint commands run in two different PowerShell sessions and cannot share one connection, which the collaboration step calls out where it matters.
Step 1: Turn on collaboration protection and close the download door
This is the step a preset does not do for you, and it is the one with the highest payoff, so it goes first. The collaboration protection is a single global setting rather than a per-policy one. In the portal, open the Safe Attachments page under Threat policies, open its Global settings flyout, and turn on the option named Turn on Defender for Office 365 for SharePoint, OneDrive, and Microsoft Teams. That alone detonates uploaded files and locks the malicious ones in place, but it leaves the door the protection-stack piece named: by default a user can still download a blocked file. Closing it is a separate setting on the SharePoint side, and because it lives in a different administrative surface it is easy to enable the detonation and never close the door.
| Setting | Value | Why |
|---|---|---|
| Turn on Defender for Office 365 for SharePoint, OneDrive, and Microsoft Teams | On | Extends detonation to stored files and locks detected files against open, copy, move, and share. |
| Disallow infected file download (SharePoint) | On | Closes the one action the lock leaves open. Without it, a file the platform has judged malicious can still be pulled onto a device where your controls do not reach. |
As two commands, in two sessions. The first runs in Exchange Online PowerShell, the second in the SharePoint Online Management Shell; they cannot be combined into one connection, so run them separately and do not expect a single script to carry both.
# Exchange Online session: turn on collaboration detonation
Set-AtpPolicyForO365 -EnableATPForSPOTeamsODB $true
# SharePoint Online Management Shell (separate session): close the download door
Connect-SPOService -Url https://contoso-admin.sharepoint.com
Set-SPOTenant -DisallowInfectedFileDownload $trueExpected result: Get-AtpPolicyForO365 | Format-List EnableATPForSPOTeamsODB reads True, and the SharePoint setting reports back True. Allow up to thirty minutes for the collaboration setting to take effect. Failure mode: enabling only the first command, which is the common half-finished state that leaves the download door standing open.
Step 2: Make the Safe Links rewrite decision explicit
The presets rewrite URLs. Built-in protection and new portal-created policies do not. If you want the cleaner no-rewrite experience for a population on modern, supported Outlook, that is a deliberate deviation you build as a custom Safe Links policy scoped above or excluded from the preset. In the portal this is the Safe Links page under Threat policies; the setting that carries the decision is worded Do not rewrite URLs, do checks via SafeLinks API only. Everything else in the table below is the same secure posture the Standard preset would apply.
| Setting | Value | Why |
|---|---|---|
| Do not rewrite URLs, do checks via SafeLinks API only | On for modern-client populations; Off (rewrite) for mixed or legacy clients | The decision that matters. No-rewrite is cleaner but depends on a supported client to do the click-time check; rewriting protects any client because the wrapped URL routes through the service regardless. |
| Apply Safe Links to email messages sent within the organization | On | Internal mail is a real attack path once one account is compromised. Built-in protection leaves this off; do not. |
| Apply real-time URL scanning | On | Detonates suspicious links and links to files at click time rather than trusting the delivery-time verdict alone. |
| Let users click through to the original URL | Off | Built-in protection allows click-through; a serious policy does not let users overrule a malicious verdict. |
New-SafeLinksPolicy -Name "MDO-SafeLinks-Modern" -EnableSafeLinksForEmail $true `
-EnableSafeLinksForTeams $true -EnableSafeLinksForOffice $true `
-ScanUrls $true -DeliverMessageAfterScan $true `
-DisableUrlRewrite $true -EnableForInternalSenders $true `
-TrackClicks $true -AllowClickThrough $false
New-SafeLinksRule -Name "MDO-SafeLinks-Modern" -SafeLinksPolicy "MDO-SafeLinks-Modern" `
-SentToMemberOf "MDO-Scope-ModernClients" -Priority 0Set -DisableUrlRewrite $false for the rewriting posture. Failure mode: a Safe Links rule needs at least one recipient condition and will not save scoped to nobody, and if its priority sits below a preset that already claims the same users, the preset wins and your policy never applies. Allow up to six hours for a new or changed Safe Links policy to take effect.
Step 3: Confirm the anti-phishing engine is acting, not just watching
The Standard and Strict presets turn on both mailbox intelligence and the action that acts on it, so if a population is on a preset this is already handled and you are only verifying. Where a population is on a custom anti-phishing policy, the acting toggle defaults off and you must set it explicitly. In the portal the two settings sit together on the anti-phishing policy’s threshold page: Enable mailbox intelligence, which learns, and Enable intelligence for impersonation protection, which acts. The first without the second is the half-configured state the doctrine piece described.
# For a CUSTOM anti-phishing policy: turn on the action and set the threshold
Set-AntiPhishPolicy -Identity "MDO-AntiPhish-Exec" `
-EnableMailboxIntelligence $true -EnableMailboxIntelligenceProtection $true `
-MailboxIntelligenceProtectionAction Quarantine -PhishThresholdLevel 3
# To verify what any user's effective policy actually does:
Get-AntiPhishPolicy | Format-Table Name,EnableMailboxIntelligence,EnableMailboxIntelligenceProtection,PhishThresholdLevelA threshold of 3 is the more-aggressive setting the Standard preset uses; 4 is the most-aggressive Strict value. The failure mode to check for by eye is a policy where EnableMailboxIntelligence reads True while EnableMailboxIntelligenceProtection reads False, which is the learning-without-acting state that looks fine at a glance and protects no one.
Validation, and the end-to-end tests
Each engine has a test, and one of them is routinely oversold, so be precise about what each proves. The anti-malware layer has a standard test file. Create a plain text file whose only content is the string below, save it as EICAR.TXT, and mail it from an external source to a test mailbox.
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*What this proves is the anti-malware engine, and only that. EICAR is known-signature malware caught upstream; it does not exercise Safe Attachments detonation, which by design targets files nothing has seen before. There is no Microsoft-published test artifact for detonation, so do not present an EICAR pass as proof that Safe Attachments is working. The honest confirmation for Safe Attachments is operational: watch a genuinely unknown file arrive with the short detonation delay, and read its verdict in the reporting.
Safe Links has no sanctioned test URL either, and the demonstration pages people reach for belong to other Defender products. The reliable test uses your own tenant. Send yourself an external message containing a benign link and confirm the behavior you configured: with rewriting on, the URL arrives wrapped in the Safe Links domain; with no-rewrite on, it arrives untouched and the click is checked through the interface. To prove a block end to end without a live malicious link, add a URL of your own to the Tenant Allow/Block List as a block entry, which takes effect within about five minutes, then click it and confirm the block. Either way, the click lands in the advanced hunting UrlClickEvents table, where the Workload column tells you whether it came from email, Office, or Teams and the action column records allow or block.
// Advanced hunting: confirm your test click was recorded and how it was actioned
UrlClickEvents
| where AccountUpn == "[email protected]"
| project Timestamp, Url, ActionType, Workload, IsClickedThrough
| order by Timestamp descThe impersonation self-test from the previous build sheet doubles as the anti-phishing check here: an external send under a protected user’s display name should carry the user-impersonation category in its header and be actioned per the policy. Between them, these tests confirm that the anti-malware layer catches known malware, that Safe Links behaves the way you chose, that the collaboration lock and its closed download door hold, and that impersonation fires on the right names.
Naming convention
Custom protection policies follow the same scheme as the baseline build. A Safe Links policy for modern clients is MDO-SafeLinks-Modern, a custom anti-phishing policy for the executive group is MDO-AntiPhish-Exec, and each rule takes the identical name as its policy. Scope groups stay in the MDO-Scope-<purpose> form. The global collaboration and SharePoint settings have no name to manage, which is itself worth recording in your build notes, because a tenant-wide setting with no policy object attached is the kind of thing that is easy to forget you ever changed.
A worked example
Take an organization that has standardized its head-office staff on current Outlook but still runs a warehouse and field population on an older mail client that predates the Safe Links interface. You leave the whole organization on the Standard preset, which rewrites, and then build one custom Safe Links policy, MDO-SafeLinks-Modern, with no-rewrite on, scoped to MDO-Scope-ModernClients at priority 0 so it wins for that group ahead of the preset. Head office gets the clean, unwrapped experience whose click-time check their supported client can honor; the field staff stay on rewriting, which protects them regardless of what their client can do. The collaboration setting and its closed download door are global and cover everyone at once. Same three engines, one deliberate split, made where the client estate actually required it rather than tenant-wide by reflex.
With the baseline standing and the stack configured, the endpoint spine of this series now has its mail-and-collaboration counterpart fully built as well as argued. The pillar opened by saying the work had moved from tuning to scope, exceptions, and operations. These two builds are that work, done by hand where the platform cannot do it for you. The next pillar in the suite turns from mail to the SaaS estate that sits beside it.
Defender XDR
‹ Previous: [D 4.2] The Protection Stack: What Safe Links, Safe Attachments, and Anti-Phishing Actually Do
Next: [D 4.3] Operating Mail Security: Submissions, Quarantine, and the Queue ›
