Blocking Auto-Forwarding Rules in Exchange Online to Prevent Data Exfiltration

Why Auto-Forwarding Is a Top Data Exfiltration Vector

When a threat actor compromises a Microsoft 365 account, one of their first moves is deceptively simple: set up an email forwarding rule. It's quiet, persistent, and devastatingly effective. Even after a password reset, a hidden forwarding rule keeps silently siphoning sensitive emails to an attacker-controlled address. CISA advisory AA21-008A explicitly calls out malicious email forwarding rules as a key indicator of compromise and a primary exfiltration technique targeting organizations running Microsoft cloud environments [10].

Microsoft 365 provides three distinct forwarding mechanisms: user-configured Inbox rules created through Outlook or OWA, admin-configured mailbox forwarding (commonly called SMTP forwarding), and mail flow rules (transport rules) set at the organizational level [1]. Each represents a potential exfiltration channel — and no single control point can close them all.

Microsoft has moved toward a secure-by-default posture for email protection [8], but defaults alone don't constitute a complete defense. Administrators must verify configurations, layer controls, and implement ongoing monitoring. This article walks through a defense-in-depth approach using three complementary layers of protection, along with auditing strategies to catch forwarding rules that may already be lurking in your environment.

Layer 1: Outbound Spam Filter Policy — The Primary Kill Switch

The outbound spam filter policy in Exchange Online Protection is the broadest and most important control for blocking external auto-forwarding. It acts as a gateway-level enforcement point that applies regardless of how the forwarding was configured — making it the first control every administrator should lock down.

Understanding the Three Settings

The policy offers three options for automatic forwarding [1]:

• Automatic - System-controlled (default): This setting has a complicated history. When first introduced, it behaved like "On," allowing forwarding freely. Microsoft has since progressively changed its effect to match "Off" for all customers, aligning with secure-by-default principles [1].
• On - Forwarding is enabled: Explicitly permits external auto-forwarding with no restrictions from this policy.
• Off - Forwarding is disabled: Explicitly blocks all automatic forwarding to external recipients.

Given that rocky history, best practice is to explicitly set the policy to "Off" rather than trusting the default behavior. Explicit configuration removes ambiguity — and ambiguity is the enemy of security.

Configuring via PowerShell

Use the Set-HostedOutboundSpamFilterPolicy cmdlet to lock down forwarding [2]:

Set-HostedOutboundSpamFilterPolicy -Identity "Default" -AutoForwardingMode Off

If your organization uses custom outbound spam policies scoped to specific user groups, apply the same setting across the board:

Get-HostedOutboundSpamFilterPolicy | Set-HostedOutboundSpamFilterPolicy -AutoForwardingMode Off

What Users See

When a user attempts to forward email externally and the policy blocks it, they receive a non-delivery report (NDR) with error code 5.7.520: "Access denied, Your organization does not allow external forwarding" [1]. The clear wording helps service desk teams quickly identify the cause without escalation.

Scope and Limitations

This policy blocks both user-configured Inbox rules and admin-configured SMTP forwarding that target external addresses [1]. Internal forwarding between users within the organization is unaffected [1], so legitimate internal workflows continue without disruption.

Layer 2: Remote Domain Controls — Domain-Level Granularity

The outbound spam filter policy is effectively all-or-nothing for external forwarding. Remote domain settings fill a different need: domain-level granularity. This matters when your organization needs to permit forwarding to specific trusted partners while blocking everything else.

The Default Remote Domain

Every Exchange Online organization ships with a default remote domain configured as *, which governs all external domains that lack a specific remote domain entry [3]. Disabling auto-forwarding on this default domain establishes a baseline block:

Set-RemoteDomain -Identity "Default" -AutoForwardEnabled $false

With this in place, users can still create forwarding rules in their mailbox — but the messages simply won't be delivered to the external recipient [3]. The rule exists; the exfiltration doesn't.

Creating Exceptions for Trusted Partners

To allow forwarding to a specific partner domain while keeping everything else locked down, create a dedicated remote domain entry:

New-RemoteDomain -Name "TrustedPartner" -DomainName "partner.com"
Set-RemoteDomain -Identity "TrustedPartner" -AutoForwardEnabled $true

This pattern keeps the default restrictive while explicitly allowing only verified business relationships — a classic allowlist approach.

How Remote Domains Interact with Other Controls

A critical interaction rule governs these layers: when one control allows forwarding but another blocks it, the block wins [1]. If you allow forwarding to a partner domain via remote domain settings but the outbound spam filter policy is set to Off, the messages are still blocked.

There's an equally critical limitation: remote domain settings only override user-configured Inbox rules and Outlook forwarding settings. They have no effect on admin-configured SMTP forwarding or mail flow rules [3]. If an administrator sets mailbox forwarding via Set-Mailbox -ForwardingSmtpAddress, messages flow out regardless of remote domain settings. This gap is precisely why a single layer is never enough.

Layer 3: Mail Flow Rules (Transport Rules) — Detection and Response

The third layer fills gaps the first two controls can't address and — more importantly — adds visibility and response capabilities that neither of them offers.

Why Transport Rules Matter

The outbound spam filter policy blocks forwarding silently (aside from the NDR to the sender). Remote domains similarly operate without generating alerts. Transport rules change the equation entirely: they can log forwarded messages, generate incident reports, notify security teams, and trigger custom actions [1]. For any mature security operation, this visibility is non-negotiable.

Detecting Auto-Forwarded Messages

Mail flow rules identify automatically forwarded messages by checking for the X-MS-Exchange-Inbox-Rules-Loop message header [1]. The following PowerShell example creates a rule that blocks and audits auto-forwarded messages to external recipients:

New-TransportRule -Name "Block External Auto-Forward" `
    -HeaderContainsMessageHeader "X-MS-Exchange-Inbox-Rules-Loop" `
    -HeaderContainsWords "." `
    -SentToScope "NotInOrganization" `
    -RejectMessageReasonText "External email forwarding is not permitted." `
    -GenerateIncidentReport "[email protected]" `
    -IncidentReportContent "Sender","Recipients","Subject","Headers"

To enhance an existing rule after initial deployment — for example, adding incident reporting:

Set-TransportRule -Identity "Block External Auto-Forward" `
    -GenerateIncidentReport "[email protected]"

Propagation Delay

After creating or modifying a mail flow rule, allow 30 minutes or more for the change to propagate across the service [5]. During incident response, plan accordingly — don't assume immediate enforcement.

Hybrid Coverage

Organizations with hybrid deployments should note that on-premises users forwarding messages through Microsoft 365 are subject to the same transport rule controls as cloud mailboxes [1]. Policy enforcement remains consistent across the environment.

Auditing for Existing Forwarding Rules

Blocking future forwarding is only half the battle. Threat actors may have already planted forwarding rules during a prior compromise. Proactive auditing is essential to root out these persistent exfiltration channels before they do more damage.

PowerShell Audit with Get-InboxRule

The Get-InboxRule cmdlet lets administrators inspect Inbox rule properties for any mailbox [6]. The following script scans all mailboxes for rules containing forwarding actions:

$mailboxes = Get-Mailbox -ResultSize Unlimited

foreach ($mailbox in $mailboxes) {
    $rules = Get-InboxRule -Mailbox $mailbox.UserPrincipalName -ErrorAction SilentlyContinue

    $forwardingRules = $rules | Where-Object {
        $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo
    }

    foreach ($rule in $forwardingRules) {
        [PSCustomObject]@{
            Mailbox              = $mailbox.UserPrincipalName
            RuleName             = $rule.Name
            ForwardTo            = $rule.ForwardTo
            ForwardAsAttachment  = $rule.ForwardAsAttachmentTo
            RedirectTo           = $rule.RedirectTo
            Enabled              = $rule.Enabled
        }
    }
} | Export-Csv -Path "ForwardingRulesAudit.csv" -NoTypeInformation

Zero in on the three properties that signal forwarding: ForwardTo, ForwardAsAttachmentTo, and RedirectTo [6]. Any rule containing these properties that targets an external address warrants immediate investigation.

The Auto-Forwarded Messages Report

The Exchange admin center includes a built-in Auto-forwarded messages report that breaks down forwarding activity by type (Mail flow rules, Inbox rules, SMTP forwarding), recipient domain, and forwarding user [7]. For organizations that need quick visibility without building custom scripts, this report is a practical starting point.

Keep the data retention limits in mind: the summary page supports queries up to 90 days, the activity page shows only the last 7 days, and the request report feature covers the last 30 days [7].

Automated Insights

Two auto-generated insights surface from the report: "New domains being forwarded email" and "New users forwarding email" [7]. These flag emerging forwarding activity that may indicate a freshly compromised account or a newly created exfiltration rule. Reviewing them weekly is a low-effort, high-value detection habit worth building into your operational routine.

Putting It All Together: A Defense-in-Depth Checklist

Forwarding Control Matrix

The following matrix clarifies which control blocks which forwarding type:

The outbound spam filter policy provides the broadest coverage, blocking both user Inbox rules and admin-configured SMTP forwarding [1]. Remote domains add domain-level granularity but only for user-configured forwarding [3]. Transport rules close the detection and response gap with logging, incident reports, and custom actions.

Hardening Checklist

1. Set the outbound spam filter policy to Off on all outbound policies — both the default and any custom policies.
2. Disable auto-forwarding on the default remote domain (*) and create explicit exceptions only for verified partner domains.
3. Deploy a transport rule to detect and block messages with the X-MS-Exchange-Inbox-Rules-Loop header sent to external recipients, with incident reporting enabled.
4. Run a full Inbox rule audit using Get-InboxRule across all mailboxes to surface existing forwarding rules.
5. Review the Auto-forwarded messages report in the EAC weekly, with particular attention to the new-domain and new-user insights.
6. Schedule recurring PowerShell audits to catch forwarding rules created between reviews.

Incident Response: When You Find Unauthorized Forwarding

Discovering an unauthorized forwarding rule should be treated as a confirmed compromise. Move quickly through these steps:

1. Remove the forwarding rule immediately using Remove-InboxRule or Set-Mailbox -ForwardingSmtpAddress $null.
2. Reset the user's credentials — password and any app-specific passwords.
3. Revoke all active sessions to force reauthentication.
4. Review audit logs to determine the scope of exfiltration: when the rule was created, how much mail was forwarded, and where it went.
5. Hunt for additional persistence — OAuth app grants, device registrations, or secondary forwarding rules on other mailboxes.

Microsoft's secure-by-default settings [8] provide a strong foundation, but they're not a substitute for explicit configuration, layered controls, and continuous monitoring. The three-layer approach outlined here — outbound spam policy, remote domains, and transport rules — closes the major forwarding paths while giving security teams the visibility they need to detect and respond when compromise happens.