CIS Benchmark Email Security Controls in Microsoft 365: The 12 That Matter

By Jonathan Fykes, CTO · Published March 20, 2026 · Last updated April 26, 2026

Where email security lives in the CIS M365 Benchmark

The CIS Microsoft 365 Foundations Benchmark is organized into numbered sections. Email is not a single section. Most of the email-specific recommendations sit in Section 6, which covers Exchange Online and Defender for Office 365. A handful of mailbox-relevant items show up earlier and later in the document, and they matter just as much as the Section 6 work.

The three places to look:

• Section 1 (Account and Authentication Policies) covers the auth posture every mailbox inherits. The two items here that touch email directly are blocking legacy authentication and requiring MFA on every account that can read mail.
• Section 5 (Auditing Policies) covers what gets logged when something happens. Mailbox audit logging and the unified audit log are in this section, and both are how you investigate after a compromise.
• Section 6 (Exchange Online) is the bulk of it: anti-phishing policies, Safe Links, Safe Attachments, outbound spam, forwarding restrictions, and the SPF/DKIM/DMARC trio that authenticates your outbound mail.

The benchmark does not tell you to buy anything new. Every control referenced in Section 6 is configurable inside the Microsoft 365 Business Premium and E3/E5 SKUs that the typical small or mid-sized business already pays for. The work is configuration, not procurement.

One framing note before the controls themselves. CIS uses Implementation Groups (IG1, IG2, IG3) to sequence priority. IG1 is the floor any business should hold. IG2 layers on the stuff a tenant with sensitive data or higher exposure needs. IG3 is the polished, fully tuned version a regulated industry would aim at. We will tag each control by its IG so you know what to do first, second, and last.

Control 1: Disable legacy authentication on every protocol (Section 1, IG1)

This one sits in Section 1 of the benchmark rather than Section 6, but it belongs at the top of an email security article because legacy auth is how most credential-stuffing attacks against mailboxes succeed. POP3, IMAP4, SMTP AUTH, EWS, MAPI/HTTP, ActiveSync basic auth, and a handful of other protocols accept a username and a password without ever prompting for MFA. An attacker with a password from a breach dump just connects, and your MFA prompt never fires.

The CIS recommendation is to disable basic authentication on every protocol via an Exchange Online authentication policy. The flag list is long because Microsoft did not collapse the protocols into one switch. You set each AllowBasicAuth* property to $false, then make that policy the tenant default.

What to verify: a tenant-default authentication policy exists, every basic-auth flag is set to false, and the Conditional Access policy that blocks legacy auth at the identity layer is enabled. Both layers matter because they catch each other when one is misconfigured.

How to verify: in Exchange Online PowerShell, Get-OrganizationConfig | Select DefaultAuthenticationPolicy should return your policy name. Then Get-AuthenticationPolicy <name> | Select AllowBasicAuth* should show every property as False.

What fails by default: tenants provisioned before 2020 still have SMTP AUTH on out of the box. Microsoft retired most basic auth in October 2022, but SMTP AUTH was specifically excluded from that retirement and it remains enabled until you turn it off. The full step-by-step for the Conditional Access policy plus the Exchange Online authentication policy is in how to block legacy authentication in Microsoft 365 on SecureYourTenant.

Control 2: Publish a valid SPF record for every owned domain (Section 6, IG1)

SPF is a TXT record on your domain that lists the IPs and services authorized to send mail as you. Without it, anyone in the world can send a message claiming to be from your domain and the receiving server has no way to check.

The CIS recommendation is to publish an SPF record with a strict ending: -all (hardfail) or at minimum ~all (softfail). The hardfail tells receivers to reject anything not on the list. Softfail tells receivers to mark it suspicious. Hardfail is the target.

A typical Microsoft 365 SPF record for a tenant with one third-party mail platform looks like this:

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

What to verify: every domain you send mail from has an SPF record, the record covers every legitimate sender, and the record ends in -all.

What fails by default: a brand-new M365 tenant gets an onmicrosoft.com domain with the right SPF for that subdomain. Your actual company domain inherits nothing. The SPF record is something you publish at your DNS host (Cloudflare, GoDaddy, Route 53), not something Microsoft creates for you.

The most common gap we see on small-business audits is an SPF record that includes a marketing platform from 2019 that the company stopped using in 2022. Receivers do a DNS lookup, the include resolves nothing useful, and the SPF check inflates toward the 10-lookup limit until SPF starts returning permerror. Audit your includes when you check this control.

Control 3: Enable DKIM signing on every sending domain (Section 6, IG1)

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound message. The receiving server fetches your public key from DNS, verifies the signature, and either accepts the message as authentic or rejects the signature as failed. Unlike SPF, DKIM survives forwarding, because the signature travels with the message instead of being tied to the sending IP.

The CIS recommendation is that DKIM be enabled on every custom domain that sends mail. Microsoft 365 generates the keys automatically the first time you turn DKIM on for a domain, but it does not enable signing by default on custom domains. The default-on case is only the onmicrosoft.com tenant subdomain, which nobody actually sends business mail from.

What to verify: DKIM is enabled in the Defender admin center for every custom sending domain, and both selector records (selector1 and selector2) resolve in DNS.

How to verify (admin center): Defender → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Each domain should show "Signing DKIM signatures for this domain" as enabled.

What fails by default: custom domains. We see this miss on roughly 60 percent of small-business tenants. Someone added the company domain to M365, the keys got generated, and nobody clicked "Enable" because the dialog was easy to miss.

Control 4: DMARC at p=quarantine minimum, p=reject preferred (Section 6, IG1)

DMARC ties SPF and DKIM together. Without DMARC, a message that fails SPF still gets delivered most of the time because the receiving server has no instruction. DMARC publishes the instruction.

A DMARC record has three policy values:

• p=none: receivers report failures to you but deliver the mail anyway. Useful for the first 30 days while you find legitimate senders you forgot about.
• p=quarantine: receivers send failing mail to spam. The CIS minimum.
• p=reject: receivers refuse the message entirely. The CIS preferred state and where you actually want to be.

A clean DMARC record for a small business looks like this:

_dmarc.yourcompany.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s"

What to verify: a DMARC record exists at _dmarc.yourdomain.com, the policy is at least p=quarantine, the rua address points somewhere a human reads, and you have done at least 30 days at p=none before tightening.

What fails by default: a fresh M365 tenant has no DMARC record on the custom domain. You publish it at DNS. The PowerShell snippet at the end of this article checks it for you.

One operational note. The rua reports come back as raw XML and they are unreadable that way. Free aggregators (DMARCian's free tier, Postmark DMARC Digests, MXToolbox) parse them into a readable dashboard. Use one of those. Reading raw DMARC XML by hand is how this control gets ignored after week three.

Control 5: Anti-phishing policy with impersonation protection for executives (Section 6, IG1)

Defender for Office 365 includes an anti-phishing policy that does two specific jobs. User impersonation flags inbound mail where the display name closely matches a protected user but the actual sending mailbox is external. Domain impersonation flags inbound mail from look-alike domains (the classic vendorsupp1y.com versus vendorsupply.com swap).

The CIS recommendation is that an anti-phishing policy be configured with a list of protected users (the executives, the controller, the AP lead) and a list of protected domains (your own primary domain, your largest vendors' domains, your bank). Impersonation matches should be quarantined, not just sent to junk.

What to verify: at least one anti-phishing policy is enabled, the protected user list contains the high-value targets, the protected domain list contains your own domains and your top vendor domains, and the action for impersonation is Quarantine.

How to verify (admin center): Defender → Email & collaboration → Policies & rules → Threat policies → Anti-phishing. Edit the default policy. Check the Impersonation section.

What fails by default: the default anti-phishing policy is on, but the protected users list is empty. Microsoft cannot guess who your executives are. You have to add them by hand. Until you do, the user-impersonation half of the control does nothing.

The full attack-pattern view of why this matters, plus the related controls that backstop it, sits in our companion guide on stopping invoice fraud in Microsoft 365.

Control 6: Anti-spoofing protection enabled (Section 6, IG1)

Anti-spoofing is a related but separate Defender feature. It catches messages where the sender is forging your own domain or a partner domain you have explicitly trusted. Where impersonation protection focuses on display names and look-alike domains, anti-spoofing focuses on cryptographic and SPF/DKIM alignment failures that DMARC alone might let through if your DMARC policy is still at p=none.

The CIS recommendation is that the anti-spoofing toggle inside the anti-phishing policy be enabled tenant-wide.

What to verify: in the anti-phishing policy, "Spoof intelligence" is on and the action for spoofed senders is Quarantine. The "Honor DMARC policy" setting should be enabled for tenants that already have DMARC.

What fails by default: nothing, usually. Microsoft enables anti-spoofing by default in newer tenants. Older tenants and ones where someone manually edited the policy can have it off. Worth checking even if you assume it is on.

Control 7: Safe Attachments with Block + Dynamic Delivery (Section 6, IG1)

Safe Attachments opens email attachments in a sandbox before delivering them. If the file tries to execute code, drop a payload, or call out to a command-and-control IP, Defender blocks the message and the recipient never sees the attachment.

The CIS recommendation is that Safe Attachments be enabled with action set to Block and delivery method set to Dynamic Delivery. Dynamic Delivery sends the message body to the recipient immediately while the attachment finishes scanning, so users get the email without waiting for the sandbox. The attachment then either appears (if clean) or gets quarantined (if malicious).

What to verify: at least one Safe Attachments policy is in place, scoped to all recipients, with action Block and Dynamic Delivery enabled.

How to verify (admin center): Defender → Email & collaboration → Policies & rules → Threat policies → Safe Attachments. Confirm at least one policy with status On and action Block.

What fails by default: Safe Attachments is not on by default in older tenants. Newer tenants get the Built-in Protection preset turned on automatically, which covers Safe Attachments at a baseline level, but the Standard or Strict preset (or a custom policy) is needed for the CIS-aligned configuration.

Control 8: Safe Links enabled tenant-wide (Section 6, IG1)

Safe Links rewrites URLs in incoming mail so that when a user clicks, Microsoft scans the destination at click time. The reason this matters is that attackers commonly send a benign-looking URL that goes live with a phishing payload only after the original message has cleared spam filters. Click-time scanning catches that delayed activation; delivery-time scanning does not.

The CIS recommendation is that Safe Links be on for email, Teams, and Office 365 apps, with the "Track user clicks" and "Do not let users click through to the original URL" options enabled.

What to verify: at least one Safe Links policy is enabled, the scope covers every user, click-tracking is on, and the override option is off (so users cannot bypass the block page).

What fails by default: like Safe Attachments, Safe Links is part of the Built-in Protection preset on newer tenants but not configured to the Standard or Strict preset settings until you opt in.

Control 9: Outbound spam filter with notification on send (Section 6, IG1)

Outbound spam policies do two things. They cap the number of recipients a single account can mail in an hour or a day, and they notify an admin when one of your users starts sending high volumes of suspicious mail. The cap stops a compromised mailbox from being used as a spam cannon. The notification gives you a chance to lock the account before the tenant gets blacklisted.

The CIS recommendation is that the outbound spam filter be configured with sensible per-hour and per-day limits, with notification enabled for unusual sending activity, and the policy applied to all users.

What to verify: the default outbound spam policy has recipient limits set to the tenant-appropriate values (Microsoft's default of 500 per hour and 1000 per day is fine for most), notification is enabled, and the notification address is a security mailbox not a personal account.

How to verify (admin center): Defender → Email & collaboration → Policies & rules → Anti-spam policies → Outbound spam policy (Default).

Control 10: Tenant-wide block on external auto-forwarding (Section 6, IG1)

This is the highest-impact post-compromise control on the list. Once an attacker has access to a mailbox (whether through credential theft, OAuth consent, or a session-cookie steal), the very first thing they do is set up forwarding so they can keep reading mail after the password gets reset. Block forwarding at the tenant level and you cap that blast radius.

The CIS recommendation is that automatic external forwarding be set to Off in the outbound spam policy, applied tenant-wide.

What to verify: in the outbound spam policy, "Automatic forwarding rules" is set to "Off, Forwarding is disabled" rather than "Automatic, System-controlled" or "On."

What fails by default: tenants created before 2020 still have forwarding allowed. Microsoft changed the default for new tenants in 2020 but did not retroactively change older ones. If your tenant predates the policy change and nobody has touched the outbound spam settings, you are probably wide open.

Equally important: the policy blocks new forwarding rules but does not remove the ones that already exist. Inbox rules created before you enabled the block keep running. The PowerShell snippet at the end of the article finds them. The companion guide on email forwarding attacks in Microsoft 365 walks through the cleanup procedure end to end.

Control 11: Mailbox audit logging enabled per mailbox (Section 5, IG1)

Mailbox audit logging records who accessed a mailbox, when, and what they did. After a suspected compromise, the audit log is how you reconstruct what the attacker read, what they sent, and what they downloaded. Without it, your incident response team is guessing.

Microsoft turned mailbox audit logging on by default for every tenant in 2019, and that "Default Audit Set" covers most operations the CIS benchmark cares about. The CIS recommendation is that mailbox auditing not be bypassed for any user (some admins disable it for service accounts, which then become a perfect place for attackers to operate undetected) and that the unified audit log be enabled at the tenant level.

What to verify: Get-OrganizationConfig | Select AuditDisabled returns False. Get-Mailbox -ResultSize Unlimited | Where-Object { $_.AuditEnabled -eq $false } returns nothing. The unified audit log is searchable in the Microsoft Purview compliance portal.

What fails by default: the unified audit log is on by default in tenants created after 2019 but was off in tenants created before. Service accounts and "no UPN" mailboxes (shared mailboxes, room mailboxes) sometimes have AuditBypassEnabled set to true from a one-time troubleshooting fix that never got reverted. Look for those.

Control 12: Defender for Office 365 active and tuned at the tenant level (Section 6, IG1/IG2)

The previous controls assume Defender for Office 365 is licensed and active. The CIS recommendation here is the wrapper around them: Defender for Office 365 should be enabled tenant-wide via the Standard or Strict preset, or via custom policies that match the preset configurations, and the policies should cover every user without scope gaps.

What to verify: in Defender → Email & collaboration → Policies & rules → Threat policies → Preset security policies, either Standard or Strict is on for Anti-phishing, Anti-spam, Safe Attachments, and Safe Links, and the policy scope is "All recipients."

What fails by default: on most tenants we audit, Built-in Protection is on (it cannot be turned off) but neither Standard nor Strict has been enabled. Built-in Protection is the floor; CIS expects the next tier up. Standard is the right starting point for IG1 and IG2 tenants. Strict is the right target for IG3 tenants and ones with regulatory exposure.

Implementation Group sequencing for the 12 controls

If you are deploying this from scratch, the order matters. CIS uses Implementation Groups specifically so a small business with limited security staff can hit the high-impact items first and worry about the polish later.

IG1, deploy first. Every business should run these:

• Disable legacy authentication (Control 1)
• Publish SPF (Control 2)
• Enable DKIM signing (Control 3)
• Publish DMARC at p=quarantine minimum (Control 4)
• Enable anti-phishing impersonation protection (Control 5)
• Enable anti-spoofing (Control 6)
• Enable Safe Attachments (Control 7)
• Enable Safe Links (Control 8)
• Configure outbound spam (Control 9)
• Block external auto-forwarding (Control 10)
• Enable mailbox audit logging tenant-wide (Control 11)
• Defender for Office 365 Standard preset (Control 12)

That is most of the list. Yes, every IG1 item belongs in the foundation. CIS does not soft-pedal the floor.

IG2, deploy after IG1. Tenants with sensitive data or financial exposure:

• Move DMARC from p=quarantine to p=reject after 30 days of clean reporting
• Add protected domains for your top 25 vendors and your bank to Control 5
• Tighten anti-phishing thresholds from Standard to Aggressive
• Configure Safe Links for Teams and Office apps in addition to email
• Set up DMARC report ingestion (DMARCian, Postmark, or in-house)
• Schedule the forwarding-rule audit query monthly with output emailed to a security mailbox

IG3, deploy after IG2. Regulated industries and high-risk profiles:

• Move from Standard to Strict preset across all Defender policies
• Tune anti-phishing to Most Aggressive for the executive group only (custom policy scope)
• Implement attack simulation training and report on click-through rates monthly
• Integrate Defender alerts with a SIEM and define escalation runbooks
• Implement DLP policies that intersect with mail flow (sensitive label detection on outbound)
• Require admin approval workflow for new OAuth app consent on mailbox scopes

Common gaps we see at the default settings

Roughly half of the small-business tenants we audit show CIS Section 6 controls in a "not configured" state because they are still at the M365 default. That sounds bad, and it is, but it has a specific cause: Microsoft tunes the default settings to maximize compatibility, not security. A new tenant has to ship in a state where every legacy mail client and every old line-of-business app keeps working on day one. The hardening happens after the customer chooses to harden.

The defaults that fail CIS most often:

• SMTP AUTH still allowed on tenants provisioned before 2020 (fails Control 1).
• No DMARC record on the custom domain because Microsoft does not publish DNS for you (fails Control 4).
• Empty protected user list on the default anti-phishing policy because the tenant admin never added executives (fails Control 5).
• Built-in Protection only on Defender, with neither Standard nor Strict enabled (fails Control 12).
• External forwarding allowed on tenants older than 2020 (fails Control 10).
• DKIM enabled on onmicrosoft.com only, not on the custom company domain (fails Control 3).

Each of those failures has a 5-to-30-minute fix once you know to look. The reason they persist is that nobody looks. The CIS Benchmark is the structured reason to look.

For the broader baseline these 12 controls fit into, including the non-Section-6 items (identity, sharing, MDM), our checklist on Microsoft 365 email security controls sequences the full set by ROI for a 30-to-100-seat business. And if a CIS audit comes back with red marks today, what actually happens after a CIS Benchmark audit failure walks through the consequences and the remediation path.

Three PowerShell checks that cover the high-signal gaps

You can verify the most commonly-missed controls in under 10 minutes with three short scripts. None of them change anything in your tenant. They are all read-only.

Check 1: DMARC record present and policy strength

This one runs from any machine with PowerShell and DNS resolution. No tenant connection needed.

$domain = "yourcompany.com"
$dmarc = Resolve-DnsName -Name "_dmarc.$domain" -Type TXT -ErrorAction SilentlyContinue

if (-not $dmarc) {
    Write-Host "FAIL: No DMARC record found for $domain" -ForegroundColor Red
} else {
    $record = $dmarc.Strings -join ""
    Write-Host "DMARC record: $record"

    if ($record -match "p=reject") {
        Write-Host "PASS: Policy is p=reject" -ForegroundColor Green
    } elseif ($record -match "p=quarantine") {
        Write-Host "PARTIAL: Policy is p=quarantine. CIS minimum met. Move to p=reject." -ForegroundColor Yellow
    } elseif ($record -match "p=none") {
        Write-Host "FAIL: Policy is p=none. Monitoring only. Tighten after 30 days." -ForegroundColor Red
    }
}

Run this against every domain you send mail from, not just the primary. Subdomain takeovers and forgotten brand domains are how attackers spoof you when the primary is locked down.

Check 2: Anti-phishing policy export

Connect to Exchange Online and dump the anti-phishing policy so you can see the protected user list, the protected domain list, and the action settings without clicking through the admin center.

Connect-ExchangeOnline

Get-AntiPhishPolicy |
  Select-Object Name,
                Enabled,
                EnableTargetedUserProtection,
                TargetedUsersToProtect,
                EnableTargetedDomainsProtection,
                TargetedDomainsToProtect,
                TargetedUserProtectionAction,
                TargetedDomainProtectionAction,
                EnableSpoofIntelligence,
                AuthenticationFailAction,
                PhishThresholdLevel |
  Format-List

What to look for in the output: TargetedUsersToProtect should not be empty. TargetedDomainsToProtect should include your own primary domain. The two action fields should be Quarantine, not MoveToJmf (junk). PhishThresholdLevel should be 2 (Aggressive) or higher.

Check 3: Tenant-wide outbound forwarding state

This is the one that most often comes back ugly on audits older than five years.

Connect-ExchangeOnline

# Outbound spam policy: tenant-level forwarding control
Get-HostedOutboundSpamFilterPolicy |
  Select-Object Name, AutoForwardingMode, NotifyOutboundSpam, NotifyOutboundSpamRecipients |
  Format-List

# Mailbox-level forwarding (different from inbox rules)
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward |
  Format-Table -AutoSize

# Inbox rules with external forwarding
$mailboxes = Get-Mailbox -ResultSize Unlimited
$findings = foreach ($mbx in $mailboxes) {
    Get-InboxRule -Mailbox $mbx.UserPrincipalName |
      Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo } |
      Select-Object @{n='Mailbox';e={$mbx.UserPrincipalName}},
                    Name, Enabled, ForwardTo, ForwardAsAttachmentTo, RedirectTo
}
$findings | Export-Csv forwarding-rules-audit.csv -NoTypeInformation

The first command should show AutoForwardingMode: Off. Anything else is a finding. The second command should return zero rows. The third command produces a CSV; any forwarding to a domain that is not yours is a finding worth investigating immediately, because it is the most common indicator that a mailbox is already compromised. The full investigation procedure is in our business email compromise prevention guide.

Where the email controls fit in the rest of the CIS Benchmark

The 12 controls above are the email-specific work. The full CIS Microsoft 365 Foundations Benchmark covers identity, sharing, storage, mobile device management, and tenant-level governance in addition to email, and the email controls are not safe in isolation. An anti-phishing policy with no MFA on the executive accounts is a half-measure. DMARC at p=reject on a tenant where any user can grant OAuth consent to any random app is solving the wrong half of the problem.

Treat this article as the email slice. For the broader implementation path that sequences the entire benchmark for a small business with one or two IT staff (or none), see implementing the CIS M365 Benchmark in a small business on SecureYourTenant. It puts the email controls in the right context and tells you what else has to be true for them to actually defend you.

Common questions

Do I need Defender for Office 365 to meet the CIS email controls, or does the basic Exchange Online filter cover it?

You need Defender for Office 365. Specifically, you need at least Defender for Office 365 Plan 1, which is included with Microsoft 365 Business Premium and most E-plan SKUs. The basic Exchange Online Protection filter does not include Safe Links, Safe Attachments, or impersonation protection. Those three are required for Controls 5, 7, and 8. If you are on a non-Premium Business plan, the upgrade to Business Premium is the lowest-friction way to license what you need.

How long should I leave DMARC at p=none before tightening to p=quarantine?

30 days is the conventional minimum and what CIS implies. Two weeks is the absolute floor and only if you have a small, well-known sender footprint. The point of the monitoring period is to find every legitimate sender that your team forgot about: the marketing platform from 2019, the accountant who emails invoices through their Gmail, the recruitment platform that sends "as you" but does not authenticate cleanly. Move to p=quarantine when the DMARC reports are clean for two consecutive weeks. Move to p=reject after another 30 days at quarantine without complaints.

If we use a third-party email security gateway like Mimecast or Proofpoint, do these controls still apply?

Most of them, yes. The DNS-level controls (SPF, DKIM, DMARC) apply regardless of where mail is filtered, because they live in DNS and any receiver checks them. The forwarding-restriction control applies because it is a tenant-level Microsoft setting, independent of any gateway. The Defender controls (Safe Links, Safe Attachments, anti-phishing impersonation) overlap with what your gateway does and the right approach depends on your mail flow. If your tenant routes mail through the gateway and back into Exchange Online, you typically run Defender in a relaxed configuration to avoid double-scanning. If the gateway is inline only on egress, Defender does the heavy inbound work. Either way, the CIS audit still wants to see the Microsoft-side configuration set correctly, because the gateway can be removed from mail flow at any time.

We use Outlook on shared mailboxes for an AP team. Will blocking external forwarding break our workflow?

No, because shared mailbox notifications and delegation are not the same thing as external forwarding. The CIS control blocks automatic forwarding from your tenant to addresses outside it. Internal forwarding (one mailbox to another inside the same tenant) is unaffected. Shared mailbox access via permissions is also unaffected. The workflow that does break is the legacy "forward all my mail to my home Gmail" pattern, which is exactly what you want to break, because that pattern is also how attackers exfiltrate. If a specific business need requires external forwarding (rare but it happens, usually for an integrator or a phone-system relay), the right pattern is a connector with IP allow-listing, not a tenant-wide policy exception.

How do I tell if my tenant was provisioned before 2020 and inherited the older defaults?

Run Get-OrganizationConfig | Select WhenCreated against Exchange Online. The date that comes back is when the Exchange Online org object was first instantiated, which lines up with when the tenant was created in 99 percent of cases. Anything earlier than mid-2020 means you should explicitly check Controls 1, 10, and 11 for the older default state.