How to Find and Stop Exchange Server Mystery Forwarding

You get a call from a user. They heard from a colleague at a partner company that they have been receiving emails from your Exchange Server -- emails the colleague never asked for. You check your sent items. Nothing. You check your transport logs. Nothing obvious. But mail is going out, and you did not send it.

This is the Exchange Server mystery forwarding problem. It shows up in a few ways: an inbox rule forwarding to an external address, a transport rule you do not remember creating, or a mailbox-level forwarding setting that was added by an automated process. Sometimes it is a misconfiguration. Sometimes it is a compromised account. Either way, it is a problem before it becomes a headline.

Why this matters more than most admins realise

External forwarding from your Exchange environment does two things at once. First, it leaks internal content to an outside party -- potentially sensitive, potentially regulated. Second, it tarnishes your sending domain's reputation because the external receiving server sees your IP sending mail to addresses you do not control. If your domain ends up on a blocklist because of mystery forwarding, your legitimate outbound mail starts bouncing. That is the double cost: data risk plus deliverability risk.

This is also exactly the kind of pattern that DMARC aggregate reports can surface. If unfamiliar external domains appear in your RUA data without a corresponding legitimate mailing relationship, that is a signal worth investigating. More on that at the end.

Three places Exchange can forward mail without you knowing

Before you start hunting, understand where Exchange stores forwarding configurations. There are three common locations.

Inbox rules -- These live at the mailbox level and run client-side even when OWA is in use. Rules can forward, redirect, or copy messages to external SMTP addresses. A malicious or compromised inbox rule is a common post-compromise move.

Mailbox forwarding attributes -- Exchange mailboxes have two relevant attributes: ForwardingSmtpAddress and DeliverToMailboxAndForward. If these are set, mail goes somewhere you may not have authorized. Scripts, migrations, or poorly documented third-party tools can set these silently.

Transport rules -- These run server-side on the Exchange Transport service. A transport rule can redirect, forward, or send copies of messages to external domains based on conditions you may not have audited recently.

Each requires different commands to find.

Finding inbox rules that forward externally

Run this PowerShell command against your Exchange environment:

Get-InboxRule -Mailbox $User | Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo } | Format-List Name, Identity, ForwardTo, ForwardAsAttachmentTo, Enabled

This returns every enabled inbox rule for a given mailbox that forwards or attaches to anything. Look for SMTP addresses you do not recognise.

To check all mailboxes at once:

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    Get-InboxRule -Mailbox $_.UserPrincipalName | Where-Object {
        $_.ForwardTo -match '@' -or $_.ForwardAsAttachmentTo -match '@'
    } | Select-Object MailboxOwnerID, Name, ForwardTo, ForwardAsAttachmentTo
}

Check the ForwardTo and ForwardAsAttachmentTo fields carefully. Rules that forward to your own domain can be legitimate. Rules forwarding to external domains -- especially domains with no business relationship -- are worth investigating immediately.

To see who created a rule and when, you need the audit log:

Search-UnifiedAuditLog -UserIds $User -Operations New-InboxRule -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) | Select-Object UserId, CreationDate, Operation, AuditData

If the rule was created by the account owner, it is likely intentional (even if unauthorized). If it was created by someone else, escalate.

Checking mailbox-level forwarding attributes

Run this against any mailbox you are investigating:

Get-Mailbox -Identity $User | Select-Object Name, ForwardingSmtpAddress, DeliverToMailboxAndForward, ExternalOofOptions

If ForwardingSmtpAddress is populated, mail is being forwarded to that address. DeliverToMailboxAndForward set to $true means the original mailbox still receives a copy. Set to $false means the forward is the only delivery path -- the user stops seeing their own mail.

To find all mailboxes with an external forward across your organisation:

Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -ne $null } | Select-Object Name, DisplayName, ForwardingSmtpAddress, DeliverToMailboxAndForward

External in this context means any address not on your accepted domain list. Spot-check any result before assuming it is legitimate.

Auditing transport rules for external delivery

Transport rules are server-side and survive password resets, MFA changes, and session revocations. If a transport rule is doing the forwarding, the mailbox owner may have no idea.

Find all transport rules that reference external domains:

Get-TransportRule | Where-Object {
    $_.ForwardTo -match '@' -or $_.RedirectTo -match '@' -or $_.RouteMessageOutbound -eq $true
} | Select-Object Name, Identity, State, ForwardTo, RedirectTo, RouteMessageOutbound, Priority

RouteMessageOutbound set to $true means the rule routes messages outside your organisation entirely. If you did not set this, find out who did.

To check which transport rule actually triggered on a specific message, look at your message tracking log:

Get-MessageTrackingLog -Server $ServerName -Subject "Subject Line Here" -Start (Get-Date).AddHours(-24) | Select-Object Timestamp, Sender, Recipient, EventId, Source, SourceContext | Format-Table

The EventId values to watch: REDIRECT, FORWARD, SUBMIT. These tell you whether a rule touched the message.

Hybrid environments add a layer that on-premises audits miss

If you run Exchange hybrid with Microsoft 365, forwarding can happen in the cloud independently of your on-premises configuration. Cloud mailboxes can have Inbox rules and forwarding attributes that exist only in Exchange Online and do not appear in your on-premises Exchange Admin Center.

To check cloud-side forwarding for a specific user:

Get-Mailbox -Identity $User.ExternalDirectoryObjectId -Remote -ResultSize Unlimited | Select-Object Name, ForwardingSmtpAddress, DeliverToMailboxAndForward

Or connect directly to Exchange Online with Connect-ExchangeOnline and run the same inbox rule cmdlets against your cloud tenants.

OAuth token theft is also worth knowing about here. If an attacker obtains a valid OAuth token for a cloud mailbox, they can create inbox rules and forwarding settings that your on-premises Exchange server never sees. This is why monitoring cloud sign-in logs for unusual app consent events matters as much as your on-premises audit trail.

A repeatable audit process for any Exchange environment

Do not wait for a user to call. Run this monthly checklist across all mailboxes:

Get-InboxRule for every mailbox: flag any rule forwarding externally

Get-Mailbox: check ForwardingSmtpAddress on all mailboxes

Get-TransportRule: check RouteMessageOutbound and external recipients

Review mail contact and mail user objects -- these can be used as forward targets

Export a baseline and diff it against the prior month

Steps 1 through 3 take under ten minutes with a script. Step 5 catches anything that was added between runs.

What DMARC reports reveal about this problem

Here is the connection that often gets missed: when Exchange forwards mail to an external address using your domain in the From header, that external mail flow shows up in your DMARC aggregate reports. You see a new sending source -- an IP you do not control, sending mail as your domain -- hitting a receiver you have no relationship with.

That pattern is a DMARC alignment failure. It may be a forwarding issue, it may be something worse. Either way, it shows up in RUA data before the user calls to complain.

DMARCFlow monitors RUA reports for exactly this signal: unknown sending infrastructure appearing in your domain's auth data. If a new external forwarding rule starts copying your internal mail to a Gmail account, DMARCFlow flags it as an alignment anomaly even if the forwarding rule itself lives outside your visibility. It does not replace your Exchange audits, but it gives you a domain-level signal that something changed.

FAQ

Can inbox rules forward mail after a password reset?

Yes. Inbox rules run client-side and are independent of credentials. If an account is compromised and rules are created before the password is reset, those rules persist until explicitly removed. Removing the compromised account's mailbox access does not automatically delete rules.

What is the difference between Forward and Redirect in inbox rules?

Forward sends a new message to the recipient -- the original message stays in the mailbox and a copy goes out. Redirect sends the original message without creating a new one -- harder to trace because the recipient sees the original headers. Both are worth investigating.

Does setting a forwarding rule to Bcc instead of To hide it?

No. Bcc in an inbox rule still creates a separate message to the Bcc recipient. It is not invisible to the transport log.

Can transport rules survive an Exchange Server restart?

Yes. Transport rules are stored in Active Directory and apply to the Transport service on all servers in the organisation. They survive restarts and are not mailbox-specific.

How do I remove a forwarding attribute without disabling the mailbox?

Set it to $null:

Set-Mailbox -Identity $User -ForwardingSmtpAddress $null -DeliverToMailboxAndForward $false