Join our Newsletter — 33% off our NHI Course
Home› Guides› How to Audit Mailbox Forwarding and Inbox Rules:…
Guide Email & Communications Security

How to Audit Mailbox Forwarding and Inbox Rules: Find Malicious Rules at Scale

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 11 November 2026 13 min read
On this page

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

ItemGoogle WorkspaceMicrosoft 365
Where forwarding is setUser automatic forwarding setting; Gmail filters with a forward action; admin routing settingsInbox rules (ForwardTo, RedirectTo, ForwardAsAttachmentTo); mailbox forwarding (ForwardingAddress, ForwardingSmtpAddress); mail flow (transport) rules
Tenant controlApps, Google Workspace, Gmail, End User Access: "Allow users to automatically forward incoming email", per organisational unit, with an option to limit to internal addressesOutbound spam policy automatic forwarding (Automatic, On, Off); remote domains; mail flow rules
Audit eventsUser accounts log event email_forwarding_out_of_domainNew-InboxRule, Set-InboxRule, UpdateInboxRules (Outlook client), Set-Mailbox
Bulk read pathGmail API settings.filters, settings.forwardingAddresses and getAutoForwarding, per userExchange Online PowerShell Get-InboxRule and Get-Mailbox per mailbox; Graph messageRules (MailboxSettings.Read)
Ready-made reportAdmin console reporting on user log eventsAuto 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. Score every row using the triage table below, then review from the top. Expect most rows to be internal, conditioned and old.
  7. 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.
  8. 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.
  9. Decide and contain (see the decision table), exporting the rule configuration and audit record before any removal.

Triage scoring

SignalWhy it mattersWeight (ours)
Destination is external and not the user's own documented second mailboxMicrosoft treats forwarding to a non-company, non-self address as the first indicatorHigh
Rule has no condition (forwards everything)Bulk exfiltration; Microsoft calls this out as suspiciousHigh
Conditions on words such as invoice, payment, finance, credentialsTargets payment fraud; Microsoft lists BodyContainsWords, SubjectContainsWords and SubjectOrBodyContainsWords as fields to readHigh
Action deletes, marks as read or moves to Notes, Junk Email, RSS Subscriptions or an archive folderHides replies from the real user (T1564.008)High
Rule is hiddenNot visible to the user or a default auditHigh 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-inLinks the rule to account takeoverHigh
Mailbox forwarding with DeliverToMailboxAndForward FalseThe user stops receiving their own mailMedium
Internal destination, conditioned, created years ago by the owner from a known deviceTypical legitimate ruleIgnore

Decision table

FindingDecisionNext action
High-score rule with suspicious creation contextMaliciousExport, 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 reasonLegitimate exceptionMove 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 ownerPolicy breach, not necessarily compromiseRemove under the email policy; data protection review if sensitive mail went out
Rule on a leaver's or shared mailbox with no ownerUnownedDisable, assign an owner, then decide
Malicious org-level mail flow or routing ruleAdmin compromiseEscalate; 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.
  • Alert on creation, not only on delivery: new or changed rules with external destinations, delete or move actions, or created from an unusual IP, using the events in the table above. The Google Workspace Audit Log Detection Guide and the Email Gateway and Message Trace Detection Guide cover the detection side.
  • 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.

Framework mapping

FrameworkReferenceHow this audit supports it
MITRE ATT&CK v20T1114.003 Email Forwarding Rule; T1564.008 Email Hiding Rules; T1078.004 Cloud AccountsFinds the persistence and hiding artefacts left after a cloud account is taken over
NIST SP 800-53 Rev 5AC-4 Information Flow Enforcement; AU-6 Audit Record Review, Analysis, and Reporting; SI-4 System MonitoringBlocks and reviews unapproved flows of mail out of the organisation
NIST CSF 2.0DE.CM-03; DE.AE-02; RS.MI-01Monitors user activity, analyses suspicious rules and contains confirmed ones

Practitioner checklist

  • Export the Auto forwarded messages report and the Gmail automatic forwarding setting per organisational unit.
  • Export mailbox forwarding fields for every mailbox, including shared and inactive ones.
  • Export every inbox rule with -IncludeHidden and -ResultSize Unlimited, and every Gmail filter and forwarding address.
  • Export organisation mail flow and routing rules.
  • Score every row, join creation context and pivot on destinations.
  • Export evidence, then remove malicious rules together with sessions, credentials and suspicious consents.
  • Set external forwarding explicitly and move legitimate cases to named exceptions with owners.
  • Alert on rule creation and schedule the sweep quarterly.

Standards and references

Related NHI Mgmt Group resources: T1114 Email Collection Defensive Guide · Business Email Compromise Response Playbook · Exchange Online Security Guide · Google Workspace Audit Log Detection Guide · Email Identity and BEC Guide

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.

Bonus 33% off our NHI Course when you subscribe.

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