A forwarding rule planted by an attacker keeps copying mail out of a mailbox long after the password has been reset, and most tenants have never looked at every rule in every mailbox. This guide is a single task done end to end: export every forwarding setting and inbox rule across a tenant, score the results so that a few hundred thousand rules become a short list, decide what is malicious, remove it safely and keep the estate clean afterwards. It covers Google Workspace and Microsoft 365 (listed alphabetically), using the vendors' own admin consoles, audit logs and APIs. It is written for messaging administrators, SOC analysts and incident responders. The attack itself, ATT&CK T1114.003 Email Forwarding Rule and T1564.008 Email Hiding Rules, is explained in the T1114 Email Collection Defensive Guide; this page is the audit procedure.
Key takeaways
Forwarding lives in four places, not one: user inbox rules, mailbox-level forwarding set by an administrator, organisation mail flow or routing rules, and (in Gmail) the account's automatic forwarding setting plus filters that forward. Audit all four or the sweep has a hole.
Hidden rules need an explicit switch: Microsoft's Get-InboxRule omits hidden rules unless you add -IncludeHidden, so an audit run without it misses the rules attackers hide on purpose.
Score, do not eyeball: external destination, no condition or finance keyword conditions, delete or move-to-obscure-folder actions, and creation from an unusual IP or shortly after a risky sign-in separate the few malicious rules from the many harmless ones.
Export before you delete: the rule, its creation event and the forwarding destination are evidence for scoping what left the organisation; remove the rule only after the export is saved.
Prevention makes the audit small: blocking automatic external forwarding at tenant level (with named exceptions) turns most malicious forwarding into a failed delivery and leaves hiding rules as the main thing to hunt.
When you need this
After any confirmed mailbox compromise: Microsoft lists suspicious inbox rules that forward mail or move it to the Notes, Junk Email or RSS Subscriptions folders, and recently added external forwarding, among the signs of a compromised account. Check the affected mailbox first, then the whole tenant, because the same destination often appears in several compromised mailboxes.
Before switching off external forwarding: you need the list of legitimate forwarders to agree exceptions with the business.
As a baseline and a recurring control: a quarterly tenant-wide sweep (our recommendation) catches rules created before alerting existed, or created through a path your alerts do not see.
During business email compromise response: the Business Email Compromise Response Playbook calls for removing forwarding and hidden rules as persistence; this page shows how to find them across all users, not only the reported one.
Before you start
Item
Google Workspace
Microsoft 365
Where forwarding is set
User automatic forwarding setting; Gmail filters with a forward action; admin routing settings
Apps, Google Workspace, Gmail, End User Access: "Allow users to automatically forward incoming email", per organisational unit, with an option to limit to internal addresses
Outbound spam policy automatic forwarding (Automatic, On, Off); remote domains; mail flow rules
Audit events
User accounts log event email_forwarding_out_of_domain
Gmail API settings.filters, settings.forwardingAddresses and getAutoForwarding, per user
Exchange Online PowerShell Get-InboxRule and Get-Mailbox per mailbox; Graph messageRules (MailboxSettings.Read)
Ready-made report
Admin console reporting on user log events
Auto forwarded messages report in the Exchange admin center (forwarding type, recipient domain, forwarder, count, first forward date; up to 90 days on the summary page)
Permissions: Microsoft documents that Get-InboxRule does not work for members of the View-Only Organization Management role group or the Entra Global Reader role, so a read-only auditor needs a custom role or a scoped admin to run it. Grant the least role that works and remove it after the sweep. In Google Workspace, per-user Gmail settings are read through the Gmail API as each user, which in practice means a service account with domain-wide delegation; treat that delegation as a privileged non-human identity, scope it to read-only settings scopes and remove it when not in use. See the Google Workspace Domain-Wide Delegation Security Guide.
Logging: confirm unified audit logging (Microsoft 365) and Gmail and user log events (Google Workspace) are on and exported to your SIEM, so creation events exist for the rules you find. Retention depends on licence; confirm the current value in each vendor's docs.
Agreed list of internal domains: every accepted domain, subdomain and alias. Forwarding to these is internal and scores low.
Change record: the sweep is read-only, but removal is a change. Get approval for "remove confirmed malicious forwarding and rules" in advance so containment is not delayed.
Step-by-step
Take the tenant-level view first. In Microsoft 365, open the Auto forwarded messages report and export it to CSV; it shows each forwarder, whether the forwarding came from an inbox rule, SMTP forwarding or a mail flow rule, the recipient domain, the forward count and the first forward date. Note the outbound spam policy setting: Microsoft says the Automatic value behaved differently for older and newer organisations and recommends setting an explicit value. In Google Workspace, record the automatic forwarding setting for each organisational unit and pull user log events for email_forwarding_out_of_domain for the look-back period.
Export mailbox-level forwarding for every mailbox. In Exchange Online PowerShell, enumerate all mailboxes and record ForwardingAddress, ForwardingSmtpAddress and DeliverToMailboxAndForward (the fields Microsoft's compromise-response article tells you to check). A non-blank ForwardingSmtpAddress means external forwarding; DeliverToMailboxAndForward False means the user no longer receives the mail at all. Include shared mailboxes, resource mailboxes and inactive users.
Export every inbox rule, including hidden ones. For each mailbox run Get-InboxRule -Mailbox <UPN> -IncludeHidden -ResultSize Unlimited (the default result size in Exchange Online is 1,000) and keep, per rule: mailbox, name, enabled, identity, conditions, ForwardTo, RedirectTo, ForwardAsAttachmentTo, delete and move actions and mark-as-read. On large tenants run it in batches and throttle; Graph GET /users/{id}/mailFolders/inbox/messageRules with MailboxSettings.Read is an alternative read path for visible rules. In Google Workspace, list each user's filters through settings.filters, their forwarding addresses and status through settings.forwardingAddresses, and their auto-forwarding state through getAutoForwarding.
Export organisation-level rules. Microsoft 365 mail flow rules (Get-TransportRule; the Auto forwarded messages report gives the rule ID when a transport rule forwarded mail) and Google Workspace routing settings. These are changed by administrators, so a malicious one points to an admin compromise and moves the incident up a level.
Normalise into one table. One row per forwarding path: platform, mailbox, path type (inbox rule, filter, mailbox forwarding, auto-forwarding, org rule), destination address and domain, internal or external, conditions, actions, enabled, hidden, created or modified time and who made the change (joined from audit events).
Score every row using the triage table below, then review from the top. Expect most rows to be internal, conditioned and old.
Join creation context for anything that scores medium or higher. Microsoft's alert-grading playbook for suspicious forwarding rules uses the CloudAppEvents table in advanced hunting, filtering ActionType on New-InboxRule, Set-InboxRule and Set-Mailbox and reading the rule parameters from RawEventData, then compares the creating IP's ISP, country and user agent with the user's previous 30 days. In Google Workspace, line up the forwarding event with login events for the same user.
Pivot on the destination. Search all rows and all rule-creation events for the same destination address or domain. Microsoft's playbook includes a query for exactly this, because one destination across several mailboxes means several compromised accounts.
Decide and contain (see the decision table), exporting the rule configuration and audit record before any removal.
Triage scoring
Signal
Why it matters
Weight (ours)
Destination is external and not the user's own documented second mailbox
Microsoft treats forwarding to a non-company, non-self address as the first indicator
High
Rule has no condition (forwards everything)
Bulk exfiltration; Microsoft calls this out as suspicious
High
Conditions on words such as invoice, payment, finance, credentials
Targets payment fraud; Microsoft lists BodyContainsWords, SubjectContainsWords and SubjectOrBodyContainsWords as fields to read
High
Action deletes, marks as read or moves to Notes, Junk Email, RSS Subscriptions or an archive folder
Hides replies from the real user (T1564.008)
High
Rule is hidden
Not visible to the user or a default audit
High once system rules are baselined
Created from an IP, ISP, country or user agent the user has not used in 30 days, or within a day of a risky sign-in
Links the rule to account takeover
High
Mailbox forwarding with DeliverToMailboxAndForward False
The user stops receiving their own mail
Medium
Internal destination, conditioned, created years ago by the owner from a known device
Typical legitimate rule
Ignore
Decision table
Finding
Decision
Next action
High-score rule with suspicious creation context
Malicious
Export, disable or remove, reset credentials and revoke sessions, review sign-ins, scope forwarded mail, open an incident
External forwarding the owner confirms in writing, for a business reason
Legitimate exception
Move it to an approved mechanism (remote domain allow list or Gmail internal-only setting with an exception OU), record owner and review date
Forwarding to a personal address by the mailbox owner
Policy breach, not necessarily compromise
Remove under the email policy; data protection review if sensitive mail went out
Rule on a leaver's or shared mailbox with no owner
Unowned
Disable, assign an owner, then decide
Malicious org-level mail flow or routing rule
Admin compromise
Escalate; treat as tenant compromise and review all admin activity
Verify it worked
Re-run the export for the affected mailboxes and confirm the rules and forwarding values are gone, including with -IncludeHidden.
Watch delivery: in Microsoft 365, the Auto forwarded messages report should show no new forwards from the mailbox. If external forwarding is blocked by the outbound spam policy, any remaining attempt generates NDR 5.7.520 Access denied, Your organization does not allow external forwarding, which is itself a useful alert.
Check for re-creation: alert on the same destination appearing again in any rule-creation event for 30 days, because an attacker who still holds a token or another account will try again.
Coverage check: the number of mailboxes scanned equals the number of mailboxes in the tenant, and failures (throttling, permission errors) are listed and re-run.
Measures that show the control is working
Share of mailboxes scanned in the last quarterly sweep (target 100 percent).
Mailboxes with external forwarding outside the approved exception list (target zero).
Median time from rule creation to alert for high-score rules.
Number of approved forwarding exceptions, each with an owner and an unexpired review date.
Rules re-created after removal (should trend to zero once credentials and sessions are cleaned up).
Rollback and common errors
Removed a legitimate rule: because you exported the full configuration first, re-create it from the export, or ask the owner to re-create it. This is why export comes before removal.
Audit missed hidden rules: the export was run without -IncludeHidden. Re-run it.
Results stop at 1,000:-ResultSize was left at its Exchange Online default.
Permission errors from a read-only account: Global Reader and View-Only Organization Management cannot run Get-InboxRule; use a scoped role.
Removing the rule but not the access: a rule removed while the attacker still holds a session or an OAuth grant is re-created within hours. Revoke sessions and review consents in the same change; see the Consent Phishing and Illicit OAuth Grants Guide.
Switching off external forwarding without a list of exceptions: Microsoft notes that setting automatic forwarding to Off also disables existing inbox rules and mailbox forwarding to external addresses, so legitimate workflows break at once. Use the export to agree exceptions first.
Hardening afterwards
Set external forwarding explicitly: in Microsoft 365, set the outbound spam policy to Off, or to On with remote domains limiting where forwarding may go; Microsoft notes that when one control allows and another blocks, the block typically wins. In Google Workspace, limit automatic forwarding to internal addresses for most organisational units and put approved exceptions in their own unit. See the Exchange Online Security Guide and the Google Workspace Security Guide.
Track forwarding on organisations still routing on-premises mail through Microsoft 365: Microsoft suggests a mail flow rule that matches the X-MS-Exchange-Inbox-Rules-Loop header and sets an incident severity so the activity appears in the transport rule report.
Cover non-human mail access: applications and agents that can create rules or read mail through APIs carry the same risk with no user to notice. Inventory them; see the AI Agent Email Access Security.
Schedule the sweep: run the export quarterly (our recommendation) and keep each run as audit evidence.
NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 11 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security.
nhimg.org
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.