Microsoft 365: detect and remove suspicious email forwarding

Quiet forwarding can keep a data leak alive

A user still receives email while another copy goes elsewhere. The change may be legitimate, misconfigured, or introduced after an account compromise. A rule name, MFA, and the absence of an alert cannot establish legitimacy. Compare the destination, business purpose, configuration, and available activity evidence.

This guide focuses on Exchange Online: read-only inventory, assessment, evidence preservation, and controlled removal. It complements the compromised-account first-response guide; it does not replace a full investigation or Microsoft 365 security assessment. All examples use fictional identities.

• Compromised Microsoft 365 account: first response →

Check three separate configuration locations

Rules that move replies or mark them as read also deserve examination. A mail contact can point outside the organization: resolve its destination rather than trusting its display name. When both mailbox-forwarding targets are set, ForwardingAddress has precedence according to Set-Mailbox.

Separate automatic forwarding from manually sending a message. Outbound forwarding policies do not prevent every exfiltration method, OAuth application access, or malicious transport-rule action.

• Microsoft: mailbox forwarding properties ↗

Prepare scoped permissions and protected evidence storage

Use ExchangeOnlineManagement with an interactive MFA-protected connection. Never embed passwords in scripts. Design unattended application authentication and minimally scoped RBAC separately; do not grant Global Administrator just to make inventory easier.

Get-InboxRule is not supported with only View-Only Organization Management or Global Reader. Have an administrator validate the Exchange role needed for the commands and mailbox scope. Audit searches require appropriate Purview permissions. Keep inspection, remediation, and policy-management privileges distinct.

Choose a UTC window and case identifier. Protect exports with access controls, encryption, and limited retention. Addresses and folder names can be sensitive. Export-Clixml records returned objects; it is neither a mailbox backup nor an automatic rule-restoration mechanism.

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
# Use an approved existing directory with restricted access.
$evidence = 'C:\IR\Case-001'
if (-not (Test-Path -LiteralPath $evidence -PathType Container)) {
    throw 'Create and secure the evidence directory before collection.'
}
$mailbox = 'alex@contoso.com'

• Microsoft: Get-InboxRule permissions and limitations ↗
• Microsoft: investigate rule modifications ↗

Inventory mailbox forwarding, including shared mailboxes

The following inventory preserves both destination properties instead of checking only ForwardingSmtpAddress. Treat its output as configurations to assess, not automatically confirmed incidents. DeliverToMailboxAndForward describes whether a copy remains in the mailbox when forwarding is configured.

• Include shared mailboxes, operational accounts, and previously approved exceptions.
• Resolve ForwardingAddress with Get-Recipient; inspect ExternalEmailAddress for mail contacts.
• Follow forwarding chains: an internal recipient may forward externally in turn.
• Record an owner, purpose, destination, and expiry for every exception.

# Read-only tenant inventory, including shared mailboxes.
$mailboxes = @(Get-Mailbox -ResultSize Unlimited -ErrorAction Stop)
$mailboxes |
    Where-Object { $_.ForwardingAddress -or $_.ForwardingSmtpAddress } |
    Select-Object DisplayName,PrimarySmtpAddress,RecipientTypeDetails,
        ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward |
    Export-Csv (Join-Path $evidence 'mailbox-forwarding.csv') -NoTypeInformation -Encoding UTF8

# Resolve a directory recipient: it may be a mail contact with an external target.
$target = (Get-Mailbox -Identity $mailbox -ErrorAction Stop).ForwardingAddress
if ($target) {
    Get-Recipient -Identity $target -ErrorAction Stop |
        Format-List Name,RecipientTypeDetails,PrimarySmtpAddress,ExternalEmailAddress
}

Inspect hidden rules without changing mailboxes

IncludeHidden includes hidden inbox rules in the output. It does not prove that every persistence mechanism has been found. Preserve disabled rules, processing order, and rules without forwarding: some may conceal warnings or financial conversations.

Start with a few mailboxes. For large environments, split the scope, handle service throttling, and retry failed collections. An access error never means there are no rules. CSV supports triage; full returned objects help examine conditions and exceptions.

# Read-only collection. Scope to a pilot before a tenant-wide run.
$allRules = [System.Collections.Generic.List[object]]::new()
$errors = [System.Collections.Generic.List[object]]::new()
foreach ($box in $mailboxes) {
    $address = $box.PrimarySmtpAddress.ToString()
    try {
        $rules = @(Get-InboxRule -Mailbox $address -IncludeHidden -ResultSize Unlimited -ErrorAction Stop)
        foreach ($rule in $rules) {
            $allRules.Add([pscustomobject]@{ Mailbox = $address; Rule = $rule })
        }
    } catch {
        $errors.Add([pscustomobject]@{ Mailbox = $address; Error = $_.Exception.Message })
    }
}
# Keep full returned objects; CSV alone loses structured rule details.
$allRules | Export-Clixml (Join-Path $evidence 'inbox-rules.xml')
$allRules | Where-Object {
    $_.Rule.ForwardTo -or $_.Rule.RedirectTo -or $_.Rule.ForwardAsAttachmentTo
} | ForEach-Object {
    [pscustomobject]@{
        Mailbox = $_.Mailbox; Name = $_.Rule.Name
        RuleIdentity = $_.Rule.RuleIdentity; Enabled = $_.Rule.Enabled
        Priority = $_.Rule.Priority
        ForwardTo = ($_.Rule.ForwardTo -join '; ')
        RedirectTo = ($_.Rule.RedirectTo -join '; ')
        ForwardAsAttachmentTo = ($_.Rule.ForwardAsAttachmentTo -join '; ')
        DeleteMessage = $_.Rule.DeleteMessage
        MoveToFolder = [string]$_.Rule.MoveToFolder
        StopProcessingRules = $_.Rule.StopProcessingRules
    }
} | Export-Csv (Join-Path $evidence 'inbox-forwarding.csv') -NoTypeInformation -Encoding UTF8
$errors | Export-Csv (Join-Path $evidence 'collection-errors.csv') -NoTypeInformation -Encoding UTF8

Assess the recipient and establish actual activity

Ask the owner through a trusted channel whether forwarding is expected. Do not rely solely on a reply from the suspected account. Check the exact domain, lookalike partner addresses, complete conditions, and documented approval.

Fictional example: a rule named '.' redirects messages containing 'invoice' to collection@external-example.invalid and then moves them. Correlation with an unusual sign-in increases its priority. Conversely, a recognized supplier address is not automatically authorized to receive an entire mailbox.

• Compare changes with Entra sign-ins, delegation, and administrator activity.
• Use Message Trace to inspect affected messages and delivery status; configuration alone does not establish external delivery.
• Use the Auto forwarded messages report as additional evidence, not an exhaustive historical record.
• Preserve message identifiers, logs, rules, and timestamps before deletion when containment permits.

Reconstruct changes in Microsoft Purview Audit

Search for rule creation, updates, activation, deletion, UpdateInboxRules, and Set-Mailbox. UserIds filters the actor, so filtering only on the mailbox owner can miss an administrator or delegate. This example collects relevant tenant operations; inspect ObjectId, UserId, and Parameters in AuditData to identify the affected mailbox.

ReturnLargeSet searches are paginated and capped at 50,000 results. Split time windows if the cap is reached. Missing events may reflect retention, permissions, ingestion delay, or search completeness; they do not establish that a change was legitimate. Microsoft recommends the Management Activity API for ongoing programmatic monitoring rather than simply repeating search scripts.

# Read-only audit query. No UserIds filter: the actor may be a delegate/admin.
$end = (Get-Date).ToUniversalTime()
$start = $end.AddDays(-7)
$session = [guid]::NewGuid().ToString()
$operations = 'New-InboxRule','Set-InboxRule','Remove-InboxRule',
    'Enable-InboxRule','Disable-InboxRule','UpdateInboxRules','Set-Mailbox'
$records = [System.Collections.Generic.List[object]]::new()
do {
    $page = @(Search-UnifiedAuditLog -StartDate $start -EndDate $end -Operations $operations `
        -SessionId $session -SessionCommand ReturnLargeSet -ResultSize 5000 -ErrorAction Stop)
    foreach ($record in $page) { $records.Add($record) }
} while ($page.Count -gt 0 -and $records.Count -lt 50000)
$records | Export-Clixml (Join-Path $evidence 'audit-records.xml')
$records | Select-Object CreationDate,UserIds,Operations,AuditData |
    Export-Csv (Join-Path $evidence 'audit-records.csv') -NoTypeInformation -Encoding UTF8
if ($records.Count -ge 50000) {
    Write-Warning 'Result cap reached: repeat with smaller UTC time windows.'
}

• Microsoft: Search-UnifiedAuditLog pagination and limits ↗

Disable or delete only confirmed malicious configuration

Containment of an active leak must not wait for perfect collection. Quickly preserve available evidence, then coordinate account containment and forwarding removal with the response team. Deleting a rule alone does not remove the attacker's access.

Important: Microsoft warns that creating, modifying, enabling, disabling, or removing an inbox rule through Exchange PowerShell can remove Outlook-created client-side rules. Document those with the user where practical, keep warnings enabled, and choose the appropriate remediation method. Do not use blanket deletion or -Force to ignore the risk.

The example starts with WhatIf. Disabling retains the server rule for inspection but does not guarantee complete rollback of Outlook rules. Clearing mailbox-forwarding targets does not modify inbox or transport rules; address those mechanisms separately.

# CHANGE: inspect and export first. Replace the placeholder with the exact RuleIdentity.
$ruleId = 'REPLACE_WITH_CONFIRMED_RULE_ID'
if ($ruleId -eq 'REPLACE_WITH_CONFIRMED_RULE_ID' -or [string]::IsNullOrWhiteSpace($ruleId)) {
    throw 'Select the confirmed malicious rule before proceeding.'
}
Get-InboxRule -Mailbox $mailbox -Identity $ruleId -IncludeHidden -ErrorAction Stop | Format-List *
Disable-InboxRule -Mailbox $mailbox -Identity $ruleId -WhatIf
# After approval, run without -WhatIf; retain normal confirmation prompts.
# Disable-InboxRule -Mailbox $mailbox -Identity $ruleId
# Remove-InboxRule -Mailbox $mailbox -Identity $ruleId

# CHANGE: removes both mailbox-forwarding targets, not inbox or transport rules.
Set-Mailbox -Identity $mailbox -ForwardingAddress $null -ForwardingSmtpAddress $null -DeliverToMailboxAndForward $false -WhatIf
# Run without -WhatIf only after validating the intended scope.
Get-Mailbox -Identity $mailbox |
    Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

• Microsoft: Disable-InboxRule precautions ↗
• Microsoft: Remove-InboxRule ↗
• Microsoft: compromised-account response ↗

Block external forwarding with controlled exceptions

Review outbound spam policies in Microsoft Defender. Explicitly select Off to prohibit automatic external forwarding; do not assume Automatic has identical behavior across tenants. This setting does not block internal forwarding. Review transport rules separately.

Inventory custom policies before changing the default. The first applicable outbound policy in priority order is used; the default is last. An On exception should cover only approved senders, with an owner and expiry. Remote domains can restrict destinations, but test the interaction: an applicable block can prevent forwarding despite an allow elsewhere.

• Start with a pilot mailbox and a message containing no real business data.
• Test prohibited external forwarding, an approved exception, internal forwarding, and manually sent external mail.
• Verify normal delivery, retained copies where intended, Message Trace, and any 5.7.520 NDR.
• Record the original configuration; restore an exception only after reconfirming its destination and purpose.

# Read-only configuration: scope, exceptions and priority matter.
Get-HostedOutboundSpamFilterPolicy | Format-List Name,AutoForwardingMode
Get-HostedOutboundSpamFilterRule | Sort-Object Priority |
    Format-List Name,State,Priority,HostedOutboundSpamFilterPolicy,
        From,FromMemberOf,SenderDomainIs,ExceptIfFrom,ExceptIfFromMemberOf,ExceptIfSenderDomainIs
Get-RemoteDomain | Format-Table Name,DomainName,AutoForwardEnabled
Get-TransportRule | Sort-Object Priority |
    Format-List Name,Identity,State,Mode,Priority,Description

• Microsoft: automatic external forwarding controls ↗
• Microsoft: outbound policy scope and precedence ↗
• Microsoft: remote domains ↗

Watch for recurrence and close the case with evidence

Review Suspicious email forwarding activity and forwarding-creation alerts available in your environment. The former detects forwarding considered suspicious, not every forwarding configuration; it is not a complete inventory. Validate licensing, roles, notifications, and on-call recipients. Microsoft notes that new or changed alert policies can take up to 24 hours to trigger.

If a rule returns, investigate the access recreating it: a session, delegate, application, or administrator account. Reassess authentication methods and OAuth consent. Record the destination, period, potentially exposed messages, confidence level, changes, and test evidence. Removing configuration cannot retrieve copies already delivered.

• Inventory complete; collection errors resolved or explicitly documented.
• Suspicious rules and forwarding neutralized; business rules preserved where possible.
• Originating access contained and mail-delivery tests passed.
• Exceptions approved, monitoring assigned, and follow-up scheduled.

• Microsoft: alert policies and licensing ↗
• Audit Microsoft 365 OAuth applications →

When is professional assistance warranted?

Multiple affected mailboxes, recreated rules, an unknown application, or financial exposure justify a broader investigation. My Microsoft 365 consulting services help assess exposure, review permissions and policies, and establish appropriate monitoring. This focused diagnosis remains one step, not a substitute for a complete security assessment or incident response.

• Microsoft 365 security assessment →