Mail flow or transport rules


Applies to: Exchange Server 2013

Topic Last Modified: 2016-12-09

You can use Exchange mail flow rules, also known as transport rules, to look for specific conditions in messages that pass through your organization and take action on them. Mail flow rules are similar to the Inbox rules that are available in many email clients. The main difference between mail flow rules and rules you would set up in a client application such as Outlook is that mail flow rules take action on messages while they’re in transit as opposed to after the message is delivered. Mail flow rules also contain a richer set of conditions, exceptions, and actions, which provides you with the flexibility to implement many types of messaging policies.

This article explains the components of mail flow rules, and how they work.

For steps to create, copy, and manage mail flow rules, see Manage mail flow rules. For each rule, you have the option of enforcing it, testing it, or testing it and notifying the sender. To learn more about the testing options, see Test a mail flow rule and Policy Tips.

For steps to implement specific messaging policies, see:

You can use the Exchange admin center (EAC) or the Exchange Management Shell to create transport rules, also known as mail flow rules.

Each mail flow rule includes criteria (conditions and exceptions), actions, and properties:

  • Conditions Conditions specify the characteristics of messages to which you want to apply a mail flow rule or transport rule action. Some conditions examine message fields or headers, such as the To, From, or Cc fields. Other conditions examine message characteristics such as message subject, body, attachments, message size, and message classification. Most conditions require that you specify a comparison operator, such as equals, doesn't equal, or contains, and a value to match. If there are no conditions or exceptions, the rule is applied to all messages.

    For a complete list of mail flow rule conditions, see Transport rule conditions (predicates). The list of conditions is also available in the mail flow dialog box in the EAC. If you use the Exchange Management Shell, you can retrieve the list of conditions by using the Get-TransportRulePredicate cmdlet.

  • Exceptions Exceptions are based on the same characteristics used to build conditions. However, unlike conditions, exceptions identify messages to which mail flow rule actions shouldn't be applied. Exceptions override conditions and prevent actions from being applied to an email message, even if the message matches all configured conditions.

  • Actions Actions are applied to messages that match all the conditions and don't match any of the exceptions. There are many actions available, such as rejecting, deleting, or redirecting messages, adding additional recipients, adding prefixes in the message subject, or inserting disclaimers in the message body.

    For a complete list of transport rule actions available, see Transport rule actions. The list of actions is also available in the mail flow dialog box in the EAC. If you use the Shell, you can retrieve the list of actions by using the Get-TransportRuleAction cmdlet.

  • Properties Properties specify when and how the mail flow rule should be applied, including whether to enforce or test the rule and the time period when the rule applies.

The following table shows how multiple conditions, condition values, exceptions, and actions are handled in a rule.


Component Logic Comments

Multiple conditions


A message must match all the conditions in the rule. If you need to match one condition or another, use separate rules for each condition. For example, if you want to add the same disclaimer to messages with attachments and messages with content that matches a pattern, create one rule for each condition. You can easily copy a rule.

One condition with multiple values


Some conditions allow you to specify more than one value. If one condition allows you to enter multiple values, the message must match any of the values specified for that condition. For example, if an email message has the subject Stock price information, and the The subject includes any of these words condition is configured to match the words Contoso or stock, the condition is satisfied because the subject contains at least one of the condition values.

Multiple exceptions


If a message matches any of the exceptions, the actions are not processed. The message doesn’t have to match all the exceptions.

Multiple actions


Messages that match a rule’s conditions get all actions specified in the rule. For example, if the actions Prepend the subject of the message with and Add recipients to the Bcc box are selected, both actions are applied to the message. The message will get the specified string prefixed to the message subject, and the recipients specified will be added as Bcc recipients.

Keep in mind that some actions, such as the Delete the message without notifying anyone action, prevent subsequent rules from being applied to a message. Other actions such as Forward the message do not allow additional actions.

You can also set a property on a rule so that when that rule is applied, subsequent rules are not processed.

Return to top

Each mail flow rule, also known as transport rules, has the following properties:

  • The order in which the rules are processed. The rule with a priority of 0 is processed first, followed by the rule with a priority of 1 and so on. You can change the rule priority by adjusting the order of rules in the EAC or changing the priority of individual rules. For example, if you have one rule to reject messages that include a credit card number, and another one requiring approval, you’ll want the reject rule to happen first, and stop applying other rules.

  • The mode of the rule. This controls whether to enforce or test the rule:

    • Do all the actions (Enforce)

    • Don’t do actions that impact mail delivery, and notify the sender (Test with Policy Tips)

      You can notify the sender that they might be violating one of the rules—even before they send an offending message. You can accomplish this by configuring Policy Tips and setting the mode of the rule. Policy Tips are similar to MailTips, and can be configured to present a brief note in the Microsoft Outlook 2013 or Outlook Web App client that provides information about possible policy violations to a person creating a message. For more information, see Policy Tips.

    • Don’t do actions that impact mail delivery (Test without Policy Tips). This options is typically used for testing a newly created rule.

    For more information about the modes, see Test a mail flow rule.

  • Time period. You can specify the date and time to start and stop the rule.

  • Whether or not the rule is enabled. You might want to disable a rule until you are ready to test it.

  • Category for the rule reports. You can specify whether to include the rule in the rule reports, and how it should be categorized in the reports.

  • What to do if rule processing fails. You can specify whether to skip the rule if rule processing fails.

  • How to evaluate the sender address. You can specify whether any conditions related to the sender address match the value in the message header, message envelope, or both.

Return to top

All messages in your organization are evaluated against the enabled mail flow rules for your organization. Rules are processed in the order listed on the Rules page in EAC, or based on the value of the Priority parameter in the Exchange Management Shell.

Each rule also offers the option of stopping processing more rules when the rule is matched.

Return to top

There are several types of messages that pass through an organization. The following table shows which messages types can be processed by transport rules.


Type of message Can a rule be applied?

Regular messages

Messages that contain a single rich text format (RTF), HTML, or plain text message body or a multipart or alternative set of message bodies.


Encrypted messages (Office 365 Message Encryption)

Messages that are encrypted using Office 365 Message Encryption.

Rules can always access envelope headers contained in encrypted messages and process messages based on conditions that inspect headers.

For a rule to inspect or modify Office 365 message encrypted content, your organization must:

  • Use Exchange Server or Exchange Online.

  • Have transport decryption set to Mandatory or Optional. Transport decryption is set to Optional by default.

  • Have the encryption key.

You can also create a rule that automatically decrypts encrypted messages.

Encrypted messages (S/MIME)

Messages that are encrypted using S/MIME.

Rules can access only envelope headers contained in S/MIME encrypted messages and process messages based on conditions that inspect headers. Rules with conditions that require inspection of message content, or actions that modify content, can't be processed.

Protected messages

Messages that are protected by applying an Active Directory Rights Management Services (AD RMS) rights policy template.

Rules can always access envelope headers contained in protected messages and process messages based on conditions that inspect headers.

For a rule to inspect or modify protected message content, your organization must:

  • Use Exchange Server or Exchange Online.

  • Have transport decryption set to Mandatory or Optional. Transport decryption is set to Optional by default.

  • Have the encryption key.

Clear-signed messages

Messages that have been signed but not encrypted.


Unified messaging email messages

Messages that are created or processed by the Unified Messaging service, such as voice mail, fax, missed call notifications, and messages created or forwarded by using Microsoft Outlook Voice Access.




Messages sent by anonymous senders.


Read reports

Reports that are generated in response to read receipt requests by senders. Read reports have a message class of IPM.Note*.MdnRead or IPM.Note*.MdnNotRead.


When you define a transport rule using a condition that expands membership of a distribution group, the resulting list of recipients is cached by the Transport service on the Mailbox server that applies the rule. This is known as the Expanded Groups Cache and is also used by the Journaling agent for evaluating group membership for journal rules. By default, the Expanded Groups Cache stores group membership for four hours. Recipients returned by the recipient filter of a dynamic distribution group are also stored. The Expanded Groups Cache makes repeated round-trips to Active Directory and the resulting network traffic from resolving group memberships unnecessary.

In Exchange 2013, this interval and other parameters related to the Expanded Groups Cache are configurable. You can lower the cache expiration interval, or disable caching altogether, to ensure group memberships are refreshed more frequently. You must plan for the corresponding increase in load on your Active Directory domain controllers for distribution group expansion queries. You can also clear the cache on a Mailbox server by restarting the Microsoft Exchange Transport service on that server. You must do this on each Mailbox server where you want to clear the cache. When creating, testing, and troubleshooting transport rules that use conditions based on distribution group membership, you must also consider the impact of Expanded Groups Cache.

Return to top

The Transport rules you create are stored in Active Directory and are available after Active Directory replication on all Exchange servers in your Exchange 2013 organization. This allows you to apply a consistent set of rules across the entire Exchange organization.

When a transport rule is created or an existing transport rule is modified or deleted, the change is replicated to all Active Directory domain controllers in the organization. All the Exchange servers in the organization then read the new configuration from the Active Directory servers and apply the new or modified transport rules.

Replication of transport rules across an organization depends on Active Directory replication. Replication time between Active Directory domain controllers varies depending on the number of sites in the organization, slow links, and other factors outside the control of Exchange. When you configure transport rules in your organization, make sure that you consider replication delays. For more information about Active Directory replication, see Active Directory Replication Technologies.
The Transport service on each Mailbox server maintains a recipient cache that's used to look up recipient and distribution list information. The recipient cache reduces the number of requests that each Mailbox server must make to an Active Directory domain controller. The recipient cache updates every four hours. You can't modify the recipient cache update interval. Therefore, changes to transport rule recipients, such as the addition or removal of distribution list members, may not be applied to transport rules until the recipient cache is updated. To force an immediate update of the recipient cache, you must stop and start the Microsoft Exchange Transport service. You must do this for each Mailbox server where you want to forcibly update the recipient cache.
Each time the Transport service on the Mailbox server retrieves a new transport rule configuration, an event is logged in the Security log in Event Viewer.

Return to top

There are two mixed environment scenarios that are common: hybrid deployments where part of your organization resides on Office 365, and Exchange 2013 coexisting with Exchange 2010 or Exchange 2007.

In the hybrid scenario, there is no replication of rules between your on-premises deployment and Office 365. Therefore, when you create a rule in your on-premises Exchange organization, you need to create a matching rule in Office 365. The rules you create in Office 365 are stored in the cloud, along with the rest of your Office 365 organization configuration, whereas the rules you create in your on-premises Exchange organization are stored locally in Active Directory. When managing rules in a hybrid scenario, you need to make sure that you keep the two sets of rules synchronized by making the change in both places, or making the change in one environment and then exporting the rules and importing them in the other environment.

Even though there is a substantial overlap between the conditions and actions available in Office 365 and on-premises Exchange, there are differences. If you plan on creating the same rule in both locations, make sure that all conditions and actions you plan to use are available. To see the list of available conditions and actions for each deployment, see the following topics:
Mail flow rule conditions (predicates) in Office 365
Transport rule conditions (predicates) in on-premises Exchange
Mail flow rule actions in Office 365
Transport rule actions in on-premises Exchange

When you coexist with Exchange 2007, all transport rules are stored in Active Directory and replicated across your organization regardless of the Exchange Server version you used to create the rules. However, all transport rules are associated with the Exchange server version that was used to create them and are stored in a version-specific container in Active Directory. When you first deploy Exchange 2013 in your organization, any existing rules are imported to Exchange 2013 as part of the setup process. However, any changes afterwards would need to be made with both versions. For example, if you change an existing rule using the Exchange 2013 EAC, you need to make the same change using the Exchange 2007 EMC.

Return to top

  • If you use both Exchange Server 2010 and Exchange Server 2013, note that Exchange Server 2010 can't process rules that are listed as version 15. To be sure all your rules can be processed, use just the version 14 rules.