Transport Rule Changed

Why this risk matters

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.

What happens if this is abused

A malicious transport rule can forward copies of all emails matching certain criteria — or all emails entirely — to an external address the attacker controls. Unlike per-user forwarding rules, a transport rule operates at the server level and affects every matching message regardless of the recipient's inbox settings or awareness.

Transport rules can also be used to: delete specific emails before delivery (to suppress alerts or notifications), modify message content (to redirect payment instructions in BEC attacks), strip attachments from certain email classes, or bypass spam/phishing filters for specific senders. These modifications happen silently and leave no visible trace for end users.

In Business Email Compromise attacks, attackers often modify existing transport rules rather than creating new ones, to reduce the likelihood of detection.

When this is expected or acceptable

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.

Checks to perform before taking action

  • 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

Safe remediation steps

  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.

Related risks and follow-on checks

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
TBD CTA