Dev.to Security 🔐 Cybersecurity 👁 0 📖 4 min read

Find every external mail forward in Exchange Online before you turn forwarding off

A forward to an outside address is the quietest way to keep reading a mailbox after a takeover. Exchange Online can block it with one setting, but the default value of that setting does not mean the same thing in every t

A forward to an outside address is the quietest way to keep reading a mailbox after a takeover. Exchange Online can block it with one setting, but the default value of that setting does not mean the same thing in every tenant. Here is how to see where you stand with read-only commands, and how to switch it off without surprising the people who rely on a forward.

What changes: nothing changes on its own. Microsoft recommends setting automatic external forwarding explicitly to Off in the outbound spam policy, because the default, Automatic, behaves differently from tenant to tenant.
Who: Exchange Online admins, any plan (Exchange Online Protection is enough).
By when: no deadline. It is a standing recommendation.
Do this:
1. List mailboxes with a forward and inbox rules that forward or redirect outside.
2. Set the default outbound spam policy to Off and give approved forwards their own scoped policy.
Check: Get-HostedOutboundSpamFilterPolicy | Format-List Name,AutoForwardingMode (read-only)
Source: Microsoft Learn, "Control automatic external email forwarding from cloud mailboxes"

Why "Automatic" is not an answer

The outbound spam filter policy has three values for automatic forwarding:

  • Automatic - System-controlled is the default. Microsoft says it was first equivalent to On, and in 2021 it became equivalent to Off for new organisations and for existing ones that weren't actively using it. Tenants that were already using it can still behave as On.
  • On - Forwarding is enabled allows automatic external forwarding.
  • Off - Forwarding is disabled blocks it and returns a non-delivery report to the sender.

Because the result of Automatic depends on your tenant's history, Microsoft's advice is to configure On or Off instead. Its recommended settings for both the Standard and Strict presets are Off.

Two details from the same Learn page matter for planning:

  • Off blocks both kinds of automatic forwarding: inbox rules that users create (or an attacker creates for them) and mailbox forwarding that admins set (SMTP forwarding).
  • Forwarding between internal users is not affected.

Step 1: see your current setting (read-only)

Connect with the ExchangeOnlineManagement module and read every outbound policy:

Connect-ExchangeOnline
Get-HostedOutboundSpamFilterPolicy |
  Format-Table Name, AutoForwardingMode

If the policy named Default says Automatic, you do not know from this output alone whether forwarding works in your tenant. That is the reason to make it explicit.

Step 2: list the forwards that exist today (read-only)

Mailbox forwarding set by admins:

$f = Get-Mailbox -ResultSize Unlimited |
  Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress }
"Mailboxes with a forward: $(@($f).Count)"
$f | Select-Object UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

Inbox rules that forward or redirect. This walks every mailbox, so run it out of hours in a large tenant or limit it to a pilot group first:

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  $upn = $_.UserPrincipalName
  Get-InboxRule -Mailbox $upn -ErrorAction SilentlyContinue |
    Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo } |
    Select-Object @{n='Mailbox';e={$upn}}, Name, Enabled, ForwardTo, ForwardAsAttachmentTo, RedirectTo
}

Not every address in those results is external: check the domain of each one against your accepted domains. The Auto forwarded messages report in the Defender portal shows the same picture from the mail flow side.

Write the counts down. They are your baseline, and any forward you did not expect deserves a closer look before anything else: an inbox rule forwarding to a free mail address on a finance mailbox is a sign-in investigation, not a settings task.

Step 3: ask, then set Off

For each remaining forward, ask the owner whether it is still needed. Then:

  1. In the Defender portal go to Email & collaboration > Policies & rules > Threat policies > Anti-spam, open Anti-spam outbound policy (Default) and set Automatic forwarding rules to Off - Forwarding is disabled.
  2. For forwards that the business approves, create a custom outbound spam policy with forwarding On, scoped to those senders only. To limit where they can forward, use remote domains: when one control allows forwarding and another blocks it, the block typically wins.
  3. Tell the helpdesk what users will see. The bounce reads: 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7555)

Rollback

Set the default outbound policy back to its previous value, or add the affected user to the custom outbound policy with forwarding On.

How to verify

The default outbound policy shows AutoForwardingMode Off; every remaining forward sits in a named custom policy with an owner; a test inbox rule that forwards outside the tenant returns 5.7.520.

Before you change anything

Run Steps 1 and 2 today, even if you change nothing this week. Finding a forward you can't explain matters more than the setting.

This check is control E07 in our free Microsoft 365 Emergency Top 10, which comes with a Jira import, an Excel plan and read-only PowerShell checks: https://runbooklabhq.com/kits/m365-hardening/?utm_source=devto&utm_medium=article&utm_campaign=m365-top10&utm_content=devto-005

Sources

  • Microsoft Learn: Control automatic external email forwarding from cloud mailboxes (read 5 November 2026)
  • Microsoft Learn: Recommended settings for EOP and Microsoft Defender for Office 365 security
  • Microsoft Learn: Configure outbound spam filtering

Drafted with AI assistance and reviewed before publishing. Runbook Lab is not affiliated with Microsoft.

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.