Mailbox Forwarding Rules: Review After Account Compromise

A compromised email account can keep leaking messages through forwarding rules after its password is changed. Review mailbox rules, account-level forwarding and related application access as part of recovery. A successful login by the legitimate owner is not enough to prove the account is clean.

This workflow focuses on mail routing and persistence. It complements account containment rather than replacing it. Follow your provider's current incident procedure and use an authorized administrator for organization-level changes.

Contain the account and preserve relevant evidence

Record the discovery time, reported symptoms and authorized account owner. Restrict further attacker access using your organization's incident process, including session and credential actions supported by the provider. Preserve relevant sign-in and audit records before their retention window closes.

Do not delete every suspicious rule immediately if evidence is needed for an investigation. Capture its settings, creation or modification information where available and the destination addresses through an approved evidence process. Keep that material private; forwarding destinations can reveal personal or confidential relationships.

Microsoft's compromised-account response guidance includes mailbox-related investigation. Follow the current provider-specific controls rather than assuming that every mail service exposes the same settings or administrative commands.

Review more than the ordinary inbox rules screen

Look for rules that forward, redirect, delete, move or mark messages as read. A rule may conceal replies or security notices without forwarding everything. Review narrow conditions such as sender, subject terms and attachment presence.

Check account-level forwarding independently of per-message rules. If your platform supports hidden rules or administrative rule enumeration, use the documented administrative method. Also inspect delegates and application permissions according to the provider's incident procedure.

Build a small inventory of each setting and its owner-approved purpose. An unfamiliar rule is a reason to investigate, not proof of an attack. Legitimate sales, support and archiving workflows may involve external destinations, and their removal can disrupt business mail.

Compare against an approved baseline

{"mailbox":"redacted","rule_name":"supplier-notices",
 "action":"move","destination":"approved-folder",
 "owner_confirmed":true,"review_state":"expected"}

This synthetic record shows a review structure without exposing real email addresses. Compare sanitized inventories with JSON Diff or inspect them using JSON Viewer. These tools help review settings; they do not connect to the mailbox or determine whether a rule is malicious.

Where no baseline exists, ask the account owner or responsible team to explain the purpose of each important rule through your organization's process. Keep the distinction between confirmed legitimate, confirmed unauthorized and unresolved. Do not force uncertainty into a misleading clean/dirty binary.

Remove confirmed unauthorized routing

Use the provider's supported administrative interface to disable or remove confirmed unauthorized rules and forwarding. Document the exact change and verify the settings afterward. Avoid broad cleanup that removes legitimate routes unrelated to the compromise.

If an external destination received confidential mail, consider that data potentially disclosed. The incident scope depends on which messages matched, when the routing was active and whether delivery occurred. A rule's existence alone does not reveal every message it processed.

Review other mailboxes that share the same compromised administrator or automation identity when justified by evidence. Scope the investigation deliberately. Do not export every employee's mailbox simply because one user had a suspicious rule.

Test the restored mail flow

Send harmless test messages that exercise the conditions of the removed rule. Confirm expected delivery, folder placement and visibility. Avoid using real sensitive documents to prove that forwarding stopped.

Verify both incoming and outgoing behavior if the incident involved sent phishing mail or reply suppression. Check provider audit or message-trace evidence where available. An inbox screenshot shows one outcome, while routing evidence can establish whether the message was also sent somewhere else.

Record the test message identifiers and time. That lets another responder find the same event without retaining complete message contents. Keep any exported trace data within the incident's access policy.

Watch for reappearance

Monitor rule and forwarding changes for a defined recovery period. If an unauthorized rule returns, investigate remaining sessions, app grants, delegated access and administrator compromise. Repeating the same password reset without identifying the surviving access path is unlikely to solve persistence.

Assign an owner to unresolved findings and a date for the next review. Teams often complete immediate containment but leave ambiguous rules untouched indefinitely. A recovery checklist should end with reconciled findings, not merely a collection of screenshots.

Common blind spots

Deleting evidence before recording the settings makes later scoping harder. Reviewing only visible inbox rules can miss other routing mechanisms. Assuming that MFA prevents every persistence mechanism can also create false confidence after an account is recovered.

Conversely, treating all external forwarding as malicious can break legitimate business processes. The correct decision depends on authorization, observed changes and message-flow evidence. Keep those reasons attached to the finding.

Recovery includes where mail goes

Account recovery should restore authorized access and authorized routing. Inspect forwarding and rules, preserve useful evidence, remove confirmed unauthorized settings and test the resulting flow. Keep the final status explicit: recovered access, reviewed routing and any remaining uncertainty.