Microsoft 365 Email Security Checklist: 30 Items Between Default and Hardened

By Jonathan Fykes, CTO · Published February 21, 2026 · Last updated April 26, 2026

Why a checklist, and why thirty items

Most M365 hardening guides are written as runbooks: do this, then this, then this. That works once. It does not work the third time someone in your tenant turns off a setting "just to test something" and forgets to turn it back on.

A checklist does a different job. It tells you the steady-state. The 30 items below are what should be true about your tenant on any random Tuesday. If one of them flips, that is a finding, and the audit trail tells you who flipped it and when.

Three things to know before you start. First, almost every item assumes Microsoft 365 Business Premium or an E-plan SKU with Defender for Office 365 Plan 1. Items 11 through 16 (Defender) require it. If you are on Business Standard, you can do everything else and bolt on Defender later. Second, the order matters less than the completeness. A tenant with 27 of 30 in place is still missing the three that get exploited. Third, this list is the prevention baseline. If you suspect you are already compromised, work through how to tell if your M365 email is compromised first, then come back here for the rebuild.

Identity layer for email (5 items)

Email security starts before any message hits an inbox. If the wrong person can sign in, no Defender policy in the world will save you.

1. MFA enforcement on every licensed mailbox

Conditional Access policy requiring MFA for all users, all cloud apps. Not "MFA registered." Not "MFA capable." Enforced. Verified by: Entra sign-in logs filtered on "Authentication requirement = single-factor" over the last 30 days. The result should be empty except for break-glass and service accounts.

2. Conditional Access targeting Exchange Online specifically

Beyond the tenant-wide MFA policy, a second Conditional Access policy that scopes Exchange Online with stricter rules: block from non-compliant devices, block from countries you don't operate in, require sign-in risk below medium. Verified by: the Conditional Access What-If tool, simulating a sign-in from an unmanaged device in a country you don't operate in. The result should be "blocked."

3. Legacy authentication blocked tenant-wide

Basic auth on POP3, IMAP4, SMTP AUTH, and the rest of the legacy protocols closes the credential-stuffing door that walks past MFA. The full procedure is on the sister site: how to block legacy auth and the rest of the M365 baseline. Verified by: a Conditional Access policy named something like CA-Block-Legacy-Auth in State = enabled, plus an Exchange Online AuthenticationPolicy with every AllowBasicAuth* field set to False.

4. Break-glass accounts excluded from blocking policies

Two emergency-access accounts that are excluded from every Conditional Access policy that could lock them out. Strong unique passwords (32+ characters), credentials in a sealed envelope or hardware vault, no day-to-day use, monitored for any sign-in event. Verified by: sign-in log filtered on the break-glass UPNs. The only entries should be quarterly check-ins by whoever owns the credentials.

5. Named admin accounts separate from daily-driver mailboxes

Your IT admin's daily mailbox ([email protected]) does not also hold Global Administrator. A separate [email protected] holds the role and is used only when admin work is needed. Privileged Identity Management for just-in-time elevation is the gold standard. Verified by: Get-MgRoleManagementDirectoryRoleAssignment output. No regular-user UPN should hold Global Admin, Exchange Admin, or Security Admin.

Email authentication layer (4 items)

SPF, DKIM, and DMARC tell the rest of the internet whether a message claiming to be from your domain actually is. Without all three aligned, attackers can spoof your brand to your own customers.

6. SPF record covers every legitimate sender

One SPF TXT record on the apex of your sending domain that lists every IP and service authorized to send as you, ending in -all (hard fail). Sample for an M365 tenant that also sends from a marketing platform:

yourcompany.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all"

Verified by: a public SPF lookup tool such as dig TXT yourcompany.com followed by counting the DNS lookups. SPF allows a maximum of ten include: resolutions before failing silently. Most tenants we audit are at twelve and don't know it.

7. DKIM enabled and signing on every sending domain

Microsoft 365 generates DKIM keypairs automatically but does not enable signing on custom domains by default. In Defender → Email & collaboration → Policies → DKIM, each custom domain you send from should show "Signing DKIM signatures for this domain: Enabled" with two CNAME records resolving in DNS. Verified by: sending yourself a test message and checking the headers for dkim=pass.

8. DMARC at p=quarantine minimum, p=reject preferred

A DMARC record published as _dmarc.yourcompany.com with policy at least p=quarantine and aggregate reporting turned on. Stuck-at-p=none is not a baseline. Quick PowerShell verification:

$domain = "yourcompany.com"
$dmarc  = Resolve-DnsName -Type TXT -Name "_dmarc.$domain" -ErrorAction SilentlyContinue |
          Where-Object { $_.Strings -match "^v=DMARC1" } |
          Select-Object -ExpandProperty Strings

if (-not $dmarc) { "FAIL: no DMARC record published"; return }
"$dmarc"
if ($dmarc -match "p=none")        { "WARN: policy is p=none (monitoring only)" }
elseif ($dmarc -match "p=quarantine") { "OK: p=quarantine" }
elseif ($dmarc -match "p=reject")  { "BEST: p=reject" }

Verified by: the snippet above plus a 14-day review of your aggregate (rua) reports through a tool like Postmark DMARC Digests or DMARCian's free tier. Failure-only reports are not enough.

9. DKIM key rotation policy on a schedule

DKIM keys should rotate at least annually. Microsoft 365 supports two selectors per domain so you can rotate without downtime. Verified by: a documented rotation date in your tenant runbook plus the actual rotation evident in DNS history.

Defender for Office 365 (6 items)

Defender ships in most Business Premium and E-plan SKUs. Most tenants we audit have it licensed and unconfigured.

10. Safe Links rewriting URLs in mail and Teams

Safe Links policy applied to all users, with "Rewrite URLs in email" on, "Apply Safe Links to messages sent within the organization" on, and Teams protection enabled. Verified by: hovering a link in any inbound message. The URL should resolve through safelinks.protection.outlook.com.

11. Safe Attachments set to Block + Dynamic Delivery

Safe Attachments policy in Block mode (not Monitor, not Replace, not Off) with Dynamic Delivery so the body of the message reaches the user while the attachment is sandboxed. Verified by: sending an EICAR test file from an external mailbox to a test recipient. The attachment should be removed and a notification sent.

12. Anti-phishing thresholds at Aggressive with named impersonation

Anti-phishing policy with mailbox intelligence on, impersonation protection covering up to 350 named users (CEO, CFO, controller, AP lead at minimum) and 50 protected domains (your own plus your largest vendors and your bank). Threshold set to Aggressive. The impersonation-protection action should be Quarantine, not "move to Junk." This is the layer that catches CEO-impersonation wire-request attacks. The full mechanism is broken down in our BEC prevention guide. Verified by: exporting the policy with the snippet at the end of this section and reviewing the protected-users list.

13. Anti-spoofing enabled with hard-fail on misaligned mail

Spoof intelligence in Defender enabled, with the action for messages from senders that fail composite authentication set to Quarantine. Verified by: Defender → Threat policies → Anti-phishing → default policy → Spoof settings. "Honor DMARC record policy when the message is detected as spoof" should be on.

14. Zero-hour Auto Purge (ZAP) enabled for both mail and phish

ZAP retroactively pulls messages from inboxes when Defender re-classifies them as malicious after delivery. Both ZAP-for-malware and ZAP-for-phish should be enabled in the anti-spam policy. Verified by: Get-HostedContentFilterPolicy. The ZapEnabled field should be True.

15. Attack simulation training scheduled and running

Defender's attack simulation training (or an equivalent third party) sending phishing simulations at least quarterly, with finance-specific scenarios for finance staff. Click-rate trended monthly. Verified by: the simulation history in Defender showing campaigns in the last 90 days.

Quick way to export every anti-phishing policy in your tenant to review thresholds, protected users, and protected domains in one place:

Connect-ExchangeOnline

Get-AntiPhishPolicy |
  Select-Object Name,
                Enabled,
                PhishThresholdLevel,
                EnableMailboxIntelligence,
                EnableMailboxIntelligenceProtection,
                MailboxIntelligenceProtectionAction,
                EnableTargetedUserProtection,
                @{n='ProtectedUsersCount';e={($_.TargetedUsersToProtect).Count}},
                EnableTargetedDomainsProtection,
                @{n='ProtectedDomainsCount';e={($_.TargetedDomainsToProtect).Count}},
                EnableSpoofIntelligence,
                AuthenticationFailAction |
  Export-Csv anti-phish-policy-audit.csv -NoTypeInformation

Forwarding and external behavior (4 items)

Once an attacker has a token, the first move is exfiltration through forwarding. Closing this domain caps the blast radius of a compromised account.

16. External sender warning on every inbound message

Transport rule that prepends [EXTERNAL] to the subject and a warning banner to the body of every message from outside your tenant. The native Outlook "External" tag is helpful but does not show on every client. The transport-rule version is universal. Verified by: sending a message from a personal Gmail to a tenant mailbox. The subject and body should show the warning.

17. Tenant-wide automatic external forwarding restricted

The outbound spam policy in Defender should have "Automatic forwarding rules" set to Off — Forwarding is disabled. This is the single highest-value setting for limiting the damage of a compromised mailbox. The mechanics of why are in our deep-dive on email forwarding attacks in Microsoft 365. Verified by: Get-HostedOutboundSpamFilterPolicy | Select AutoForwardingMode. The value should be Off.

18. Mailbox-level forwarding audited and clean

The tenant-wide block stops new external forwarding. It does not remove existing forwarding rules already in place. A monthly audit of inbox rules and mailbox forwarding addresses catches the ones that pre-date the policy. The PowerShell snippet is in our invoice fraud guide. Verified by: the most recent audit CSV showing zero external ForwardTo, RedirectTo, or ForwardingSmtpAddress entries.

19. SharePoint and OneDrive default sharing tightened

Email security spills into file-sharing security the moment a user emails a OneDrive link. Default external sharing should be set to "New and existing guests" at the most permissive, with link expiration on. "Anyone" links should be off tenant-wide unless there is a documented exception. Verified by: SharePoint admin center → Policies → Sharing, plus Get-SPOTenant | Select SharingCapability,RequireAnonymousLinksExpireInDays.

OAuth and consent (3 items)

OAuth-consent phishing is the attack pattern that bypasses MFA entirely. The user grants an attacker-controlled app permission to read mail; that grant is a long-lived token, not a password, and password resets do not invalidate it.

20. User consent restricted to verified-publisher apps with low-risk scopes

In Entra → Enterprise applications → Consent and permissions → User consent settings, the setting "Allow user consent for apps" should be off, replaced with either "Allow user consent for apps from verified publishers, for selected permissions" or "Do not allow user consent." The default is what gets tenants compromised. Verified by: the same admin screen.

21. Admin consent workflow enabled with named reviewers

Same screen, "Admin consent requests" turned on, with two or three named reviewers who get the requests in their queue. The reviewer is not the only Global Administrator, because that creates a single point of failure. Verified by: Identity governance → Admin consent settings. There should be at least two reviewers and a documented response SLA.

22. App registration restricted to admins

By default, any user can register an application in Entra. This should be off. Entra → Users → User settings → Users can register applications set to No. Verified by: attempting to register an app from a standard user account. The request should be denied. A periodic OAuth review (quarterly is fine) closes the loop on what's already consented to.

Logging and audit (4 items)

Every other control on this list is preventive. This domain is the one that tells you whether a control failed and gives you the evidence trail to investigate, notify, and recover.

23. Unified Audit Log enabled tenant-wide

UAL is on by default for tenants created after 2019, off for older ones. Verified by: Get-AdminAuditLogConfig | Select UnifiedAuditLogIngestionEnabled. The value should be True.

24. Audit log retention extended to 365+ days

Default retention is 90 days for most license tiers, 180 for E5. Most breach investigations span a longer window than that. Either upgrade the license tier or push logs to a SIEM or storage account that holds 365 days minimum. Verified by: Get-AuditConfigurationPolicy for retention or evidence of an export job to long-term storage.

25. Alert policies on the four highest-signal events

Defender alert policies (or Sentinel rules) firing on these events: creation of an inbox forwarding rule that points externally, new OAuth consent grant with mailbox scopes, addition of mailbox permissions (FullAccess, SendAs), and any change to a Conditional Access policy. Verified by: Defender → Policies & rules → Alert policy. All four should be enabled and routing to a real inbox or ticket queue.

26. Weekly alert review by a named role

Someone owns reviewing the alert queue every week, even if it is the IT manager doing it on Friday afternoon. Alerts that no human reads do not protect anyone. Verified by: a documented weekly review log with reviewer name, date, and disposition for each alert.

Process and training (4 items)

Technology controls fail. Process controls catch what technology misses, especially for socially engineered attacks where every system says "valid sender, valid login."

27. Phishing simulation program with quarterly cadence

Already covered as item 15 from the Defender side; the process side is what you do with the results. Click-rates trended over time, follow-up training assigned automatically, repeat clickers escalated to manager review. Verified by: a simulation report from the most recent quarter showing campaign details and remediation actions.

28. Security awareness training with finance-specific content

General awareness training is fine. Finance staff get an additional module on invoice fraud, vendor email compromise, and the wire-verification rule (item 30). The threat surface for an AP clerk is different from the surface for a software engineer. Verified by: the LMS or training platform showing role-based content assignments and completion rates above 95%.

29. Incident response plan covering BEC specifically

The IR plan has a BEC-specific runbook: who calls the bank's wire-recall desk, who notifies cyber insurance, who preserves the audit log evidence, who notifies customers if vendor data was exposed. The full sequence is documented in the 25-step breach-response checklist on BreachShield365. Verified by: a written IR plan reviewed in the last 12 months with named role assignments and contact numbers.

30. Out-of-band wire-verification rule above a defined threshold

Any change to vendor banking information, and any wire above the defined threshold (typically $5,000 to $25,000), requires a verbal callback to a phone number on file from before the change request. Not a number on the new invoice. The number from a previous successfully-paid invoice or the vendor's signed master agreement. This is the one control that does not depend on email, and it is the one that pays for the other 29 the day someone tries to reroute an $84,000 wire. Verified by: a documented payment-controls policy plus a sample of recent wires showing the callback log attached.

A reasonable rollout sequence

Working through 30 items at once is a recipe for burning out and stopping at item 12. The order most teams find tractable:

1. Week 1: identity layer (items 1 to 5). Without this layer the rest is decoration.
2. Week 2: email authentication (items 6 to 9). Most of week 2 is waiting for DNS propagation and DMARC reports to come back.
3. Week 3: Defender for Office 365 configuration (items 10 to 15). This is the heaviest config day.
4. Week 4: forwarding, OAuth, audit (items 16 to 26). Mostly switch flips with one PowerShell audit each.
5. Week 5 onward: process and training (items 27 to 30). These never finish. They become part of how the business runs.

For a 25 to 100 seat tenant, total admin time across the five weeks runs roughly 30 to 50 hours, plus the 14-day DMARC monitoring window before flipping to p=reject. Two weeks of calendar time for the technical layers, two more for training and process documentation.

Insurance carriers, CIS reviewers, and SOC 2 auditors will all ask for evidence of these controls in some form. Most of the verification commands above produce output you can save to PDF and hand over. The carrier-specific mapping is in our companion piece on MFA as a cyber insurance requirement, which extends to the rest of the email-security questionnaire too.

What this baseline actually stops

Done end-to-end, these 30 items close the door on the four attack patterns that drive almost every M365 email loss we see at the small-to-mid-business size:

• Credential stuffing against legacy protocols. Closed by items 1 to 3.
• CEO and CFO impersonation, including invoice fraud and vendor email compromise. Mitigated by items 6 to 13 and 16, stopped cold by item 30. The threat-specific deep-dive lives in our invoice fraud guide.
• Post-compromise data exfiltration via forwarding rules. Closed by items 17 and 18.
• OAuth consent phishing. Closed by items 20 to 22.

It does not close everything. Adversary-in-the-middle phishing kits like Evilginx, which steal post-MFA session cookies, require phishing-resistant MFA (FIDO2 keys, Windows Hello for Business, certificate-based auth) on top of the baseline. Token-replay attacks against compromised endpoints require EDR at the device layer. Insider abuse requires DLP and Information Protection. Those are the next baseline up. The 30 items here are the floor, not the ceiling.

If you want to map this against the CIS framework specifically, the CIS Benchmark email security controls for M365 walks through which CIS Level 1 and Level 2 controls correspond to which item above.

Common questions

Do I need all 30, or can I pick the top ten?

You can pick ten and you will be ahead of most tenants. The catch is that the 30 are interlocking. Skipping audit logging (items 23 to 26) means you lose the evidence trail when something fails. Skipping process controls (items 27 to 30) means a perfectly hardened tenant still wires $84,000 to a money mule because the email looked legitimate. There is no "top ten" that holds together by itself. If you have to phase, do it across weeks, not by cutting items.

We are on Business Basic or Business Standard. Are the Defender items off the table?

Items 10 through 15 require Defender for Office 365 Plan 1, which is bundled with Business Premium and most E-plans, and available as an add-on for the lower SKUs at roughly $2 per user per month. The math almost always favors the upgrade. A single avoided BEC loss covers the next decade of license cost. If the upgrade is genuinely off the table, configure everything else and accept that the phishing-detection layer is weaker than it should be.

How is this different from the CIS Microsoft 365 Foundations Benchmark?

The CIS Benchmark is broader (it covers SharePoint, Teams, OneDrive, and the rest of M365) and stricter on a few specific items. This list is email-focused and pragmatic for a small-to-mid-business that needs the highest-ROI controls without the full 200-page CIS readout. Most CIS Level 1 items related to email are represented here. CIS Level 2 adds device compliance, application control, and information protection that the average 30-seat tenant does not need yet.

How often should I re-verify the whole list?

Quarterly for the technical items (anything verified by a PowerShell command), monthly for the audit-and-alert items (23 to 26), and continuously for process items (27 to 30). The PowerShell snippets above are designed to be saved as scripts you can rerun cold; each one outputs a CSV you can diff against the previous quarter to see what changed.

Where does this leave us if a mailbox does get compromised anyway?

The recovery sequence is documented in detail. Start with the M365 email compromise diagnostic, move to the broader BEC playbook in our BEC prevention guide, and follow the breach-response steps if the incident expands tenant-wide.