Applies to: Exchange Server 2013
Topic Last Modified: 2013-02-10
Using Transport rules, you can look for specific conditions in messages that pass through your organization and take action on them. Transport rules let you apply messaging policies to email messages, secure messages, protect messaging systems, and prevent information leakage.
Many organizations today are required by law, regulatory requirements, or company policies to apply messaging policies that limit the interaction between recipients and senders, both inside and outside the organization. In addition to limiting interactions among individuals, departmental groups inside the organization, and entities outside the organization, some organizations are also subject to the following messaging policy requirements:
- Preventing inappropriate content from entering or leaving the
- Filtering confidential organization information
- Tracking or archiving copying messages that are sent to or
received from specific individuals
- Redirecting inbound and outbound messages for inspection before
- Applying disclaimers to messages as they pass through the
Looking for management tasks related to managing Transport rules? See Manage Transport Rules.
Overview of Transport rules
Transport rules are similar to the Inbox rules that are available in many email clients. The main difference between Transport rules and rules you would set up in a client application such as Outlook is that Transport rules take action on messages while they’re in transit as opposed to after the message is delivered. Transport rules also contain a richer set of conditions, exceptions, and actions, which provides you with the flexibility to create a customized rule.
The following list summarizes the basic workflow for Transport rules:
- You use the Exchange admin center (EAC) or the Shell to create
a Transport rule. After you create your rule, it’s stored in Active
- As messages go through the Transport pipeline, the Transport
rules agent is invoked. The Transport rules agent is a special
Transport agent that processes the Transport rules you create.
- The Transport rules agent scans the message, and if the message
fits the conditions you specify in a Transport rule, it takes the
specified action on that message.
The following sections provide detailed information about Transport rule components, the Transport rules agent, and how the Transport rules are applied.
Transport rule components
Transport rules consist of the following components:
- Conditions Use Transport rule
conditions to specify the characteristics of messages to which you
want to apply a Transport rule action. Conditions consist of one or
more predicates that specify the parts of a message that should be
examined. Some predicates examine message fields or headers, such
as the To, From, or Cc fields. Other predicates examine message
characteristics such as message subject, body, attachments, message
size, and message classification. Most predicates require that you
specify a comparison operator, such as equals, doesn't equal, or
contains, and a value to match.
- Exceptions Exceptions are based on the
same predicates used to build Transport rule conditions. However,
unlike conditions, exceptions identify messages to which Transport
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 the conditions and don't match any exceptions defined in
the Transport rule. Transport rules have 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 predicates, see Transport Rule Predicates. The list of predicates is also available in the Transport rule dialog in the EAC. If you use the Shell, you can retrieve the list of predicates by using the Get-TransportRulePredicate cmdlet.
For a complete list of Transport rule actions available, see Transport Rule Actions. The list of actions is also available in the Transport rule dialog box in the EAC. If you use the Shell, you can retrieve the list of actions by using the Get-TransportRuleAction cmdlet.
How Transport rules are applied
All Transport rules are processed by the Transport rules agent on Exchange servers. The Transport rules agent is a built-in agent that fires on the OnResolvedMessage transport event. All messages in an Exchange 2013 organization are processed by the Transport service.
Differences in processing based on message type
There are several types of messages that pass through an organization. Based on the message type, a message can be processed slightly different by the Transport rules agent.
- Messages sent by anonymous
senders Transport rules are applied to all
messages received from anonymous senders. Email received from the
Internet falls under this category.
- Messages sent between authenticated
users Transport rules are applied to the
following types of messages sent between authenticated users:
- Interpersonal messages Interpersonal
messages that contain a single rich text format (RTF), HTML, or
plain text message body or a multipart or alternative set of
- Encrypted email messages Messages that
are encrypted using S/MIME. Transport rules can access envelope
headers contained in encrypted messages and process messages based
on predicates that inspect them. Rules with predicates 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. With transport decryption
enabled, the Transport rules agent in the Transport service on a
Mailbox server can access the content of protected messages.
Messages must be published using an AD RMS cluster in the same
Active Directory forest as the Exchange 2013 server. If transport
decryption is disabled, the agent can't access message content and
treats the message as an encrypted message.
- 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.
- Read reports Reports that are generated
in response to read receipt requests by senders. Read reports have
a message class of
- Interpersonal messages Interpersonal messages that contain a single rich text format (RTF), HTML, or plain text message body or a multipart or alternative set of message bodies.
How the Transport rules agent evaluates messages
The Transport rules agent evaluates the following elements when processing rules for a message:
- Message scope The first check performed
by rules agents is whether a message falls within the scope of the
agent. Transport rules aren't applied to all types of messages.
- Priority For messages that fall within
the scope of the rules agent, the agent starts processing rules
based on rule priority in ascending order. The rule with a priority
of 0 is processed first, followed by the rule with a priority of 1
and so on. Transport rule priority values range from
nis the total number of Transport rules. Only enabled rules are processed. You can use the EAC or the Shell to change the rule priority.
- Rules with no conditions or
exceptions If a rule has no conditions and no
exceptions, it’s applied to all messages.
- Conditions All Transport rule
conditions are made up of predicates. The conditions describe the
type of message for which the rule is intended, and the rules agent
applies the rules to the messages that match the criteria specified
in the rule conditions.
- Rules with multiple predicate
conditions It may be necessary to use more
than one predicate condition to specify a rule. For a rule's action
to be applied to a message, it must match all the predicate
conditions selected in the rule. For example, if a rule uses the
predicate conditions The sender is a member of this group
and The subject includes any of these words, the message
must match both conditions. It must be sent by a member of the
specified distribution group, and the message subject must contain
the specified word.
- Predicate conditions with multiple
values Some predicate conditions allow you to
specify more than one value. If one predicate condition allows you
to enter multiple values, the message must match any value
specified for that predicatecondition. For example, if an email
message has the subject Stock price information, and the
The subject includes any of these words condition on a
Transport rule is configured to match the words Contoso and
stock, the condition is satisfied because the subject
contains at least one of the condition values.
- Exceptions A rule isn't applied to
messages that match any of the exceptions defined in the rule. This
is exactly opposite of how the rules agent treats predicate
conditions. For example, if the exceptions Except if the sender
is this person and Except if the subject or body includes
any of these words are selected, the message fails to match the
rule condition if the message is sent from any of the specified
senders, or if the message contains any of the specified words.
- Actions Messages that match the rules
conditions get all actions specified in the rule applied to them.
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. In Exchange 2013, you can also configure a rule so that when that rule is applied, the rules agent stops processing any subsequent rules. This property is configurable by using the EAC or the Shell.
Transport rules and group membership
When you define a Transport rule using a predicate 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 predicates based on distribution group membership, you must also consider the impact of Expanded Groups Cache.
Rule storage and replication
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.|
Rule replication and storage in mixed environments
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
predicates 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 predicates and actions
you plan to use are available. To see the list of available
predicates and actions for each deployment, see the following
Transport Rule Predicates in Office 365
Transport Rule Predicates in on-premises Exchange
Transport Rule Actions in Office 365
Transport Rule Actions in on-premises Exchange
When you coexist with Exchange 2010 or 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 2010 or Exchange 2007 EMC. For more information, see Upgrade from Exchange 2010 Transport and Upgrade from Exchange 2007 Transport.