Mail Forwarding and Inbox Rules: The Microsoft 365 Audit Nobody Should Skip

There is a very common post-incident mistake in Microsoft 365.

The password gets reset. MFA gets checked. People breathe again. Then everyone moves on without asking whether the mailbox was set up to keep leaking information after the sign-in problem was fixed.

That is why forwarding and inbox rule review matters. It is one of the quickest ways to find quiet persistence in an email compromise.

Attackers do not always need long-term admin access. Sometimes they just need enough time to create a forwarding path, hide specific messages, or redirect information to somewhere the user never sees. If that survives the first round of cleanup, the breach is not really over.

The three places worth checking

I keep this simple and look in three layers.

Layer	What can go wrong
Mailbox forwarding	Messages copied or redirected outside the tenant
Inbox rules	Warnings hidden, mail redirected, replies shaped or deleted
Transport rules	Organisation-wide logic creating unexpected redirection or blind copies

Each one can be legitimate. That is what makes them risky. The problem is rarely the feature itself. The problem is poor ownership and weak review.

Mailbox forwarding is still under-estimated

Microsoft documents how to control automatic external forwarding for a reason. It is a real route for data leaving the tenant.

Some forwarding is legitimate. Shared workflows, ticketing tools and legacy processes still lean on it. Fine. But the bar should be higher than "someone needed it once". Every forwarding exception should have:

• a named business owner
• a stated purpose
• a known destination
• a review date

If any of those are missing, you do not have a business process. You have drift.

Inbox rules deserve more suspicion than they get

Inbox rules are easy to dismiss because users create harmless ones all the time. Move newsletters, sort invoices, clean up noise. Normal.

But inbox rules are also a good place to hide.

Suspicious patterns include:

1. forwarding or redirect actions
2. rules that delete or move security warnings
3. rules created around the time of unusual sign-in activity
4. rules that target finance, payroll or executive mail
5. rules with vague names or no obvious user purpose

You do not need to assume every odd rule is malicious. You do need to stop assuming every odd rule is harmless.

Transport rules can create bigger problems

Transport rules are more powerful, so the review bar should be higher.

I have seen old business logic hang around long after the project that created it ended. Blind copy rules, redirection for old systems, temporary exceptions that quietly became permanent. Nobody touches them because nobody wants to break mail flow.

That is understandable. It is also how messy tenants stay messy.

If a transport rule affects redirection, blind copy, outbound routing or sensitive users, it should have an owner and a reason. If not, it belongs in the review pile.

Useful starting checks

These are not a full forensic process, but they are good initial checks when auditing a tenant:

Get-Mailbox -ResultSize Unlimited |
  Where-Object {$_.ForwardingSmtpAddress -or $_.ForwardingAddress} |
  Select-Object DisplayName,PrimarySmtpAddress,ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward

Get-InboxRule -Mailbox [email protected] |
  Select-Object Name,Enabled,ForwardTo,ForwardAsAttachmentTo,RedirectTo,DeleteMessage,MoveToFolder

Get-TransportRule |
  Select-Object Name,State,Mode,RedirectMessageTo,BlindCopyTo,SentTo,From

The command output is only the start. The real work is asking whether each result still has a valid reason to exist.

After a compromised mailbox, do this in order

Microsoft's response guidance is useful here, but people often skip the slower middle steps. I would want this sequence:

1. Revoke active sessions.
2. Reset the password and confirm MFA state.
3. Check mailbox forwarding settings.
4. Review inbox rules for redirection, deletion or concealment.
5. Review recent sent mail and suspicious replies.
6. Review audit activity to understand what changed and when.
7. Check whether similar patterns exist elsewhere in the tenant.

That is not dramatic incident response advice. It is just complete.

What good policy looks like

For most organisations, a sensible position is:

• block automatic external forwarding by default
• allow exceptions only where there is a documented need
• review inbox and transport rules as part of periodic email security checks
• treat unexplained changes during a compromise window as suspicious until proved otherwise

It is not enough to say "we would notice". Most teams would not notice quickly unless somebody is looking on purpose.

That is why this audit matters. It turns an assumption into evidence.

References

• Control automatic external email forwarding in Microsoft 365
• Responding to a compromised email account in Microsoft 365
• Audit log activities in Microsoft Purview
• Investigate suspicious email forwarding activity in Microsoft Defender XDR