Transport rules in Exchange Online — also called mail flow rules — are server-side rules that apply to all email passing through your organisation's mail infrastructure. They operate before email reaches user inboxes, can silently copy, redirect, modify, or delete messages, and apply organisation-wide rather than per-user. This makes them a powerful administrative tool and, in the wrong hands, a powerful exfiltration mechanism.

Unlike inbox rules, which are set per-user and visible in the user's Outlook, transport rules are invisible to end users and require Exchange admin access to create or modify. A change to a transport rule — especially one that wasn't planned or approved — should always be investigated promptly, because a single well-crafted rule can silently copy all email from an entire domain to an external address.

• Malicious transport rule silently copies all outbound or inbound email to an external BCC address the attacker controls, operating at the server level across the entire organisation
• Rule affects every matching message regardless of individual user inbox settings or awareness
• Rule used to delete specific emails before delivery — suppressing security alerts, password reset notifications, or MFA communications tenant-wide
• Message content modified by a rule — replacing legitimate payment details with attacker-controlled account numbers in outbound finance communications
• Existing transport rule modified rather than a new one created, reducing the likelihood of detection during routine security reviews
• All emails matching broad criteria captured for weeks before the rule is discovered, with the full scope of exfiltration difficult to determine retrospectively
• Transport rule changes require Exchange admin access — compromise at this privilege level creates this risk alongside all other admin-level abuse the attacker can perform
• Rule is invisible to end users; only an admin reviewing the Exchange admin center or running Get-TransportRule will see the change

Transport rule changes are a routine part of Exchange Online administration. Legitimate scenarios include:

• Adding disclaimer text or legal footers to outbound emails
• Creating rules to route specific email types to compliance archiving
• Configuring routing rules for third-party services (e.g., email security gateways, archiving platforms)
• Creating rules to block or quarantine emails meeting certain criteria as part of a security policy update
• Modifying rules as part of a planned mail flow reconfiguration

Any legitimate transport rule change should have a corresponding ticket, change request, or administrative audit trail linking it to a specific project or policy decision. Unexplained changes, new rules that forward to external addresses, or modifications to existing rules that add external forwarding are the key red flags.

• In the Exchange admin centre or via PowerShell (Get-TransportRule), review the current transport rules and identify what was changed, created, or deleted
• For the specific change, check the unified audit log in Microsoft Purview for the admin action — who made the change, when, and from which IP address
• Verify whether the admin account that made the change has a corresponding change request or ticket for this activity
• If a new rule was created, review its conditions and actions carefully — look particularly for BCC or redirect actions pointing to external domains
• If an existing rule was modified, compare the before and after configuration to understand exactly what changed
• Check the admin account's recent sign-in history for signs of compromise

1. If the transport rule change cannot be matched to an approved change, disable or delete the rule immediately to stop any ongoing mail exfiltration or modification
2. Review all emails that may have been affected by the rule during the period it was active — if the rule forwarded mail externally, attempt to determine the scope of what was sent
3. Revoke sessions and reset credentials for the admin account that made the change if it cannot be verified as acting legitimately
4. Run Get-TransportRule | Export-Csv to capture a full snapshot of current transport rules as a baseline for future comparison
5. Review all existing transport rules — not just the one that triggered the alert — to confirm there are no other unauthorised rules that may have been created earlier and not yet detected
6. Consider restricting who can create and modify transport rules by reviewing admin role assignments and removing transport rule management permissions from accounts that don't require it

Overe Auto-Response: The Transport Rule Changed alert can be configured in Overe to trigger automatic session revocation or account block for the initiating admin when unauthorised mail flow changes are detected. Review your Auto-Response settings under Org Config > Auto-Response.

Microsoft: Mail flow rules (transport rules) in Exchange Online

Microsoft: Get-TransportRule PowerShell reference

Microsoft: Search the audit log in the compliance portal

After investigating a transport rule change alert, review these related risk areas:

• Risky Inbox Forwarding Rules — check for per-user forwarding rules that may complement the transport-level exfiltration
• Suspicious Inbox Rules — review user-level inbox rules for mail-hiding behaviour that may be coordinated with the transport rule change
• Mailbox Audit Bypass — if audit bypass was also enabled around the same time, forensic coverage of the affected period may be limited
• Admins with Risky MFA Settings — the admin account used to modify the transport rule should be assessed for MFA strength
• PST Export & eDiscovery Abuse — a broad transport rule change combined with a PST export is a strong indicator of coordinated data exfiltration