Mail flow rules (transport rules) in Exchange 2013


Applies to: Exchange Server 2013

You can use mail flow rules (also known as transport rules) to identify and take action on messages that flow through your Exchange 2013 organization. Mail flow rules are similar to the Inbox rules that are available in Outlook and Outlook Web App. The main difference is mail flow rules take action on messages while they're in transit, and not after the message is delivered to the mailbox. Mail flow rules 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 information about mail flow rules in Exchange Online, see Mail flow rules in Exchange Online. For information about mail flow rules in Exchange Online Protection, see Mail flow rules in Exchange Online Protection

You can use the Exchange admin center (EAC) or the Exchange Management Shell to manage mail flow rules. For instructions on how to manage transport 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.

To implement specific messaging policies by using mail flow rules, see these topics:

Mail flow rule components

A mail flow rule is made of conditions, exceptions, actions, and properties:

  • Conditions Identify the messages that you want to apply the actions to. Some conditions examine message header fields (for example, the To, From, or Cc fields). Other conditions examine message properties (for example, the message subject, body, attachments, message size, or message classification). Most conditions require you to specify a comparison operator (for example, 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 more information about mail flow rule conditions in Exchange 2013, see Mail flow rule conditions and exceptions (predicates) in Exchange 2013.

  • Exceptions Optionally identify the messages that the actions shouldn't apply to. The same message identifiers that are available in conditions are also available in exceptions. Exceptions override conditions and prevent the rule actions from being applied to a message, even if the message matches all of the configured conditions.

  • Actions Specify what to do to messages that match the conditions in the rule, 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 more information about mail flow rule actions in Exchange 2013, see Mail flow rule actions in Exchange 2013.

  • Properties Specify other rules settings that aren't conditions, exceptions or actions. For example, when the rule should be applied, whether to enforce or test the rule, and the time period when the rule is active.

    For more information, see the Mail flow rule properties section in this topic.

Multiple conditions, exceptions, and actions

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 that contain specific text, create one rule for each condition. In the EAC, you can easily copy a rule.

One condition with multiple values


Some conditions allow you to specify more than one value. The message must match any one (not all) of the specified values. 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 specified values.

Multiple exceptions


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

Multiple actions


Messages that match a rule's conditions get all the actions that are 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.

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 an action on a rule so that when that rule is applied, subsequent rules are not applied to the message.

Return to top

Mail flow rule properties

The following table describes the rule properties that are available in mail flow rules.

Property name in the EAC Parameter name in PowerShell Description



Indicates the order that the rules are applied to messages. The default priority is based on when the rule is created (older rules have a higher priority than newer rules, and higher priority rules are processed before lower priority rules).

You change the rule priority in the EAC by moving the rule up or down in the list of rules. In the PowerShell, you set the priority number (0 is the highest priority).

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.

For more information, see Set the priority of mail flow rules.



You can specify whether you want the rule to start processing messages immediately, or whether you want to test rules without affecting the delivery of the message (with or without Data Loss Prevention or DLP Policy Tips).

Policy Tips present a brief note in Outlook or Outlook on the web that provides information about possible policy violations to the person that's creating the message. For more information, see Policy Tips.

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

Activate this rule on the following date

Deactivate this rule on the following date



Specifies the date range when the rule is active.

On check box selected or not selected

New rules: Enabled parameter on the New-TransportRule cmdlet.

Existing rules: Use the Enable-TransportRule or Disable-TransportRule cmdlets.

The value is displayed in the State property of the rule.

You can create a disabled rule, and enable it when you're ready to test it. Or, you can disable a rule without deleting it to preserve the settings.

Defer the message if rule processing doesn't complete


You can specify how the message should be handled if the rule processing can't be completed. By default, the rule will be ignored, but you can choose to resubmit the message for processing.

Match sender address in message


If the rule uses conditions or exceptions that examine the sender's email address, you can look for the value in the message header, the message envelope, or both.

Stop processing more rules


This is an action for the rule, but it looks like a property in the EAC. You can choose to stop applying additional rules to a message after a rule processes a message.



You can enter descriptive comments about the rule.

Return to top

How mail flow rules are applied to messages


Differences in processing based on message type

There are several types of messages that pass through an organization. The following table shows which messages types can be processed by mail flow 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.


Office 365 Message Encryption    Messages encrypted by Office 365 Message Encryption in Office 365. For more information, see Office 365 Message Encryption.

Rules can always access envelope headers and process messages based on conditions that inspect those headers.

For a rule to inspect or modify the contents of an encrypted message, you need to verify that transport decryption is enabled (Mandatory or Optional; the default is Optional). For more information, see Enable or disable transport decryption.

You can also create a rule that automatically decrypts encrypted messages. For more information, see Define rules to encrypt or decrypt email messages.

S/MIME encrypted messages

Rules can only access envelope headers and process messages based on conditions that inspect those headers.

Rules with conditions that require inspection of the message's content, or actions that modify the message's content can't be processed.

RMS protected messages   Messages that had an Active Directory Rights Management Services (AD RMS) or Azure Rights Management (RMS) policy applied.

Rules can always access envelope headers and process messages based on conditions that inspect those headers.

For a rule to inspect or modify the contents of an RMS protected message, you need to verify that transport decryption is enabled (Mandatory or Optional; the default is Optional). For more information, see Enable or disable transport decryption.

Clear-signed messages   Messages that have been signed but not encrypted.


UM 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.


Anonymous messages   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.


Transport rules and group membership

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.

Rule storage and replication

Mail flow rules that you create and configure on Mailbox servers are stored in Active Directory, and they're read and applied by the Transport service on all Mailbox servers in the organization. When you create, modify, or remove a mail flow rule, the change is replicated between the domain controllers in your organization. This allows Exchange to provide a consistent set of mail flow rules across the organization.


  • Replication between domain controllers depends on factors that aren't controlled by Exchange (for example, the number of Active Directory sites, and the speed of network links). Therefore, you need to consider replication delays when you implement mail flow rules in your organization. For more information about Active Directory replication, see Introduction to Active Directory Replication and Topology Management Using Windows PowerShell.

  • Each Mailbox server caches expanded distribution groups to avoid repeated Active Directory queries to determine a group's membership. By default, entries in the expanded groups cache expire every four hours. Therefore, changes to the group's membership aren't detected by mail flow rules until the expanded groups cache is updated. To force an immediate update of the cache on a Mailbox server, restart the Microsoft Exchange Transport service. You need to restart the service on each Mailbox server where you want to forcibly update the cache.

Mail flow rules that you create and configure on Edge Transport servers are stored in the local instance of AD LDS on the server. No automated replication of mail flow rules occurs on Edge Transport servers. Rules on the Edge Transport server apply only to messages that flow through the local server. If you need to apply the same set of mail flow rules on multiple Edge Transport servers, you can clone the Edge Transport server configuration, or export and import the mail flow rules. For more information, see Edge Transport server cloned configuration and Import or export mail flow rule collections.

Whenever the Transport service on a Mailbox server or Edge Transport server detects a modified mail flow rule, an event is logged in the Application log in the Event Viewer (Event ID 4002 on Mailbox servers, and Event ID 16028 on Edge Transport servers).

Rule replication and storage in mixed environments

There are two mixed environment scenarios that are common in Exchange 2013:

  • Hybrid deployments where part of your organization resides in UNRESOLVED_TOKEN_VAL(Office365)

    In a hybrid environment, there's no replication of rules between your on-premises Exchange organization and UNRESOLVED_TOKEN_VAL(Office365). Therefore, when you create a rule in Exchange, you need to create a matching rule in UNRESOLVED_TOKEN_VAL(Office365). Rules you create in UNRESOLVED_TOKEN_VAL(Office365) are stored in the cloud, whereas the rules you create in your on-premises organization are stored locally in Active Directory. When you manage rules in a hybrid environment, you need to 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 that are available in UNRESOLVED_TOKEN_VAL(Office365) and Exchange Server, 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 that are available in UNRESOLVED_TOKEN_VAL(Office365), see the following topics:
    Mail flow rule conditions and exceptions (predicates) in Exchange Online
    Mail flow rule actions in Exchange Online

  • Coexistence with Exchange 2010 or Exchange 2007

    When you coexist with Exchange 2010 or Exchange 2007, all mail flow 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 mail flow rules are associated with the Exchange Server 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 in Exchange 2013 (Exchange Management Shell or the EAC), you need to make the same change in Exchange 2010 (Exchange Management Shell or the UNRESOLVED_TOKEN_VAL(exEMC)). Or, you can export the rules from Exchange 2013 and import them into Exchange 2010.

    Exchange 2010 can't process rules that have the Version or RuleVersion value 15.n.n.n. To be sure all your rules can be processed, only use rules that have the value 14.n.n.n.

For more information

Manage mail flow rules

Mail flow rule conditions and exceptions (predicates) in Exchange 2013

Mail flow rule actions in Exchange 2013

Transport agents