CMMC Level 2 Email Forwarding Controls In Exchange Online

Email forwarding looks harmless until it isn’t. One inbox rule can copy Controlled Unclassified Information (CUI) to a personal mailbox, a vendor, or a compromised account. In March 2026, I still see “helpful” auto-forwarding set up during busy projects, then forgotten.

This post is how I implement CMMC email forwarding controls in Exchange Online in a way that helps support CMMC Level 2 expectations (mapped to NIST SP 800-171 Rev 2), without pretending there’s a single magic setting.

How forwarding risk ties back to CMMC Level 2 (without overpromising)

Diagram of internal forwarding, blocked external auto-forwarding, approved exceptions, and monitoring, created with AI.

CMMC Level 2 aligns to 110 practices from NIST SP 800-171 Rev 2. None of them say “block auto-forwarding” word-for-word. However, auto-forwarding is a common path for data to leave your boundary without review, so controlling it helps support several requirements around access control, monitoring, and controlling information flow.

When I map email forwarding controls, I usually point to these NIST families:

• Access Control (AC): limit who can send CUI where, and under what conditions (for example 3.1.1).
• Audit and Accountability (AU): keep records of rule creation, policy changes, and mail flow events (3.3.x).
• System and Communications Protection (SC): monitor and control outbound flows (for example 3.13.6 and 3.13.8).
• System and Information Integrity (SI): detect and respond to suspicious forwarding behavior (for example 3.14.6).

Forwarding also comes in multiple “doors,” and each door needs a latch. This quick table is how I explain it to admins and auditors.

Forwarding path	Common example	Where I control it
Mailbox-level forwarding	ForwardingSmtpAddress set on mailbox	Exchange Online mailbox settings, PowerShell
Inbox rules	Outlook rule forwards to Gmail	Exchange Online inbox rule review, audit alerts
External auto-forwarding	Automatic forward to vendor	Outbound spam policy (EOP/Defender)
Transport behavior	Allowed exception flow	Mail flow rule scoped to approved cases

If you need a plain-language framing for auditors, I like this perspective on controlling the flow of CUI because it matches how real mail systems work.

Baseline: block external auto-forwarding tenant-wide (and prove it)

The cleanest baseline is simple: block external auto-forwarding for everyone by default, then carve out a tiny exception group with tight limits.

Microsoft documents the control under outbound anti-spam policy settings, and I keep that page in my project notes for change reviews: external email forwarding controls in Microsoft 365.

Configure and verify the organization setting (PowerShell)

I usually do this in Microsoft 365 Defender (EOP) first, then I verify with PowerShell so I can hand an export to an auditor.

# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.tld


# Verify outbound spam policies and external auto-forward setting
Get-HostedOutboundSpamFilterPolicy |
  Select-Object Name, AutoForwardingMode, IsDefault |
  Sort-Object IsDefault -Descending

If your default policy isn’t set to block, I set it to Off (block). Use your policy name.

# Block external auto-forwarding (default policy example)
Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode Off

My rule of thumb: if you can’t explain why auto-forwarding must leave the tenant, it shouldn’t.

Find mailboxes that already forward (and turn it off)

Even with org-wide blocking, mailbox-level forwarding is still a red flag because it signals intent, and it often pairs with other risky rules.

# Identify mailboxes with forwarding configured
Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
  Select-Object DisplayName, UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

Then I disable it in a controlled change window.

# Disable mailbox-level forwarding (safe baseline)
Set-Mailbox -Identity "user@yourdomain.tld" `
  -ForwardingAddress $null `
  -ForwardingSmtpAddress $null `
  -DeliverToMailboxAndForward $false

For background on how forwarding differs from redirecting (helpful when admins swear “we didn’t forward”), this explainer is solid: block forwarding in Microsoft 365.

An admin validating forwarding settings with PowerShell, created with AI.

Approved exceptions: allow only what you can monitor, and guard it with Purview

Some teams truly need an exception, for example forwarding from a monitored shared mailbox to a secure ticketing address. In that case, I don’t “open forwarding.” I build a narrow lane with two controls:

1. A scoped outbound spam policy for an exception group (only those senders can auto-forward externally).
2. A mail flow rule that restricts destinations (only approved domains or addresses).

This works in commercial Microsoft 365 and in government tenants, but the portals and endpoints can differ. If you’re in GCC High, I plan extra time for validation because feature release timing and UI paths can vary.

Create a scoped mail flow rule (PowerShell example)

This example blocks external auto-forwarding except for a dedicated exception group, and only to an approved recipient domain. I match on the Auto-Submitted header because it’s a practical way to catch automatic forwards.

# Create an exception group in Entra ID first, then use it here as a distribution group or mail-enabled security group.
# Example: "CMMC-Approved-Autoforward-Senders"


New-TransportRule -Name "CMMC - Block external auto-forward (except approved)" `
  -HeaderMatchesMessageHeader "Auto-Submitted" `
  -HeaderMatchesPatterns "auto-forward" `
  -SentToScope NotInOrganization `
  -ExceptIfFromMemberOf "CMMC-Approved-Autoforward-Senders" `
  -RejectMessageReasonText "External auto-forwarding is blocked by policy." `
  -StopRuleProcessing $true

Then I add a second rule that only allows approved senders to forward to an approved destination pattern.

New-TransportRule -Name "CMMC - Allow approved external auto-forward to ticketing" `
  -HeaderMatchesMessageHeader "Auto-Submitted" `
  -HeaderMatchesPatterns "auto-forward" `
  -FromMemberOf "CMMC-Approved-Autoforward-Senders" `
  -RecipientDomainIs "approved-ticketing.vendor.tld" `
  -SetSCL "-1" `
  -StopRuleProcessing $true

On the Microsoft Purview side, I pair forwarding controls with Sensitivity labels and DLP rules so CUI-like content triggers a block or encryption when it tries to leave. That combination helps support Secure Cloud Architecture goals because it treats email as a controlled channel, not a free exit.

Auditor Evidence Pack (what I retain and how often I review)

I keep an “evidence pack” folder per tenant because audits move fast. Here’s what I export and how often I check it:

• Outbound spam policy screenshot/export (AutoForwardingMode), review quarterly and after changes.
• Transport rule list export (name, priority, conditions, exceptions), review quarterly.
• PowerShell outputs: forwarding mailbox report, exception group membership, review monthly.
• Unified audit log search for mail flow rule changes and admin actions, review monthly.
• Alerting proof for forwarding rule creation or suspicious changes (SIEM or MDR), review weekly if you handle CUI daily.

For detection ideas tied to forwarding rule creation, I sometimes reference guidance like Blumira’s write-up on forwarding and redirect rule findings and map it to whatever SIEM I’m using.

In practice, this work fits into the bigger stack I deliver: Small Business IT, Cloud Infrastructure, Office 365 Migration, Data Center Technology, Restaurant POS Support, Kitchen Technology Solutions, Cybersecurity Services, Endpoint Security, Device Hardening, Innovative IT Solutions, Tailored Technology Services, Cloud Management, Business Technology Partner, Technology Consulting, Infrastructure Optimization, Digital Transformation, IT Strategy for SMBs, Secure Cloud Architecture, Managed IT for Small Business, and Business Continuity & Security.

One-page checklist: CMMC Level 2 email forwarding controls

• Set default outbound spam policy to block external auto-forwarding.
• Export policy proof (screenshot plus PowerShell output) for audit files.
• Report mailbox forwarding (ForwardingSmtpAddress, ForwardingAddress) monthly.
• Remove mailbox forwarding unless an approved exception exists.
• Create an exception group with named owner and ticket-based approval.
• Apply a scoped allow policy only to that group (keep it tiny).
• Add mail flow rules to (a) block external auto-forwarding, (b) allow only approved domains.
• Enable audit logging and verify you can search admin and rule changes.
• Add alerting for new forwarding rules, transport rule edits, and group membership changes.
• Use Purview labels and DLP to stop or protect CUI leaving the tenant.
• Document the business reason for every exception, with expiry date.
• Review exceptions quarterly, remove anything stale.

Closing thought: email forwarding is like a side door on your building. I block it by default, then I install a keypad for the few people who truly need it. That approach, plus monitoring and evidence, helps support CMMC Level 2 without turning Exchange Online into a productivity killer.