The critical tier was mostly beyond argument. This is where judgment starts: which threat policies to run and who maintains them, where user-reported mail goes and whether anyone reads it, what to stop Outlook doing on a device you do not manage, and how long to keep mail that nobody has asked for yet. These are the items where two competent consultants can reach different answers, so I have given the reasoning rather than only the value.
Threat policies, and the case for not building your own
Use Microsoft’s preset security policies. Standard suits most organisations, Strict raises false positives in exchange for a lower tolerance, and the choice between them is a conversation about who absorbs the cost of a wrongly quarantined message. What matters more than which preset is that you use one at all, and the reason is not convenience.
The usual argument for presets is that Microsoft updates them as its own recommendations change, so your configuration tracks the product without anyone maintaining it. That is true and it is worth having. The stronger argument is one almost nobody makes, and I have watched it bite three estates. The default policies and the presets use different quarantine behaviour. Presets notify end users about the verdicts a user could reasonably act on, and the default policies do not. Under Standard that means high confidence spam, phishing and both impersonation verdicts arrive with a notification; under Strict it extends to everything the preset quarantines. The default policies assign a quarantine policy with notifications off for the same verdicts. Malware, high confidence phishing and Safe Attachments detections are administrator-access only under both, and that is not a gap you can close with permissions, because release of those three is blocked at the platform and a granted release permission silently becomes a request instead. So an organisation that hand-builds custom threat policies, believing it is doing the more rigorous thing, silently ships an estate where nobody is ever told their mail was quarantined. The default quarantine policies are read-only, so you cannot repair it in place. You have to author a custom quarantine policy you did not know you needed. One exception worth checking before you tell a client this: a tenant that predates the quarantine policy model and had end-user notifications switched on in an anti-spam policy carries a legacy notification-enabled policy that the default path still uses, so the older the estate the more likely it is already partly covered.
Precedence is worth knowing precisely, because it is more layered than the four rungs usually described. Strict wins, then Standard, then evaluation policies, then your custom policies in priority order, and then at the same level as each other sit the built-in protection preset and the default policies. Built-in protection is not a tier above the defaults. It sits beside them.
Which leads to the thing to understand about built-in protection, because it is routinely used to justify doing nothing. It is on for everyone, and it is materially weaker than Standard, and the entire difference is in Safe Links. Built-in lets users click through the warning, does not rewrite URLs, and does not apply to internal senders at all. Safe Attachments is identical across all three. So the sentence “everyone is already covered” is true and misleading in the same breath: the people outside a preset are covered by a version of the control with its three most useful behaviours turned off, including protection from a colleague whose mailbox has been taken over.
Impersonation protection is the part of the preset you must populate yourself, because Microsoft cannot know who your executives are. Add the people who get impersonated, with their external addresses as well as internal ones, and add the partner domains you deal with often. Domains you own are protected automatically and do not need listing. The ceilings are 350 users and 50 custom domains per policy, which is generous enough that hitting them usually means the list has stopped being curated. Note this needs Defender for Office 365 rather than the basic protection stack, and note that Plan 1 now reaches E3 and G3, which it did not before. Be careful how you say that to a client, because entitlement and availability are not the same date. The licensing change took effect on 1 July 2026, the rollout began in mid-June, and Microsoft has published two different completion dates for it on two different surfaces. Check the subscription for the Plan 1 service plan rather than a calendar. Check what arrived, as well: the rollout applies Built-in protection automatically, which is Safe Links and Safe Attachments, and Standard and Strict remain something you turn on. The impersonation list in this section is not one of the things that appears by itself. Education tenants are outside the change entirely, and government tenants are on their own timetable. The full shape of Plan 1 against Plan 2, and why the distinction is an operations decision rather than a filtering one, is in [D 4].
Outbound spam sits outside the presets and has to be set separately, though members of a preset are covered by the default outbound policy rather than left bare. The automatic-forwarding control there now behaves identically to the explicit off position, so setting it is about making the position explicit and auditable rather than closing an open door. One trap worth carrying: the compliance baselines check external forwarding at the remote domain, not at the outbound spam policy, so an estate that sets only the policy will fail an assessment while being correctly configured. Set both and understand why they are different surfaces.
Connect-ExchangeOnline
Connect-IPPSSession
# Who is actually in a preset, and which one
Get-EOPProtectionPolicyRule | Format-List Name,State,SentTo,SentToMemberOf,RecipientDomainIs
Get-ATPProtectionPolicyRule | Format-List Name,State,SentTo,SentToMemberOf,RecipientDomainIs
# Both forwarding surfaces, because the assessment checks the second one
Get-HostedOutboundSpamFilterPolicy | Format-List Name,AutoForwardingMode
Get-RemoteDomain | Format-Table DomainName,AutoForwardEnabled
# Quarantine notification reality check
Get-QuarantinePolicy | Format-Table Name,EndUserSpamNotificationFrequency,ESNEnabledUser reporting, and the mailbox nobody chose
Users find phishing your filters missed. That is not a failure of the filters, it is the design working: a reporting channel exists because no detection stack catches everything. What matters is that the channel is one users can find and one somebody reads.
The old add-ins are in maintenance mode and will be deprecated, superseded by the button built into Outlook itself. No deprecation date has been published, so do not invent one for a client, but there is no reason to keep deploying an add-in that is on its way out, and the add-ins now depend on a newer authentication model that older clients do not support. Move to the built-in button and remove the add-ins.
Then set the destination, which is the part that gets skipped. If nobody configures a reporting mailbox, the default submission policy ships blank, and blank means user-reported messages land in a global administrator’s mailbox. Worse, it is not displayed as the destination until after the first report arrives, so an inspection before go-live shows nothing wrong. I have found this in estates where the reports had been arriving for a year, into the inbox of a director who assumed they were spam. Point it at a monitored queue, and treat a report nobody reviews the same way you treat an alert nobody reads.
Device trust: what Outlook may do on a machine you do not manage
For sensitive environments, pair an Outlook on the web mailbox policy set to read-only with a Conditional Access policy using application-enforced restrictions. The effect is that a user on an unmanaged device can read mail in the browser but cannot download attachments to that machine or take the mailbox offline. It is a blunt control and it costs you the lightweight web client, so scope it to the population that warrants it rather than the whole tenant.
Two corrections to how this is usually described. It does not stop printing. It stops downloading and offline mode, and attachments remain viewable in the browser, which is a materially weaker guarantee than the one people believe they have bought. The stricter variant blocks browser viewing too if that is what you actually need. And this is no longer a browser-only control: mailbox policies set for Outlook on the web now govern the new Outlook for Windows as well, which with the classic client on its way out means the blast radius of these settings has quietly grown to the desktop.
In the same policy, turn off the consumer storage connections. Personal cloud storage attached to a corporate mail client is an exfiltration path that leaves no trace in anything you monitor, and it is on by default. This one is cheap, unambiguous and almost never contested by a client once it is explained.
Retention and archiving, where the defaults are the wrong shape
Start with the smallest and least controversial change: extend the deleted-item recovery window from fourteen days to the thirty-day maximum. Fourteen days is shorter than a holiday. It costs nothing, and it is the difference between a self-service recovery and a support ticket that ends badly. Do it on existing mailboxes and on the mailbox plan so new mailboxes inherit it, and know that the plan never reaches back to mailboxes that already exist.
For retention proper, use Purview retention policies as the general instrument and reserve litigation hold for actual legal matters. Microsoft’s own position is now that hold is the older technology and retention is the recommended path, and the practical argument agrees: retention manages both keeping and deleting, while hold only keeps. An estate under indefinite hold with no deletion policy is not being governed, it is accumulating, and someone will eventually have to answer a discovery request against fifteen years of everything.
Archiving deserves more caution than it usually gets, and there is a new behaviour that changes the conversation. Automatic archiving now moves the oldest items out of a primary mailbox once it approaches its quota, on by default per mailbox, and there is no organisation-level enable or disable parameter. What there is instead is a threshold, valid from 80 to 100 and defaulting to 96, and Microsoft states that setting it to 100 disables auto-archiving for the tenant. So the off switch exists, it is just wearing a percentage. Whether or not you consider that desirable, it means item location is now a function of quota pressure rather than of a retention tag you wrote, and that changes what a user sees, what a cached client holds, and where an investigator looks. It also does not provision archives, so a mailbox with archiving enabled and no expansion configured will fill its archive and stop.
Which brings us to the decision I would think hardest about, and the one I have moved into its own article because it is not really a setting. Auto-expanding archiving cannot be turned off once on, and it removes your ability to recover an inactive mailbox afterwards. Enabling it tenant-wide because a handful of mailboxes are large is a permanent trade of leaver recoverability for headroom, made on behalf of every mailbox in the organisation. Enable it where the growth genuinely warrants it. Do not enable it as a default.
Connect-ExchangeOnline
# Deleted item window, existing and future
Get-Mailbox -ResultSize Unlimited | Format-Table PrimarySmtpAddress,RetainDeletedItemsFor
Get-MailboxPlan | Format-Table Name,RetainDeletedItemsFor
# Automatic archiving, which has no organisation-level off switch
Get-OrganizationConfig | Format-List AutoArchivingThresholdPercentage
Get-Mailbox -ResultSize Unlimited | Format-Table PrimarySmtpAddress,AutoArchivingEnabled,ArchiveStatus,AutoExpandingArchiveEnabled
# Outlook on the web policy, which now also governs the desktop client
Get-OwaMailboxPolicy | Format-List Name,ConditionalAccessPolicy,AdditionalStorageProvidersAvailableTenant governance: the objects nobody has looked at since 2018
Every estate past a certain age carries distribution lists that are really project teams, shared calendars that are really a workflow, and public folders that are really a filing system somebody built before there was an alternative. The optional item here is not to convert them. It is to look at them and ask, for each one, whether the work it carries still belongs in a mail product.
Some do. A broadcast list with two hundred recipients and one sender is a distribution list and should stay one. Converting it to a group because groups are newer achieves nothing and costs you a change. The ones worth moving are the collaboration-heavy objects, where a modern workspace gives people the thing they were trying to build out of email. Audit, decide case by case, and resist the vendor instinct to modernise everything because a migration tool exists.
The recommended settings, in brief
| Domain | Setting | Set it to |
|---|---|---|
| Data and Email | Threat policies | Standard preset for most estates, Strict where the tolerance is lower; custom only with a deliberate quarantine policy |
| Data and Email | Impersonation protection | Populated with the people who get impersonated and the partner domains you deal with |
| Data and Email | Outbound forwarding | Explicitly off at the outbound policy, and blocked at the remote domain |
| Monitoring and Response | Reporting add-ins | Removed, replaced by the built-in Outlook report button |
| Monitoring and Response | User reported destination | A monitored queue, explicitly set, never left blank |
| Device Trust | Outlook on the web policy | Read-only plus application-enforced restrictions, scoped to the population that warrants it |
| Device Trust | Consumer storage providers | Disabled |
| Data and Email | Deleted item retention | 30 days, on existing mailboxes and on the mailbox plan |
| Data and Email | Retention instrument | Purview retention policies; litigation hold reserved for live matters |
| Data and Email | Auto-expanding archiving | Only where growth warrants it, never as a tenant default |
| Tenant Governance | Legacy collaboration objects | Audited and decided case by case, not converted wholesale |
The next article covers the part of this baseline that has a calendar attached: what Exchange Online stops doing, when, and which of these choices you cannot take back.
Best Practices
‹ Previous: [BP 2.1.1] Build Sheet: Mail Authentication to Enforcement
Next: [BP 2.3] Exchange Online on a Clock: Retirements and One-Way Doors ›
