Find External Mailbox Forwarding in Exchange Online

Practical intro

External forwarding is not automatically bad. It can support a real workflow, reflect an old process, or point to something that needs a deeper look. The point of this check is to make forwarding visible so it can be reviewed.

Why I check this

In real tenant reviews, it is common to find settings that made sense at one point but were never revisited. Forwarding is worth checking because it can affect where business mail goes and who can see it.

What this check tells you

This example reads mailbox-level forwarding fields from Exchange Online and exports mailboxes where forwarding appears to be configured. It is useful as a first mailbox configuration review because it gives you a concrete list of mailboxes with forwarding values to explain.

What this helps you decide

This helps you decide which mailbox forwarding entries need an owner, a reason, and a closer look before mail flow or security changes. For an everyday admin, the useful question is bigger than whether forwarding exists. You need to know why this mailbox sends copies somewhere else and whether that path is still expected.

What this does not prove

This check does not prove that forwarding is malicious or incorrect. It does not detect inbox rules, mail flow rules, third-party app access, OAuth consent abuse, connectors, journaling, or every downstream routing path. External forwarding can be legitimate, forgotten, or suspicious depending on context.

When I would run this

• Before mail flow or security policy changes.
• During tenant reviews and admin handoffs.
• When investigating unusual mail delivery reports or inherited forwarding behavior.

Permissions and modules

Use an account with approved read access to mailbox configuration. The example uses the Exchange Online PowerShell module. Microsoft recommends the Exchange Online PowerShell module for modern Exchange Online scenarios, and Get-EXOMailbox can return explicitly requested properties.

• ExchangeOnlineManagement

Read-only PowerShell example

This example reads mailbox objects, filters for forwarding-related fields, and exports a CSV for review. It does not change mailbox settings. The example uses Get-EXOMailbox with the forwarding properties requested explicitly.

# SecureOps Playbooks | secureopsplaybooks.com
# Read-only example: external mailbox forwarding review. Validate in a lab first.

Connect-ExchangeOnline

$forwardingProperties = @(
  "DisplayName",
  "UserPrincipalName",
  "PrimarySmtpAddress",
  "ForwardingSmtpAddress",
  "ForwardingAddress",
  "DeliverToMailboxAndForward"
)

$mailboxes = Get-EXOMailbox -ResultSize Unlimited -Properties $forwardingProperties

$forwardingReview = $mailboxes |
  Where-Object {
    $_.ForwardingSmtpAddress -or
    $_.ForwardingAddress -or
    $_.DeliverToMailboxAndForward
  } |
  Select-Object DisplayName,
    UserPrincipalName,
    PrimarySmtpAddress,
    ForwardingSmtpAddress,
    ForwardingAddress,
    DeliverToMailboxAndForward

$forwardingReview |
  Sort-Object UserPrincipalName |
  Export-Csv ".\mailbox-forwarding-review.csv" -NoTypeInformation

Expected output columns

• DisplayName
• UserPrincipalName
• PrimarySmtpAddress
• ForwardingSmtpAddress
• ForwardingAddress
• DeliverToMailboxAndForward

How to read the results

Review external addresses first, then confirm whether the forwarding is expected. Finding this value does not automatically mean the setting is malicious or incorrect. It means the setting should be reviewed in context.

Common findings

• Forwarding left in place after a role or process changed.
• Shared mailbox forwarding used for a known business workflow.
• Forwarding that needs owner confirmation before any action is taken.

False positives or normal explanations

A mailbox may forward to a ticketing system, a shared service address, or an approved operational mailbox. Do not assume intent from the field alone.

What to verify before action

• Whether the forwarding destination is internal or external.
• Whether the mailbox owner or business owner expects the forwarding.
• Whether mail is also delivered to the original mailbox.
• Whether inbox rules, mail flow rules, app access, or OAuth consent need separate follow-up checks.
• Who confirmed the business reason, when it was reviewed, and what evidence supports the next step.

Troubleshooting

• If connection fails, confirm modern authentication is available for the admin account.
• If the export is empty, confirm the account can read mailbox forwarding fields.
• If output contains ambiguous recipients, validate them manually before making decisions.
• If the tenant is large, consider how and when to run the export so the review process is manageable.

Limitations

This checks mailbox-level forwarding properties only. It does not inspect inbox rule forwarding, mail flow rules, third-party app access, OAuth consent abuse, connectors, journaling, third-party routing, or downstream systems. Those are separate follow-up checks, and this export should not be treated as a complete forwarding investigation.

Sources and documentation to review

• Exchange Online PowerShell documentation
• Exchange Online Connect-ExchangeOnline documentation
• Exchange Online Get-Mailbox documentation
• Exchange Online Get-EXOMailbox documentation

Validation status

This is an example read-only playbook. Review the Microsoft documentation, permissions, and output in a test or lab environment before using it as part of a production change process.

Related playbooks

• Audit MFA Registration
• Review Privileged Role Assignments
• M365 Admin Quick-Check Pack