How to Manage Mail Flow Rules in Exchange

4.5K

You can use the Exchange Admin Center (EAC) web interface to create and edit an Exchange transport rule. In this example, we will create a transport rule in EOL.

About mail flow rules

Exchange Transport Rules (ETRs), also known as Mail Flow rules, are used to select and apply various actions to messages based on specific criteria as they flow through your Exchange organization. Mail flow rules are available in Exchange Online and in supported on-premises Exchange Server deployments, including Exchange Server Subscription Edition (SE).

Note. In modern Microsoft 365 environments, many compliance-related cases that were previously handled by mail flow rules have moved to Microsoft Purview and Microsoft Defender for Office 365. Mail flow rules are now primarily used for message routing, basic blocking, and simple transformations rather than compliance enforcement.

Rule evaluation order and processing behavior

Keep in mind that in Exchange Online (EOP), mail flow rules are processed in a strict priority order. Here are the main characteristics:

• Rules are evaluated from lowest number (highest priority) to highest number (lowest priority)
• Each message is evaluated sequentially against all applicable rules
• If a rule has “Stop processing more rules” enabled, no further rules are evaluated
• Multiple matching rules can apply unless processing is explicitly stopped

Mail flow rule limits and scalability

Exchange Online imposes service limits on mail flow rules, including limits on the number of rules that can be configured and on the size or complexity of certain rule conditions and patterns. You need to review the current Microsoft documentation for the applicable limits before designing a large rule set.

In large organizations, mail flow rules can become difficult to manage long before you hit Exchange Online’s service limits. You should avoid creating overlapping rules/making conditions more complex than necessary. Large lists of domains, addresses, keywords, or regular expressions can make rules harder to understand, maintain, and troubleshoot.

When a requirement becomes too complex for a manageable transport rule, you should consider whether the logic should be consolidated, split into smaller rules, or implemented through a more appropriate Microsoft Defender/Microsoft Purview policy.

Rule conflict and precedence behavior

If you have a situation when multiple transport rules match the same message:

• All matching rules are applied unless a rule stops processing
• Actions are cumulative (unless they conflict, e.g., reject vs modify)
• Reject/block actions take precedence and terminate message processing
• More specific conditions should be placed at higher priority (lower number)

Where mail flow rules sit in the Microsoft 365 email security pipeline

Note that in Microsoft 365, mail flow rules (Exchange Transport Rules) operate within the Exchange Online Protection (EOP) transport pipeline.

Mail flow rules are part of the Exchange Online transport/policy-processing pipeline. They operate alongside, rather than simply before or after, the various EOP and Defender protection layers. The exact processing order depends on the message type and protection feature involved.

Mail flow rules are evaluated during transport. It means that:

• they act before final mailbox delivery
• they can modify, block, or redirect messages before they are stored
• they do not replace post-delivery security controls

Important. Note that mail flow rules operate in the transport layer. Defender policies can still evaluate and act on messages after transport rule processing, including post-delivery remediation.

Elements of Exchange mail flow rule

The Exchange mail flow rule consists of four elements:

• Conditions — allows you to define criteria for the selection of emails to which rules are to be applied. For example, sender/recipient email address or domain, message direction, email subject, etc.
• Actions — action to be taken on messages when a configuration condition is met.
• Exceptions — allows you to specify attributes of an email message for which you want to skip the actions.
• Mode — whether to apply the rule immediately (Enforce) or run it in test mode first (Test with/without Policy Tips).

Exchange Online and Hybrid Considerations

Mail flow rules behave differently depending on whether you use Exchange Online/on-premises Exchange Server.

For Exchange Online (Microsoft 365)

• Rules are processed in a distributed cloud environment (EOP)
• Changes may take time to propagate across datacenters (typically minutes, sometimes longer)
• Rule evaluation is subject to service-side throttling and backend optimization
• Some actions depend on Defender for Office 365 or Purview services

For on-premises Exchange Server

• Rules are evaluated locally on Transport servers
• You have a full control over transport pipeline behavior

Hybrid environments

Keep in mind that in hybrid Exchange deployments:

• Mail may pass through both on-prem transport and Exchange Online Protection (EOP)
• Rule evaluation depends on mail routing path (inbound vs outbound vs internal relay)
• Some rules may be evaluated twice (once on-prem, once in EXO)
• Misconfigured connectors can cause inconsistent rule behavior

Rule propagation and latency considerations

Note that in Exchange Online, transport rule changes are not always immediate:

• Typical propagation delay is 1–10 minutes
• In large tenants delay can be up to 30 minutes
• Cached routing decisions may temporarily ignore new rules

As the best practice, we recommend you to wait before testing new rules in production and use Message Trace to validate rule application.

Permissions required to manage mail flow rules

Your Exchange RBAC permissions determine what you can do with mail flow rules. To create, modify, enable, or remove transport rules, you need the appropriate Exchange permissions.

The Transport Rules role provides permissions for managing mail flow rules. Broader administrative roles, such as Organization Management, can also provide the required access, but assigning broad roles solely to manage transport rules is generally not recommended for production administration.

In enterprise environments, give admins only the Exchange permissions they actually need. Before making a change in production, you should check if the account or administrative group has the required Exchange RBAC role.

Creating a mail flow rule

Note. When creating multiple transport rules, you should always consider rule priority. Incorrect ordering may result in bypassed blocking rules, unintended message modifications, or conflicting actions. We recommend designing rule priority together with explicit exceptions and using Stop processing more rules only when required.

Let’s create a mail flow rule that prevents unauthorized outbound mail to the gmail.com domain.

1. Sign in to Exchange Admin Center: https://admin.exchange.microsoft.com/
2. Navigate to Mail flow > Rules.
3. Click Add a rule.
   

   

4. Select Create a new rule.
5. Specify the rule name: Block outbound email to Gmail.
6. Configure the rule conditions:
   Apply this rule if:
   The sender is located → Inside the organization
   The recipient → domain is → gmail.com
7. Configure appropriate exceptions for legitimate business communication:
   Except if:
   – the sender is an approved user or member of an approved group; or
   – the recipient belongs to an approved partner domain or workflow.
   The exact exceptions should reflect your organization’s approved external-mail requirements.
8. Configure the action. Under Do the following, select Block the message and choose reject the message and include an explanation. Enter Not authorized recipient as the rejection message.
9. For a production environment, start with an appropriate test mode rather than immediately enforcing the rule. Send representative test messages and use Message Trace to verify the expected behavior.
10. Verify both the blocking and exception cases:
    – an unauthorized sender is blocked when sending to gmail.com;
    – an approved sender or approved workflow is allowed to send to the permitted external recipient.
11. After successful testing, change the rule to Enforce and enable the rule.
    

    

Enterprise consideration. You should avoid blanket external-domain blocks without first identifying legitimate business communication, apps, service accounts, and partner workflows. Explicit exceptions and pre-production testing help prevent the rule from disrupting approved business processes.

Note that a domain-based mail flow rule is a deterministic transport control, not a replacement for Microsoft Defender or Microsoft Purview security policies.

When mail flow rules are still appropriate?

Despite modern alternatives in Microsoft Purview and Defender for Office 365, transport rules are still useful in such cases:

• you need immediate message-level enforcement without policy dependency
• the requirement is purely deterministic (e.g., block/allow based on domain or header)
• you operate in on-prem/hybrid environments without full Defender integration
• you need predictable, transparent rule execution for troubleshooting purposes

Note that in modern Microsoft 365 environments, you generally should not use domain-based blocking as the primary security mechanism (however, it may still be acceptable as a supplementary/temporary control depending on the case).

Here are the recommended modern approaches instead of simple domain blocking:

• Outbound anti-spam policies in Microsoft Defender for Office 365 (restrict/control external email flow at tenant level)
• Tenant-wide external access restrictions (Microsoft 365 admin center → Org-wide settings → External communications)
• Policy-based controls in Microsoft Defender for Office 365 for advanced outbound filtering and risk-based decisions

Here is a comparison table:

Method	Status in 2026	Use case
Mail flow rule (block domain)	Legacy/limited use	Simple blocking/lab environments
Outbound spam policy	Recommended	Tenant-level external mail control
Defender for Office 365 policies	Recommended	Security-driven filtering and risk analysis

Also note that while mail flow rules can still block specific domains, we recommend using outbound anti-spam policies/tenant-wide restrictions in Microsoft Defender for Office 365 for more advanced and secure control cases.

Note. For new compliance and data-loss prevention cases, Microsoft recommends Microsoft Purview DLP policies. That said, Exchange mail flow rules are still useful for controlling messages as they pass through Exchange, and some of their capabilities overlap with compliance cases.

What mail flow rules are still used for in 2026?

Despite the shift toward Microsoft Purview and Microsoft Defender for Office 365, you can still use mail flow rules for operational cases that require deterministic message processing.

Here are the common valid use cases:

• When you need to add disclaimers/legal banners to outgoing emails
• Modifying message routing (e.g., redirecting, forwarding, or journaling)
• Tagging/stamping messages with headers for downstream systems
• Simple conditional blocking based on sender/recipient/keywords
• Internal message normalization (subject prefixing, footer enforcement)

It is important to note that you should not consider these cases as security enforcement mechanisms in modern Microsoft 365 architecture, but rather message processing and transport control functions.

Use PowerShell to manage Exchange transport rules

Because mail flow rules still play an important role in message processing, you can manage and automate them using PowerShell in both hybrid and cloud environments.

You can use PowerShell to manage Exchange transport rules. The following cmdlets are used:

• Get-TransportRule
• New-TransportRule
• Remove-TransportRule
• Enable-TransportRule
• Disable-TransportRule

Note. In Exchange Online environments, typically you can perform transport rule management using the ExchangeOnlineManagement PowerShell module. However, keep in mind that modern cmdlets are REST-backed and may require Connect-ExchangeOnline authentication.

Keep in mind that in Exchange Online, PowerShell cmdlets for transport rules are executed against a distributed service layer. As a result, changes may not reflect instantly due to backend sync.

Authentication for automation

For interactive administration, you can connect to Exchange Online PowerShell with modern authentication by running:

Connect-ExchangeOnline

For unattended scripts, scheduled tasks, and other automation, don’t rely on interactive sign-ins or store user credentials. Instead, use app-only authentication with a Microsoft Entra app and certificate. Note that the app must have the required Exchange permissions, including the Exchange.ManageAsApp application permission and appropriate Exchange RBAC permissions.

For Azure-hosted automation, managed identities are another option and can eliminate the need to manage certificates/secrets.

For example, an app-only connection can be established with a certificate thumbprint:

Connect-ExchangeOnline `
-CertificateThumbprint $CertificateThumbprint `
-AppId $AppId `
-Organization "contoso.onmicrosoft.com"

Assign the automation account only the Exchange RBAC roles and permissions required for its tasks.  You should avoid granting broad admin roles when a more limited role is sufficient to manage transport rules.

Let’s use PowerShell to create a similar rule that will block outgoing e-mail to a specific domain:

New-TransportRule `
-Name "Block outbound mail to test.com" `
-FromScope InOrganization `
-RecipientDomainIs "test.com" `
-RejectMessageEnhancedStatusCode "5.7.1" `
-RejectMessageReasonText "Not authorized recipient"

In case the rule must run at a specific position, you should use Set-TransportRule -Priority after reviewing the existing rule order. Do not assume that priority 0 is appropriate for every new rule!

Get-TransportRule |
Sort-Object Priority |
Format-Table Name, Priority, State, Mode

You can use the Priority parameter to specify the order in which transport rules are processed. The rule with the Priority 0 parameter has the highest priority.

Test a mail flow rule before enforcing it

Before enabling a new mail flow rule in production, create it in test mode and validate its behavior first. In Exchange Online, test the rule against messages that should match and messages that should not match it. Once the results are as expected, enable the rule in production.

For PowerShell-based testing, Exchange Online provides the Test-Message cmdlet. It can simulate the effect of transport rules against a test message without requiring you to deliver that message through normal production mail flow.

For example, you can test a saved .eml file against the transport rules:

$data = [System.IO.File]::ReadAllBytes('C:\Data\test.eml')

Test-Message `
-MessageFileData $data `
-Sender sender@contoso.com `
-Recipients recipient@contoso.com `
-SendReportTo admin@contoso.com `
-TransportRules

After sending controlled test messages, use Message Trace in order to verify how Exchange Online processed them. The trace details can show whether a mail flow rule was applied and, where available, which rule matched the message and what action was taken.

Test at least one message that should match the rule and one that should not. For rules with exceptions or complex conditions, you should also test the exception path and interactions with other mail flow rules.

Only after the expected behavior has been confirmed should you change the rule mode to Enforce.

Disable mail flow rule

Get-TransportRule "Block to test.com"| Disable-TransportRule

Checking rule priority

Get-TransportRule | Sort-Object Priority | Select Name,Priority

Checking rules

Try to send an email to a domain that is blocked. The sender should receive an NDR with code 550 5.7.1_ETR and the email will not be delivered to the recipient.

Note that in Microsoft 365, transport rule evaluation may be overridden/supplemented by Microsoft Defender for Office 365 policies and Microsoft Purview compliance policies (depending on config priority and policy scope).

If you trace an email in the Exchange transport logs, you can see which transport rule was applied to the email:

Reason: [{LED=550 5.7.1 TRANSPORT.RULES.RejectMessage; the message was rejected by organization policy};

Transport rule: ‘Block outgoing email to Gmail’