Mail flow rules are how you tell Exchange Online to do something to a message based on conditions you set — add a disclaimer, warn on external senders, block a risky attachment type, or route certain mail to a specific connector. If you’ve used Outlook rules, the idea is familiar, but these run on the server for the whole organization, not in one person’s mailbox.
This guide covers building a rule in the Exchange admin center and in PowerShell, the condition/action/exception model that every rule follows, and the practical patterns most tenants actually need. It also covers the part that bites people: rule order and test mode. Get those wrong and a rule either never fires or fires on everything.
How a mail flow rule is built
Every rule is the same three parts. Once this clicks, the portal builder makes sense.
The three parts of every rule
| Conditions | When the rule applies — e.g. sender is outside the org, subject contains a word |
|---|---|
| Actions | What it does — e.g. prepend a disclaimer, reject, redirect, set a header |
| Exceptions | When to skip it even if the condition matched — e.g. except a trusted domain |
A rule with no conditions applies to all mail, which is occasionally what you want and usually not. Exceptions always win over conditions, so they’re your safety valve for the one sender or domain that shouldn’t be caught.
Create a rule in the Exchange admin center
The EAC builder is the right place to start, especially for your first few rules.
- Sign in to the Exchange admin center (
admin.exchange.microsoft.com). - Go to Mail flow → Rules.
- Click Add a rule (+). You can start from a template (like “Apply disclaimers”) or Create a new rule.
- Give the rule a clear name — future-you will thank you.
- Set Apply this rule if… (the condition), Do the following… (the action), and Except if… (the exception).
- Set the rule mode. Start in Test if the rule blocks or redirects mail.
- Set the priority, then Save.
Pattern 1: Warn on external senders
This is the most common request — flag mail from outside the organization so users are wary of impersonation. In the EAC, the condition is The sender is located → Outside the organization, and the action is Prepend the disclaimer. In PowerShell:
Connect-ExchangeOnline
New-TransportRule -Name "External sender warning" `
-FromScope NotInOrganization `
-SentToScope InOrganization `
-ApplyHtmlDisclaimerLocation Prepend `
-ApplyHtmlDisclaimerText "<div style='background:#fff3cd;padding:8px;border:1px solid #ffe69c;'><b>CAUTION:</b> This email came from outside your organization. Don't click links or open attachments unless you recognize the sender.</div>" `
-ApplyHtmlDisclaimerFallbackAction WrapTo avoid stacking the banner on every reply in a thread, add an exception so the rule skips messages that already contain the warning text. The cleaner long-term approach is the native external sender tag in Outlook, but the rule above works everywhere and gives you full control over the wording.
Pattern 2: Block risky attachment types
To stop executable and script attachments at the gateway, match on attachment file type and reject the message. In the EAC: condition Any attachment → file extension matches, action Block the message → reject and return a message. In PowerShell:
New-TransportRule -Name "Block executable and script attachments" `
-AttachmentExtensionMatchesWords @("exe","js","vbs","scr","bat","cmd","jar","ps1") `
-RejectMessageReasonText "This attachment type is blocked by company policy. Contact IT if you need to receive this file." `
-RejectMessageEnhancedStatusCode "5.7.1"This handles routing and policy, not malware scanning. Keep it alongside Defender for Office 365 — see Safe Links vs Safe Attachments for the scanning side, which catches threats a static extension block never will.
Pattern 3: Add a company disclaimer
A standard footer on outbound mail is a classic disclaimer rule: condition sender is inside the organization, action prepend or append a disclaimer.
New-TransportRule -Name "Company footer" `
-FromScope InOrganization `
-SentToScope NotInOrganization `
-ApplyHtmlDisclaimerLocation Append `
-ApplyHtmlDisclaimerText "<hr><p style='font-size:11px;color:#666;'>Contoso Ltd. This message is confidential and intended only for the named recipient.</p>" `
-ApplyHtmlDisclaimerFallbackAction WrapThe FallbackAction matters: Wrap keeps the original message intact if the disclaimer can’t be applied (for example, on signed or encrypted mail), instead of dropping it.
Rule order and the “stop processing” trap
Rules run top to bottom by priority — the lowest number first. By default, processing continues to the next rule after a match. That’s fine until two rules collide.
Rule order behavior
| Priority | Lower number runs first (0 is first) |
|---|---|
| After a match | Next rule still runs unless you stop it |
| Stop processing more rules | An action that makes the current rule the last one to apply |
| Exceptions | Always override conditions on the same rule |
If a broad “block this domain” rule sits below a “redirect for review” rule, mail might get redirected and blocked, or one might never fire. Order rules deliberately, and add Stop processing more rules when a match should be the final word.
Before you flip a rule on
A short pre-flight check saves cleanup later.
Before enabling a mail flow rule
- The rule has a clear, descriptive name
- Conditions are specific enough not to catch unintended mail
- Exceptions cover the senders/domains that must not be affected
- Priority is set so it runs in the right order with existing rules
- Blocking/redirecting rules start in test mode
- You know how you'll verify it (message trace)
After it’s live, confirm it’s behaving with message trace in Exchange Online, which shows whether a rule acted on a given message and why. If a rule is the reason mail isn’t arriving, the broader checklist in Microsoft 365 email not sending or receiving helps you separate a rule problem from a mail flow or DNS one.
Manage rules with PowerShell
For auditing or bulk changes, PowerShell beats clicking through the portal. A few useful commands:
# List all rules with priority and state
Get-TransportRule | Format-Table Name, Priority, State, Mode -AutoSize
# Disable a rule without deleting it
Disable-TransportRule -Identity "Block executable and script attachments"
# Change a rule's priority (0 runs first)
Set-TransportRule -Identity "External sender warning" -Priority 0
# Export all rules to a file for backup
Get-TransportRule | Export-Clixml C:\Temp\transport-rules-backup.xmlExport your rules before making big changes. Rebuilding a complex rule set from memory is no fun.
Wrapping up
Mail flow rules follow one model: conditions, actions, exceptions, in priority order. Build the common ones — external warnings, attachment blocks, disclaimers — in the EAC or with New-TransportRule, and lean on test mode before enforcing anything that blocks or redirects. Watch rule order and use “stop processing” when a match should be final. They’re powerful for routing and custom handling, but they sit alongside your anti-spam and anti-phishing protection, not in place of it.
