External forwarding in Exchange Online is one of the data loss risks I keep running into in Microsoft 365 environments. Once attackers have taken over an account, they like to set up auto-forwarding, often with nothing more than one inbox rule, and then quietly siphon off email for weeks. Microsoft now blocks automatic external forwarding by default. Even so, if you don't know every setting and every exception, there may be open doors in your tenant you aren't aware of.

Three layers decide whether a forward leaves the tenant

The setting that matters most is "Automatic forwarding" in the Outbound spam filter policy. You'll find it in the Microsoft Defender portal under Email & Collaboration → Policies & rules → Threat policies → Anti-spam policies (see docs). There are three options: "Automatic - System-controlled" (the default, which blocks forwarding), "On" (allow) and "Off" (explicitly block). New tenants and most existing ones use "Automatic - System-controlled", so external forwarding is blocked.

Remote domain settings come on top of that. Each accepted domain has a matching remote domain in Exchange Online (Mail flow → Remote domains), and its "Allow automatic forwarding" option determines whether forwarding to that destination is permitted (details here). Turn it off and forwarding to that domain is blocked, no matter what the spam policy says. Then there are transport (mail flow) rules, which can block or allow forwarding based on keywords, senders or recipients. The layers interact strictly, and the most restrictive setting always wins. A forward only gets through if every layer explicitly allows it.

In hybrid or migrated tenants in particular, I often find remote domain settings that are too permissive, or old transport rules that silently override the intended policy. One tip from my own projects:

If specific users need an exception, always create a dedicated outbound spam policy, scope it to just those users or a group, and set external forwarding to "On" in that policy. Then check the remote domain and mail flow rule settings as well.

The diagram shows how these settings interact

Below you can see the route an auto-forwarded message takes. A block at any one of these layers stops the forward.

flowchart TD
    UserRule["User inbox rule"] --> Outbound["Outbound spam policy"]
    Outbound --> RemoteDomain["Remote domain policy"]
    RemoteDomain --> Transport["Transport rule"]
    Transport --> Target["External delivery"]

Figure: How forwarding settings interact in Exchange Online

A dedicated policy handles exceptions for specific users

Now and then a department or a trusted third party genuinely has to forward mail externally, for example to a support vendor or a partner. The cleanest approach is a separate outbound spam policy (Defender portal → Email & Collaboration → Policies & rules → Threat policies → Anti-spam policies) that targets only those users or a group, with "Automatic forwarding" set to "On". Make sure it sits above the default policy in the priority order, otherwise it won't be applied. I'd stay away from exceptions in remote domain settings or transport rules. You lose track of them quickly, and they can be hard to audit later on.

PowerShell finds active forwarding in your tenant

To see whether forwarding is already switched on somewhere, I use PowerShell. In Exchange Online PowerShell, with at least Exchange Online Administrator rights, you can quickly list mailboxes that forward externally (these have a ForwardingSmtpAddress set) or that keep a copy and forward (DeliverToMailboxAndForward):

# Mailboxes forwarding externally
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingSmtpAddress -ne $null }

# Mailboxes with DeliverToMailboxAndForward (internal/external)
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.DeliverToMailboxAndForward -eq $true }

# Inbox rules with ForwardTo or RedirectTo
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    Get-InboxRule -Mailbox $_.UserPrincipalName | Where-Object { $_.ForwardTo -or $_.RedirectTo }
}

These queries run in Exchange Online PowerShell and need at least Exchange Online Admin rights. Checking for suspicious inbox rules on a regular basis matters a lot, because attackers frequently create them after an Account Takeover or AiTM phishing. Shared mailboxes are another frequent weak spot. Many tenants never enforce MFA on them, which makes them a favourite target for auto-forwarding (I've written more about this in my post on securing shared mailboxes).

The auto-forwarded messages report shows who is forwarding right now

In the Exchange admin center, open Mail flow → Message trace → Auto-forwarded messages report. It shows at a glance who is currently forwarding to which address. When I'm doing an audit or looking into suspicious activity, this is where I usually start. The reports section in the Defender portal adds outbound mail volume and destination addresses, which helps you notice unusual spikes (read more).

I trust the settings but verify them routinely

Today you can control external forwarding in Exchange Online cleanly and at a fine-grained level, provided you know where to look and check regularly. In the tenants I work with, the most dangerous gaps come from exceptions and old rules, often after major incidents or during hurried onboarding. Don't depend on one setting alone. Review forwarding and inbox rules on a schedule, and especially after AiTM phishing waves, which have a habit of leaving hidden rules in mailboxes. That keeps exfiltration in check even as attack methods change.