Exchange Online Mail Flow Rules Security Guide: Audit Transport Rules for Bypasses and Abuse

One Exchange Online mail flow rule can silently copy, redirect, strip or whitelist every message in a tenant, and most organisations have never reviewed the rule set an administrator built years ago. Mail flow rules, also called transport rules, act on messages in transit before they reach any mailbox, so they sit above every user's inbox rules and alongside the anti-spam and anti-phishing stack. That power makes them a target: attackers with Exchange admin rights use them to collect mail, hide their own spam and remove authentication headers, and well-meant allowlist rules open bypasses that phishing campaigns then walk through. This guide covers how to audit the tenant-wide rule set, which rule patterns are risky, how to build safe bypass rules, and how to detect malicious rule changes. It is for Microsoft 365 administrators, email security engineers and SOC analysts. Inbox rules and mailbox forwarding are covered in How to Audit Mailbox Forwarding and Inbox Rules.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public Exchange Online documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Transport rules outrank inbox rules. They evaluate every message in transit for the whole organisation, so one rule with a broad condition can redirect, Bcc or delete mail for all users.
• SCL -1 is a scoped exception, never a domain allowlist. Microsoft's guidance is to combine the sender condition with an authentication result or a narrow IP range, and never to bypass filtering on sender domain alone.
• Header stripping is an attacker signature. Rules that remove Authentication-Results, DKIM-Signature or Received-SPF headers have been used to hide spam sent through compromised tenants.
• There is no rule history. Exchange Online does not version rule changes, so export the rule collection as a baseline and rely on the unified audit log for who changed what.
• Treat rule management as privileged access. Limit who holds mail flow permissions, require phishing-resistant MFA for them, and alert on New-TransportRule and Set-TransportRule.

How mail flow rules work and why the design matters for security

A mail flow rule has conditions, exceptions, actions and properties. Microsoft documents the logic precisely: multiple conditions are combined with AND, multiple values within a condition with OR, exceptions use OR and override conditions, and all actions apply. A rule with no conditions or exceptions applies to every message. Rules run in priority order, where 0 is the highest priority in PowerShell and older rules rank above newer ones by default. A rule can stop processing of later rules, and some actions, such as deleting the message without notifying anyone or sending to hosted quarantine, end evaluation for that message.

Three properties matter most in an audit:

• Mode: Enforce, Test without Policy Tips (Audit) or Test with Policy Tips (AuditAndNotify). Test modes record matches without affecting delivery, but an incident report action still runs in test mode.
• Severity (SetAuditSeverity): DoNotAudit, Low, Medium or High. Rules set to DoNotAudit do not appear in the Exchange transport rule report, which is a convenient way to hide a rule's activity.
• Activation and expiry dates: a dormant rule with a future ActivationDate looks harmless in a quick review.

Changes can take up to 30 minutes to apply, and Microsoft states that rule changes are not versioned, so there is no built-in way to revert to a previous state. Messages that rules do not process include Exchange-generated NDRs and journal reports, and S/MIME encrypted messages can only be matched on envelope headers.

High-risk actions and what to look for

Every rule in the tenant should be classifiable as low or high risk from its actions alone. The table lists the actions that deserve individual review, using the EAC wording and the PowerShell parameter you will see in Get-TransportRule output.

Rules that combine a broad condition (no condition, "the sender is located inside the organisation", or a single common keyword) with one of these actions are the first to review.

Building safe filtering bypass rules

Bypass rules exist for good reasons: multifunction printers, legacy line-of-business senders and partners whose mail is wrongly filtered. Microsoft's allowlisting guidance ranks the options: Tenant Allow/Block List entries first, then mail flow rules, then Outlook Safe Senders, the IP Allow List in the connection filter policy, and finally allowed sender lists in anti-spam policies. Use a mail flow rule only when the Tenant Allow/Block List cannot do the job.

When a rule is needed, Microsoft's documented pattern is:

1. Condition 1: the sender domain is the specific partner domain.
2. Condition 2 (one of): a message header Authentication-Results includes dmarc=pass or dmarc=bestguesspass, or the source IP is in a narrow range (Microsoft suggests /24 or smaller, never consumer or shared infrastructure).
3. Actions: set SCL to -1 and set a custom header (for example X-ETR) that records why the message bypassed filtering.

What SCL -1 does and does not do is also documented. It asks filtering to skip most spam checks, but malware scanning still applies and high confidence phishing is still not delivered. There is one important exception: if the domain's MX record does not point to Microsoft 365 because mail passes through a third-party gateway first, a bypass rule can allow high confidence phishing into the inbox. Tenants behind a third-party gateway should configure Enhanced Filtering for Connectors rather than rely on a blanket SCL -1 rule for gateway traffic, and the Email security gateway health check covers that layer.

Do not use mail flow rules to deliver phishing simulations or to keep mail flowing to SecOps mailboxes; Microsoft directs both to the advanced delivery policy. Do not bypass filtering for all internal mail either: Microsoft warns that a compromised internal account could then send malicious content unfiltered.

Choosing the right control

Auditing the existing rule set

Run the review read-only first. Nothing below changes configuration.

1. Export a baseline: Export-TransportRuleCollection writes every rule to XML. Store the file with a date and hash; it is the only snapshot you will have, because the service keeps no history.
2. List rules with key properties: Get-TransportRule piped to Format-List shows Name, Priority, State, Mode, SetAuditSeverity, ActivationDate, ExpiryDate, conditions, exceptions and actions for each rule.
3. Classify by action: flag any rule with RedirectMessageTo, BlindCopyTo, AddToRecipients or CopyTo pointing outside accepted domains, SetSCL of -1, RemoveHeader, RouteMessageOutboundConnector or DeleteMessage.
4. Check scope: flag rules with no conditions, conditions on sender domain only, or conditions that match your own accepted domains (Microsoft warns against allowlisting your own or popular domains).
5. Check visibility: flag rules set to DoNotAudit, rules disabled but recently modified, and rules with future activation dates.
6. Find an owner: every rule needs a named owner and a business reason in the Comments property. Rules nobody claims go into test mode for two weeks, then are disabled.
7. Review connectors at the same time: list inbound and outbound connectors, because a rule that routes to a connector is only as trustworthy as the connector.
8. Verify on real mail: check the X-Forefront-Antispam-Report header of a sample of allowlisted messages; SFV:SKN shows the rule's bypass request was honoured and IPV:CAL shows the IP Allow List matched.

For changes, use test mode before Enforce, change one rule at a time, and roll back by restoring the specific rule settings from the exported baseline. Microsoft notes that Import-TransportRuleCollection is being deprecated and its replacement approach removes all existing rules before importing, so rebuild individual rules rather than reimporting the whole collection.

Detecting malicious rule changes

Attackers create transport rules after compromising an account with Exchange admin rights or an app with tenant-wide Exchange management permission. Microsoft's 2022 investigation of malicious OAuth applications describes an attacker who created an inbound connector and twelve transport rules named Test01 to Test012 that removed Received-SPF, DKIM-Signature, ARC-Seal, Authentication-Results and an anti-spam header from every message, so spam sent through the victim tenant was harder to trace and block. The compromised admin accounts had no MFA, and Microsoft's hunting queries looked for apps granted Exchange.ManageAsApp and for new rules removing anti-spam headers.

Audit records for Exchange typically appear 60 to 90 minutes after the event, and retention is 180 days on non-E5 licences and one year by default for Exchange on E5. Forward these events to the SIEM so rule changes can be correlated with sign-in risk. The Email Gateway and Message Trace Detection Guide covers message trace queries for confirming what a suspicious rule touched.

Where identity fits

A transport rule is configuration, but the threat is an identity problem: who can create rules, and which non-human identities hold that power. Review three populations. First, human admins in Organization Management, Exchange Administrator and any custom role group that includes the Transport Rules role; require phishing-resistant MFA and privileged access workstations for them. Second, app registrations with Exchange.ManageAsApp or full_access_as_app, which can manage the tenant without any interactive sign-in; see How to review Microsoft 365 app registrations with mail permissions. Third, automation accounts and scripts that run Exchange Online PowerShell with certificate authentication; their certificates are credentials and need owners and rotation. The Exchange Online Security Guide covers the wider tenant baseline.

Decision guidance for small and large tenants

• Small tenant (one or two admins): keep the rule count low enough to review in one sitting, document each rule in its Comments property, and set an alert on any transport rule operation. A monthly export compared with the last one is enough change control.
• Large tenant (many admins, regional teams): treat the rule set as code. Store the exported collection in version control, require a change ticket for every rule change, and diff the live export against the repository daily. Split rule management into a dedicated role group so helpdesk and regional admins cannot create rules.
• Hybrid with on-premises Exchange: on-premises transport rules and transport agents run on the servers and are reviewed separately; ATT&CK tracks malicious transport agents as T1505.002. See the Microsoft Exchange Server Security Guide.

Measuring the control

• Owned rules: percentage of transport rules with a named owner and business reason (target 100%).
• Bypass hygiene: number of SCL -1 rules whose conditions rely on sender domain alone (target zero).
• External copies: number of rules redirecting or copying mail to external recipients without an approved exception (target zero).
• Change traceability: percentage of transport rule audit events matched to a change ticket.
• ETR override alerts: count of "Phish delivered due to an ETR override" alerts per month, and time to fix the responsible rule.
• Baseline freshness: days since the last exported rule collection was compared with the live state.

Framework mapping

Common failure patterns

• The partner domain allowlist: an SCL -1 rule on a supplier's domain with no authentication condition. Anyone spoofing that domain skips spam filtering, which is exactly how invoice fraud reaches finance staff. The Email Identity and BEC Guide covers the fraud side.
• Allowlisting your own domain: a rule that bypasses filtering for mail "from" an accepted domain, so spoofed internal senders are trusted.
• Orphaned compliance copies: a Bcc rule built for a past investigation that still copies a team's mail to a former employee's mailbox.
• Hidden by severity: a rule set to DoNotAudit, so it never appears in the transport rule report.
• No baseline: after an incident the team cannot tell which rules were changed, because nobody exported the collection and the service keeps no history.
• Header-trust chains: a rule sets a header that a downstream gateway or archive treats as "already scanned", so spoofing that header skips controls.

Practitioner checklist

• Export the transport rule collection today and store it with a date and hash.
• Classify every rule by action and flag redirect, Bcc, external copy, SCL -1, header removal, connector routing and silent delete.
• Rewrite any SCL -1 rule that relies on sender domain alone to require dmarc=pass or a narrow IP range, and add an X-ETR style header.
• Move phishing simulation and SecOps mailbox exceptions to the advanced delivery policy.
• Give every rule an owner and a business reason in Comments; put unowned rules in test mode, then disable them.
• Alert on New-TransportRule, Set-TransportRule and connector changes, and on the "Phish delivered due to an ETR override" policy.
• Restrict mail flow management to a small role group with phishing-resistant MFA, and review apps holding Exchange.ManageAsApp.
• Set the outbound spam policy auto-forwarding control explicitly to On or Off and manage exceptions with remote domains.
• Diff the live rule set against the baseline monthly (small tenants) or daily (large tenants).

Standards and references

• Microsoft Learn: Mail flow rules (transport rules) in Exchange Online
• Microsoft Learn: Mail flow rule actions in Exchange Online
• Microsoft Learn: Manage mail flow rules in Exchange Online
• Microsoft Learn: Use mail flow rules to set the spam confidence level (SCL) in messages
• Microsoft Learn: Create allow lists
• Microsoft Learn: Alert policies in the Microsoft Defender portal
• Microsoft Learn: Control automatic external email forwarding
• Microsoft Security Blog: Malicious OAuth applications used to compromise email servers and spread spam

Related NHI Mgmt Group resources: How to Audit Mailbox Forwarding and Inbox Rules · Exchange Online Security Guide · How to review Microsoft 365 app registrations with mail permissions · Business Email Compromise Response Playbook