Exchange Online is where the identity work of the last wave gets tested by strangers. Everything in the Entra baseline defends accounts you own. Mail is the one surface where anyone on the internet can address your organisation directly, unauthenticated, for free, several thousand times an hour. This is the critical tier for that surface: the controls I will not hand over a tenant without, walked in the order the estate depends on them.
The order here differs from the Entra wave deliberately. There I led with privileged access, because the accounts allowed to change the configuration come before the configuration. Here I lead with Data and Email, because that domain is not one control plane among eight for this product. It is what the product is. An Exchange tenant with immaculate audit settings and an unauthenticated sending domain is not a partially finished baseline, it is a mail system anyone can impersonate.
One framing note before the items. Microsoft has spent the last two years moving defaults in your favour, and a baseline written in 2024 now contains recommendations that describe work the service already did. I have flagged each of those where it occurs rather than quietly dropping the row, because the interesting question has usually inverted: the setting is on, and the decision you now own is whether to leave it on and what it breaks.
Data and email: authenticating the thing you send
Email authentication is three records in DNS that together answer one question for every receiver on the internet: is this message really from you. SPF says which hosts may send for the domain. DKIM attaches a signature that survives relaying. DMARC tells receivers what to do when the first two fail and asks them to report back. They are usually taught as a checklist of three tasks. They are better understood as a single assertion of authority over your own name, published somewhere you may not control.
Which is why the first critical item is not a mail setting at all. It is the registrar and DNS hosting account. Every one of these records lives in a zone that some provider hosts and some account can edit, and an attacker with that account rewrites your SPF record and becomes you, authenticated, with your own DMARC policy vouching for the forgery. I have walked into organisations with a textbook DMARC posture and a DNS account secured by a shared password in a spreadsheet. Treat control of the zone as a prerequisite to the records in it, hold it under the same privileged-access discipline as a Global Administrator, and know who else at the registrar can reset it.
SPF, and why I use hard fail
Publish one SPF record per sending domain, naming every legitimate source, ending in -all. Microsoft recommends hard fail rather than soft fail and gives a reason worth repeating, because it is the reason and not the preference that should decide it for you: DMARC treats hard fail and soft fail alike as an SPF failure, but the DMARC policy is effectively ignored for soft-fail results when the message also carries no DKIM signature. Soft fail therefore buys you a permissive result in exactly the case you most wanted a verdict.
Two constraints will shape the record more than your intent does. The ten-lookup limit counts include:, a, mx, exists and redirect and does not count ip4:, ip6: or all, which is why estates with six SaaS senders quietly exceed it and fail open. And you must never flatten spf.protection.outlook.com into literal addresses, because Microsoft’s sending infrastructure rotates them. If you are inheriting an estate rather than building one, start at soft fail while you discover what actually sends, then move to hard fail once the reporting has stopped surprising you. That is a migration path, not a resting place.
Note that CISA’s SCuBA baseline accepts either qualifier for its Exchange Online SPF policy, and says so explicitly. Hard fail is Microsoft’s recommendation defended on the DMARC interaction above, not a compliance requirement. Say which of the two you are citing when a client asks.
DKIM, and the CNAME shape that changed underneath everyone
Enable DKIM signing for every custom domain. The onmicrosoft.com domain is signed by Microsoft already, which is worth knowing for a reason I return to below. For custom domains you publish two selector records and then enable signing, and the ordering matters because enabling before the records resolve simply fails.
The important change is what those records point at. Domains onboarded from May 2025 use a new target format incorporating the domain with dashes, your initial domain prefix, and a partition character Microsoft assigns and you cannot choose. Domains onboarded before that keep the older form ending in your onmicrosoft.com domain, and the two formats cannot coexist for the same selector. The consequence for anyone working from a build guide written before mid-2025 is that a hand-constructed record produces a missing-CNAME status and an afternoon of confusion. Read the values the service gives you and publish exactly those. Microsoft’s own documentation now says never to construct them manually, which is unusually blunt and should be taken literally. One consequence that is a scheduling decision rather than a command. The default key size is still 1024, and moving an existing domain to 2048 is a rotation rather than a setting. The first rotation upgrades only the selector that becomes active next; the other one stays at 1024 until you rotate again. Each rotation takes 96 hours and you cannot start a second while the first is running, so a domain that is already signing needs eight days and a diary entry, not an afternoon.
Two smaller points that come up in every engagement. The default key size is still 1024 bits, and moving to 2048 requires asking for it explicitly at creation or rotation. And if you have a hosting provider proxying your DNS, the proxy must be off for these records or validation never completes.
DMARC, which is the only one of the three that is a decision
SPF and DKIM are configuration. DMARC is a policy statement about what should happen to mail that fails them, and it is the only place in this article where you are asserting something about your own risk appetite rather than switching on a mechanism. The target is p=reject for every domain and subdomain you own. Everything before that is scaffolding.
Start at p=none with aggregate reporting, read the reports for long enough to find the sending sources nobody told you about, then move through quarantine to reject, ramping with the percentage tag if the estate is large and taking low-volume subdomains before the parent domain. Treat p=none as a transitional state with a date attached. An organisation that has been at p=none for three years has not implemented DMARC, it has implemented a reporting feed. Microsoft does not send forensic reports, so the failure-report address buys you nothing from Microsoft receivers and you should not plan around it.
The domain most often missed is the one Microsoft gave you. Your onmicrosoft.com domain ships with SPF and DKIM already configured, which makes it a live, pre-authenticated sending surface in every tenant, and almost nobody publishes a DMARC record for it. If you do not send from it, park it explicitly.
Honouring inbound DMARC, which is now done for you, and the exception that matters
Publishing DMARC protects your name. Honouring other people’s DMARC protects your users. That second half used to be a hardening recommendation and is now the default: the anti-phishing policy honours the sender’s published policy, quarantines on quarantine, and rejects on reject, in the default policy and not only in the presets. If your baseline still tells a reader to enable it, delete the row. The service already did it.
What replaces that row is a harder question and an architectural one. If your MX record points at a third-party gateway sitting in front of Exchange Online, and a great many mid-market estates still do, that honouring applies only when enhanced filtering is enabled on the connector receiving the mail. Without it, mail arrives at Exchange from the gateway’s addresses, the original sender’s authentication is no longer assessable, and the default Microsoft turned on for you silently does nothing. This is not a checkbox with an obvious answer. It is a question about whether the gateway is still earning its place now that the platform underneath it rejects on the sender’s own instruction, and it is the conversation I would rather have than another year of paying for both.
Connect-ExchangeOnline
# What is actually published and signing, per domain
Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector1KeySize,Selector2CNAME,Selector2KeySize
# The inbound half: confirm the default policy is honouring, not just the presets
Get-AntiPhishPolicy | Format-List Name,HonorDmarcPolicy,DmarcQuarantineAction,DmarcRejectAction
# If a gateway sits in front, this is the setting that decides whether the above is real.
# Enhanced Filtering lives on the connector. There is no boolean: EFSkipLastIP $false
# with an empty EFSkipIPs is the disabled state, and it is the default.
Get-InboundConnector | Format-List Name,Enabled,ConnectorType,EFSkipLastIP,EFSkipIPs,EFUsersIdentity and access: the protocols that predate the policy
Exchange carries thirty years of protocol history, and the parts of it that cannot present a modern token are the parts that cannot be protected by anything you configured in the last wave. Conditional Access, risk policies and phishing-resistant strength all assume an authentication flow capable of being challenged. Basic authentication is not, which is why blocking it is not a hardening step but a precondition for the rest of the baseline meaning anything.
Legacy authentication is blocked by default for tenants created since late 2019, through security defaults, and Microsoft now also creates a managed Conditional Access policy to block it, in report-only, and enables it after a notice period unless you turn it off. Deploy your own policy anyway. Not because the platform is failing to block it, but because a control you own, named to your convention, scoped by your exclusions and visible in your own policy set, is a control you can evidence and reason about. A default someone else may change is not a position you have taken.
Shared and resource mailboxes are the other half of this. Every one of them has an account behind it, and that account is a credential nobody rotates attached to a mailbox several people read. New shared mailboxes now have sign-in blocked at creation, which closes the common case, but nothing retroactively fixed the ones your estate created in 2019. Audit for them, block them, and where they are synced from on-premises, disable them there instead, because the cloud object is not where that decision lives.
SMTP AUTH, and a date that moved
Authenticated SMTP client submission using a username and password is the last basic-auth flow standing in Exchange Online, kept alive by scan-to-email, alarm panels, and line-of-business applications written when that was the only option. Microsoft began disabling it by default for newly created tenants during 2020, so most tenants provisioned since then already have it off, and the durable statement is that new tenants get it disabled rather than that a particular date drew the line. Where it is on, it was usually enabled mailbox by mailbox, by an administrator solving a problem in a hurry.
The retirement is real and the date has moved, so be careful which one you are working to. An earlier phased window in the first half of 2026 was withdrawn. The current position is that basic authentication for SMTP AUTH is disabled by default for existing tenants at the end of December 2026, with administrators still able to re-enable it per tenant or per mailbox after that, that tenants created from 2027 never have it at all, and that Microsoft will announce a final removal date during the second half of 2027. Microsoft’s own documentation now carries no dates and defers to the announcement, which tells you the schedule is not settled. Diary the December date, verify it before you act on it, and do not build a client commitment on the withdrawn one.
The critical work is not the switch, it is the inventory. Find what still submits with a password, and move each one deliberately: modern applications to OAuth on the same protocol, anything that can be rewritten to Graph, high-volume internal notification traffic to High Volume Email, and genuinely external bulk delivery to a service built for it. Be honest about the last two. High Volume Email cannot send outside the organisation and now requires consumption billing wired to an Azure subscription before an account sends a single message, which is a commercial decision rather than a configuration one, and it disqualifies it as the default answer. It does buy time, though, and that is worth knowing: it reached general availability in March 2026 and its own basic authentication is supported until September 2028, roughly two years beyond the deadline pressing on everything else. For an estate of devices that genuinely cannot move by December, that gap is the argument for it. The evidence for that inventory does not live in Exchange. It lives in the Entra sign-in logs filtered to the Authenticated SMTP client app, which is the only surface that tells you what actually submitted rather than what is permitted to, and it is corroborated by message trace for the destinations and by whoever owns the application at the other end. The build sheet does that work.
While you are in that inventory, look at Direct Send, which is the unauthenticated path that needs no credential at all: any device on any network can submit to your tenant endpoint as any address in your accepted domains, for internal delivery. It exists for a narrow set of appliance scenarios and it is abused constantly, because it is the path of least resistance for whoever configured the printer. There is now a tenant setting to reject it outright. Most estates should have it on, and the ones that should not are the ones that can name, today, which device depends on it.
Connect-ExchangeOnline
# Org-wide posture
Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Get-OrganizationConfig | Format-List RejectDirectSend
# Explicit per-mailbox overrides only. A $null value inherits the organisation setting,
# so this returns an empty set in a tenant where SMTP AUTH is still enabled org-wide.
# It is a reconciliation, not an inventory. The inventory is in [BP 2.3.1].
Get-CASMailbox -ResultSize Unlimited |
Where-Object { $_.SmtpClientAuthenticationDisabled -eq $false } |
Format-Table PrimarySmtpAddress,SmtpClientAuthenticationDisabled
# Shared and resource mailboxes whose account can still sign in
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails SharedMailbox,RoomMailbox,EquipmentMailbox |
Format-Table PrimarySmtpAddress,RecipientTypeDetails
# The line above lists them. This proves the state, which is not an Exchange property.
Connect-MgGraph -Scopes "User.Read.All"
Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails SharedMailbox,RoomMailbox,EquipmentMailbox |
ForEach-Object {
$u = Get-MgUser -UserId $_.ExternalDirectoryObjectId `
-Property userPrincipalName,accountEnabled,onPremisesSyncEnabled
[pscustomobject]@{
Mailbox = $_.PrimarySmtpAddress
Type = $_.RecipientTypeDetails
SignInAllowed = $u.AccountEnabled
Synced = [bool]$u.OnPremisesSyncEnabled
}
}
# Expected: SignInAllowed = False on every row. A True on a Synced row is fixed
# on-premises, not here, and fixing it here will be overwritten.Monitoring and response: the record you will need later
Every incident I have worked in Exchange Online came down to the same question at the same moment: what did this account actually do, and when. Auditing is the only control in this article that does not prevent anything. It is the one that determines whether the eventual investigation produces an answer or a shrug, and unlike the others it cannot be applied retroactively. Turning it on after the incident tells you nothing about the incident.
The unified audit log is on by default for Microsoft 365 organisations, with an exception that is not a footnote for the estates this series is mostly written about: it is not enabled by default on Business Basic, Business Standard or Business Premium, nor on unmanaged tenants running enterprise trials. That is the entire small and mid-market. Check it rather than assuming it, and check it from the right place, because the property reports as disabled from the compliance-side session even when logging is running. Read it from an Exchange Online session.
Mailbox auditing is separate and is on by default, with the organisation-level setting overriding whatever an individual mailbox says. Public folder and resource mailboxes sit outside that default. One correction worth making explicitly, because it appears in a great many inherited runbooks: the mailbox audit age limit no longer governs retention in Exchange Online. Retention is a Purview concern now, and a script that sets that property is doing nothing at all while reporting success.
Retention itself is a licensing question with three answers. The standard tier keeps records for 180 days, which for most incidents is enough and for a quiet compromise discovered at the next audit is not. The premium tier extends the core workloads to a year, and only the core workloads, and only for users actually licensed for it. Ten years requires a per-user add-on and a configured policy, and it is not retroactive, which means the decision has to be made before you need it rather than at the moment you discover you do.
Last in this domain, and the one most often left at its default: alert recipients. Every tenant ships with alert policies that notify somebody, and in a distressing number of engagements that somebody is a global administrator’s personal mailbox, filtered into a folder, read by nobody. Route them to a monitored queue that a human or a ticketing system actually opens. An alert nobody reads is not a control, it is a record that you were told.
# Run this in an Exchange Online session. From a compliance session it lies.
Connect-ExchangeOnline
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
# Mailbox auditing, org level, which overrides the per-mailbox setting
Get-OrganizationConfig | Format-List AuditDisabled
# Where the alerts are actually going
Connect-IPPSSession
Get-ProtectionAlert | Where-Object { $_.Disabled -eq $false } |
Format-Table Name,NotifyUser,NotificationEnabledThe critical settings, in brief
| Domain | Setting | Set it to |
|---|---|---|
| Data and Email | Registrar and DNS hosting account | Privileged-access discipline, few admins, strong auth, known recovery path |
| Data and Email | SPF, per sending domain | Every legitimate source named, ending -all, inside the ten-lookup limit, never flattened |
| Data and Email | DKIM, per custom domain | Enabled, with the CNAME values read from the service rather than constructed |
| Data and Email | DMARC, per domain and subdomain | p=reject as the target, p=none only as a dated transitional state |
| Data and Email | The onmicrosoft.com domain | DMARC published, parked explicitly if unused |
| Data and Email | Enhanced filtering, where a gateway fronts the tenant | Configured on the inbound connector, or accept that inbound DMARC honouring does nothing |
| Identity and Access | Legacy authentication | Blocked by a Conditional Access policy you own and can evidence |
| Identity and Access | Shared and resource mailbox accounts | Sign-in blocked, on-premises where synced, audited for the historical ones |
| Identity and Access | SMTP AUTH, basic authentication | Off org-wide, per-mailbox exceptions inventoried and dated |
| Identity and Access | Direct Send | Rejected, unless you can name the device that needs it |
| Monitoring and Response | Unified audit log | On, verified from an Exchange session, and never assumed on Business SKUs |
| Monitoring and Response | Mailbox auditing | On at the organisation level; audit age limit is not a retention control |
| Monitoring and Response | Audit retention | Decided against the incident you expect, before you need it |
| Monitoring and Response | Alert recipients | A monitored queue, not an individual’s mailbox |
The next article takes the recommended and optional tiers: threat policies and why I use Microsoft’s presets rather than building my own, where user-reported mail goes, the restrictions worth placing on Outlook, and the retention and archiving decisions that are harder to reverse than they look.
Best Practices
‹ Previous: [BP 2] Exchange Online: The Surface Strangers Can Reach
Next: [BP 2.1.1] Build Sheet: Mail Authentication to Enforcement ›
