How to Find Hidden Exchange Mailbox Forwarding Rules That Evade the Admin Center

The Scenario

You get a report from a user: their inbox emails are appearing at an external Gmail address they never signed up for. You open the Exchange Admin Center, find the mailbox, and check forwarding. Nothing is configured. You check inbox rules in Outlook and OWA. Nothing. You run MFCMAPI and hunt for ForwardingAddress or folder rules. Nothing. You check the CodeTwo signature tool on the server. Not configured. You even remove the iPhone ActiveSync partnership in case that is the vector. Still forwarding.

This is a real case from a domain admin who eventually found the cause through message tracking logs and a send connector audit. The forwarding was real but invisible to every standard admin tool.

If this sounds familiar, here is a systematic checklist for finding Exchange mailbox forwarding that evades the Admin Center.

Why Standard Admin Tools Miss Hidden Forwarding

The Exchange Admin Center shows mailbox-level forwarding settings and inbox rules that are configured through Outlook or OWA. It does not show forwarding that originates from transport rules, delegate permissions, third-party gateway configurations, or SMTP-level forwarding set by legacy tools.

The gap matters because each forwarding mechanism is controlled by a different component of the Exchange stack and requires a different tool to inspect or remediate.

The Complete Exchange Forwarding Investigation Checklist

Work through these steps in order. Most hidden forwarding cases are caught by step 4 or step 7.

Step 1 -- Check Mailbox-Level Forwarding Settings

Start here even though it usually comes up empty in hidden forwarding cases:

• In EAC, go to Recipients > Mailboxes > [mailbox] > Mailbox Delegation > Edit Forwarding Address
• Check both ForwardingAddress (redirects and moves) and Deliver to both forwarding address and mailbox
• Run in Exchange Management Shell:

Get-Mailbox -Identity "user@domain.com" | Select-Object ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

If both forwarding fields are empty, the mailbox-level setting is not the cause.

Step 2 -- Check Inbox Rules (Outlook, OWA, MFCMAPI)

Inbox rules live in the mailbox database, not in Exchange admin tools. MFCMAPI is the most thorough inspector:

• Download MFCMAPI from the Microsoft Download Center (search "MFCMAPI download" if the direct link changes)
• Connect to the mailbox using the Outlook profile
• Navigate to Root Container > Inbox > Rules
• Look for any rule with a Forward or Redirect action pointing to an external address
• Check the PR_RULE_PROVIDER property for the rule engine that created the rule (Outlook, client-side, or server-side)

In OWA, go to Settings > Mail > Rules. If a rule was created client-side only in Outlook, it may not appear in OWA rules view.

Step 3 -- Check Transport Rules on the Mailbox Server

Transport rules (mail flow rules in EAC) can forward mail based on conditions without touching mailbox-level settings.

• In EAC, go to Mail Flow > Rules
• Look for rules with action "Redirect the message to" or "Forward the message to" or "Bcc the message to"
• Check the conditions: some rules apply to specific senders, recipients, or domains

Run in Exchange Management Shell:

Get-TransportRule | Where-Object {$_.Redirect -eq $true -or $_.Forward -eq $true} | Format-List Name, Identity, State, Priority

Transport rules with the Forward attribute set to an external domain are the most likely source of invisible forwarding on Exchange 2019.

Step 4 -- Check Delegate Access and Send On Behalf Permissions

This is the step most admins overlook. A delegate with "Send on Behalf" permission does not forward mail in the technical sense, but it does cause mail to appear at an external address in a way that looks like forwarding to end users.

Check delegate access:

Get-MailboxPermission -Identity "user@domain.com" | Where-Object {$_.AccessRights -like "*Delegate*"}
Get-RecipientPermission -Identity "user@domain.com" | Where-Object {$_.Trustee -ne $null}

Check Send On Behalf:

Get-Mailbox -Identity "user@domain.com" | Select-Object GrantSendOnBehalfTo

If an external address appears in GrantSendOnBehalfTo, mail will be sent from the mailbox on behalf of that external entity. This is not forwarding in the strict sense, but it produces the same user-visible symptom.

Step 5 -- Check SMTP Send Connectors and Scoping

In a hybrid Exchange environment or one with third-party gateway appliances, send connectors can be configured to relay all mail from certain mailboxes to an external destination.

Check for scoped send connectors:

Get-SendConnector | Format-List Name, Identity, AddressSpaces, SourceTransportServers

If a send connector is scoped to route mail from specific internal addresses to an external domain, it will forward mail silently. This is a common configuration in legacy migrations or when integrating third-party email security appliances.

Step 6 -- Check Edge Transport or Third-Party Gateway Rules

If your Exchange environment uses an Edge Transport server, a third-party gateway (Proofpoint, Mimecast, Barracuda), or a cloud email security service, forwarding rules may be configured at that layer, completely outside Exchange.

Check the gateway's mail flow rules and quarantine policies. In Proofpoint, for example, an administrator can configure message routing rules that redirect or forward mail based on sender or recipient conditions. These rules do not appear in Exchange admin tools.

If you have a gateway appliance, check its forwarding and routing rules before continuing deeper into Exchange investigation.

Step 7 -- Use the Remote Connectivity Analyzer to Test Forwarding

Microsoft's Remote Connectivity Analyzer can test mailbox configuration including forwarding settings:

• Go to the Remote Connectivity Analyzer (connectivity.outlook.com)
• Select "Mailbox Logging Tests" or "Outlook Connectivity"
• Run the tests against the affected mailbox

This will confirm whether forwarding is active at the protocol level even when it does not appear in the admin interface.

Step 8 -- Review Message Tracking Logs for the Forwarding Pattern

Message tracking is often the decisive investigation step when all other tools come up empty:

Get-MessageTrackingLog -Server "ExchangeServer" -Subject "Test Message" -Start (Get-Date).AddDays(-7) | Where-Object {$_.Recipient -like "*@externaldomain.com"} | Format-List Timestamp, Sender, Recipient, EventId, Source, ConnectorID

Look for:

• A ConnectorID on a message sent to an external domain that is not a known legitimate relay
• Repeated events with the same recipient pattern suggesting an automated rule rather than a one-time forward
• Source: "SMTP" vs "STOREDRIVER" vs "ROUTING" -- this tells you whether the forward originated from the mailbox or from transport

In the real case that inspired this post, message tracking showed that forwarded messages had a specific ConnectorID pointing to a send connector that had been modified during a migration. The forwarding was not in any rule -- it was in the connector configuration.

Step 9 -- Cross-Reference DMARC Aggregate Reports for the External Destination

Once message tracking identifies an external domain receiving forwarded mail, DMARC aggregate reports give you an independent confirmation that is worth checking even when message tracking has already found the cause. DMARC RUA reports show all destination domains receiving mail from your mail servers. If an external domain appears in those reports and you have not intentionally configured forwarding to it, that domain is worth investigating further.

If message tracking is inconclusive -- for example, if your Exchange logs do not capture enough detail or if the forwarding is happening at a gateway layer that does not write Exchange logs -- DMARC reports may be the only signal that shows where mail is actually going. DMARCFlow processes these reports and highlights destination domains that are not in your approved senders list, making it faster to spot a forwarding anomaly without manually reviewing raw report data.

FAQ

Can a forwarding rule exist without any trace in Exchange logs?

Yes. If forwarding is set at the gateway layer or on a send connector that does not generate verbose transport logs, the rule can be invisible to Exchange logging. Message tracking at the transport level is the most reliable way to confirm forwarding is actually occurring.

Does removing an iPhone ActiveSync partnership stop mailbox forwarding?

Only if the iPhone was the source of the forwarding. ActiveSync device partnerships do not themselves forward mail -- they sync mailbox content. However, some mobile email apps with ActiveSync access can create inbox rules server-side. Removing the partnership alone does not guarantee forwarding stops.

Can a delegate account set up forwarding that the admin cannot see?

A delegate with full access permissions can create inbox rules that forward mail, but those rules will appear in MFCMAPI. A more subtle scenario: if a delegate has been granted Send On Behalf permissions and configures their own Outlook to automatically forward, that forwarding originates from the delegate's Outlook, not from the mailbox itself, and it will not appear as a mailbox rule in Exchange.

How do I block external forwarding in Exchange 2019?

Three layers: (1) Set mailbox-level restrictions in EAC or via Set-Mailbox to reject all forwarding to external domains. (2) Create a transport rule that blocks messages sent to external recipients where the From address matches your domain (this catches rule-based forwarding). (3) Audit send connectors for any that route to external domains without justification. If you use third-party gateways, configure them to block forwarding rules that target external addresses.