Exchange Online mail flow rules: a blind spot worth auditing
Mail flow rules, also known as transport rules, apply to every message in the organisation, and users never see any trace of them. In our audits they pile up over the years, through migrations and successive providers. Some quietly weaken security; others could be used to exfiltrate mail.
Why transport rules deserve attention
A mailbox rule only affects one user, who can see it in Outlook. A transport rule is defined at organisation level in the Exchange admin centre and runs in the transport service, for every message matching its conditions. Nobody outside the Exchange administrators has any reason to look at it.
That is exactly what makes it attractive to an attacker who has obtained an Exchange administration role: a single rule is enough to receive a copy of all of an executive's mail, indefinitely, without ever compromising their mailbox. It also explains why rules accumulate: someone creates one for a one-off need, then forgets it.
Rules that divert mail
Several actions take messages out of their normal path:
- Blind carbon copy the message to another recipient: the original recipient receives the message as usual, and nothing reveals the copy;
- Redirect the message to another address, internal or external;
- Forward for approval to a moderator, who therefore sees the content before the recipient;
- Route through a specific outbound connector, which may send mail through a third-party service.
These actions have legitimate uses: regulatory archiving, oversight of certain flows, a signature tool hosted by a provider. But each one must be documented, justified and assigned to an owner. A hidden copy to an external address with no written explanation should be treated as an incident until proven otherwise.
Rules that weaken filtering
The second family of risky rules concerns filtering. The "set the spam confidence level (SCL)" action with the bypass value (-1) lets messages skip spam filtering. It is often conditioned on the sender's domain: "anything from partner.com is safe".
The problem is that sender addresses are easy to spoof. A rule based solely on the sender domain hands a free pass to anyone impersonating that domain. The same applies to rules based on words in the subject line or on an overly broad IP range. Microsoft applies some "secure by default" protections, notably for malware and high-confidence phishing, but you should not rely on them to make up for an overly permissive rule; check the current behaviour in your tenant.
The right tool for each need. For a provider's phishing simulations or the security team's analysis mailboxes, the advanced delivery policy is designed for exactly that. For a legitimate partner, prefer the Tenant Allow/Block List with time-limited entries over a permanent bypass rule.
Other settings that go unnoticed
Beyond the actions themselves, several details change how rules actually behave:
- priority and the "stop processing more rules" option, which can prevent a security rule further down the list from ever applying;
- exceptions, sometimes broader than the condition itself;
- mode: a rule in test mode does nothing, which can create a false sense of protection;
- rules that remove or modify headers, which can disrupt downstream checks or insert bypass headers;
- disabled rules that are kept around and that any administrator can re-enable with a click.
Reviewing the rules
A review is easier in PowerShell than in the portal. The Get-TransportRule cmdlet lists rules with their state, priority, mode and last modification date. We recommend exporting them with all their conditions, exceptions and actions, then sorting them into three categories: keep and document, fix, delete.
For every rule you keep, record its purpose, who requested it, its technical owner and its review date. On the detection side, the creation and modification of transport rules appear in the audit log as New-TransportRule, Set-TransportRule and Enable-TransportRule operations. An alert on these operations, or at least a regular check, will catch a rule added outside the normal process.
Finally, limit who can create these rules. The "Transport Rules" role is included in broad Exchange role groups; reviewing the membership of those groups is part of the same exercise.
What an audit checks
- A complete inventory of transport rules: enabled, disabled and in test mode.
- Rules that add a hidden copy, redirect, require approval or route to a connector.
- Rules that set a bypass SCL or bypass headers, and their conditions.
- Use of advanced delivery and the Tenant Allow/Block List instead of bypass rules.
- Documentation and an owner for every rule that is kept.
- Monitoring of rule creation and changes in the audit log.
- Members of role groups that hold the Transport Rules role.