They should be able to detect new forwarding, deletion, or filtering rules soon after they are created and tie them to the originating sign-in event. Effective monitoring also flags whether the rule targets external mailboxes or keywords linked to invoices, wire transfers, or payroll. If rules are only reviewed after an incident, the control is too weak.
Why This Matters for Security Teams
Inbox-rule monitoring is one of the few controls that can reveal post-compromise abuse before an attacker turns a mailbox into a long-term access path. It matters because malicious forwarding and filtering rules often bypass password resets, MFA challenges, and even some EDR alerts. Security teams should treat rule activity as an identity and email-control problem, not just an email hygiene task, because the risk sits at the intersection of account takeover, business email compromise, and data exfiltration. NIST SP 800-53 Rev. 5 Security and Privacy Controls gives useful context for monitoring, logging, and incident response expectations, but the practical test is whether the organisation can see suspicious rule creation fast enough to act.
The common mistake is focusing on whether any mailbox audit logs exist, rather than whether those logs are complete, retained, and correlated with sign-in telemetry. A rule created after a risky login is far more meaningful than a rule discovered days later during a fraud investigation. Teams also underestimate how often attackers blend in with legitimate automation, using normal-looking names, broad filters, or forwarding to cloud storage instead of obvious spam indicators. In practice, many security teams encounter inbox-rule abuse only after payment diversion or mailbox tampering has already occurred, rather than through intentional early detection.
How It Works in Practice
Effective monitoring starts with telemetry from the mail platform itself, then adds identity context from the authentication layer and alerting from the SOC. The goal is to detect when a new rule is created, changed, or removed, and to understand whether that rule changes message flow in a way that benefits an attacker. The most useful detections are not limited to “forwarding enabled.” They also watch for hidden rules, auto-delete actions, message marking, inbox moves, sender-based filters, and rules that route mail outside the tenant.
Security teams should baseline normal automation first. Many organisations legitimately use inbox rules for ticketing, alerts, or executive assistance. Without that baseline, rule monitoring creates noise and gets ignored. The better approach is to enrich each event with:
- source user, device, IP, and geo context
- the preceding sign-in result and risk score
- the exact rule action and target mailbox or external recipient
- whether the rule was created from a new session, legacy protocol, or uncommon client
- keywords or conditions that suggest invoice, payroll, wire transfer, or executive impersonation targeting
Teams should also compare rule creation against mailbox access and OAuth consent events, because attackers often combine these paths to preserve access. Alert logic is stronger when it chains together suspicious sign-in, new inbox rule, and external forwarding within a short window. For operational guidance on logging and monitoring expectations, many teams map the control to NIST SP 800-53 Rev 5 Security and Privacy Controls and pair it with mailbox audit review procedures. Microsoft’s guidance on Microsoft 365 auditing is also useful where that platform is in scope, especially for event provenance and retention planning. These controls tend to break down in hybrid mail environments because rule events, sign-in logs, and forwarding policies are split across multiple consoles with inconsistent retention.
Common Variations and Edge Cases
Tighter inbox-rule monitoring often increases alert volume and analyst workload, requiring organisations to balance faster detection against false positives from legitimate delegation and automation. That tradeoff becomes sharper in environments with shared mailboxes, executive assistants, legal holds, and business process automation, where rule creation may be normal but still risky if it expands message visibility or exfiltrates content.
Current guidance suggests monitoring should be tuned by mailbox sensitivity rather than applied identically to every user. Finance, HR, legal, and senior leadership mailboxes deserve stricter thresholds because those accounts are repeatedly targeted for fraud and data theft. There is no universal standard for how much delay is acceptable, but the operational test is whether the SOC can review high-risk rule events before the mailbox is used to send a fraudulent reply or hide a payment request.
Edge cases also matter. Some attackers avoid forwarding entirely and instead delete warnings, archive replies, or bury messages with sender-specific rules that are hard to spot in a casual review. Others create rules through IMAP, legacy protocols, or delegated access, which means monitoring must include the creation path, not only the final rule state. Where identity governance is weak, inbox-rule detection is only one layer of mailbox abuse monitoring and should be paired with access reviews, conditional access, and response playbooks aligned to CISA incident response guidance and zero trust principles only as general reference points, not substitutes for platform-specific controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Mailbox rule monitoring is a continuous monitoring problem tied to anomalous activity detection. |
| MITRE ATT&CK | T1114.003 | Email Collection via Email Forwarding Rule matches the abuse pattern this question addresses. |
Instrument mail telemetry and alert on rule creation, change, and suspicious forwarding in near real time.
Related resources from NHI Mgmt Group
- How do security teams know if post-login monitoring is actually working?
- How do security teams know whether carrier monitoring is actually working?
- How should security teams measure whether DLP monitoring is actually working?
- How do security teams know if Active Directory hardening is actually working?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
