How does an email rule work?

How an email rule processes messages

An email rule is a mail-client or server-side automation that evaluates incoming or existing messages against conditions, then performs an action such as moving, forwarding, deleting, flagging or categorising. The useful mental model is simple: condition first, action second. The exact behaviour depends on where the rule runs, because server-side rules act even when the mailbox owner is offline.

That distinction matters because server-side rules are harder to notice and can affect every device or client that reads the mailbox. A rule can be triggered by sender, recipient, subject, keywords, attachment patterns or message headers, and the action may apply immediately or on a schedule depending on the platform.

Why attackers target mailbox rules after compromise

Once an attacker controls a mailbox, rules become a low-noise way to shape what the victim sees. They can hide security alerts, suppress password reset notices, auto-forward mail to another inbox, or quietly file away messages that would expose the compromise. A malicious rule can also act as persistence, because it continues to work after the attacker loses interactive access.

In practice, the danger is not the rule mechanism itself but the trust it inherits from the mailbox owner. If a rule is created using legitimate mailbox privileges, many organisations will treat the resulting mail flow as normal unless they monitor for unusual rule creation, forwarding destinations, or unexpected deletions. For a broader view of mail protections and remediation paths, see the Email Security Guide.

How to review and constrain rules safely

Good rule hygiene starts with inventory and visibility. Review client-side and server-side rules separately, because they may live in different settings pages and may not behave the same way. Pay particular attention to rules that forward externally, delete messages, mark mail as read, move messages out of the inbox, or match on security-related keywords such as password reset, MFA, invoice, or alert.

Rules should be treated as a mailbox governance control, not just a convenience feature. The safest pattern is to allow simple user productivity rules while restricting automatic forwarding to untrusted destinations, logging rule changes, and investigating any rule created shortly after a suspicious sign-in or consent event. In larger environments, rule review should be part of mailbox compromise response, not only routine administration.

Risk and Threat Considerations

Email rules are attractive to attackers because they convert a one-time mailbox compromise into ongoing control over message flow. The most common failure mode is silent manipulation of alerts and business mail, which delays detection and can let an intruder remain hidden long enough to harvest resets, approvals, or internal communications.

Failure mechanism: A rule can divert, suppress or auto-handle messages before the user notices, especially when the rule is created with valid mailbox access and applied server-side.

Impact: Victims may miss security notifications, lose visibility into account recovery activity, or unknowingly forward sensitive mail outside the organisation, increasing the chance of persistence and data exposure.

Practitioner Guidance

What to verify: Check whether the rule is server-side, whether it forwards outside the tenant or domain, and whether it was created or modified near a suspicious authentication event. Those three facts usually tell you whether the rule is a convenience setting or a compromise indicator.

Decision rule: If a rule can move or forward messages that affect account recovery, approvals or executive mail, treat it as a containment issue first and a usability issue second. Remove the rule, review recent mailbox activity, and confirm whether any other forwarding or delegation exists before closing the case.

Practitioner takeaway: The security question is not whether a rule exists, but whether it changes who sees the message and when, because that is what turns a normal inbox feature into an abuse path.

Related resources from NHI Mgmt Group

• Why do email impersonation attacks still work in Zero Trust programmes?
• Why does credential phishing still work in organisations with mature email security?
• Why do poisoned tenant attacks work even when email authentication passes?
• Which governance model should apply to email flowing into downstream work systems?