Creating a Recipient Policy

Creating a Recipient Policy


You want to create a recipient policy to configure an additional email address or mailbox manager policy.


Using a graphical user interface
  1. Open the Exchange System Manager (ESM) snap-in.

  2. In the left pane, browse to the Recipients Recipient Policies container.

  3. Right-click on Recipient Policies and select New Recipient Policy.

  4. Select the property pages you a want on the recipient policy form and click OK.

  5. Enter the recipient policy name.

  6. Click on Filter Rules, click Modify, select the search criteria, click OK.

  7. Read the warning message that is displayed and click OK.

  8. Set the desired policies on the E-Mail Addresses (Policy) and Mailbox Manager Settings (Policy) tabs.

  9. When you are done, click OK.


Recipient policies are used for controlling how the RUS stamps mail-enabled objects. It is in charge of stamping objects with the correct email addresses as well as Mail-box Manager settings, such as automatically deleting and reporting on messages that exceed certain ages and sizes. Companies that have multiple divisions and want different email addresses for users in the different divisions use multiple recipient policies for configuring the email addresses. Each recipient policy has a filter that specifies the mailboxes it should configure with its rules.

Recipient policy is too involved to do simply from the command line or through VBScript. Several of the values in the Active Directory msExchRecipientPolicy class are binary types, which are not trivial to manipulate with LDIF or VBScript. If you wish to programmatically create recipient policies, you can do it, but you will need to use something a bit more involved such as Visual Basic or C++.

Managing recipient policies requires Exchange Full Administrator permissions. See the "Discussion" for Recipe 22.7.

One note of warning: do not test the manipulation of recipient policies in your production environment. Changes to recipient policies get stamped on many or possibly all mail-enabled objects in the directory, and you could unintentionally bring down entire sections of your mail delivery system. Due to its widespread effect, you could have great difficulty getting it all back up and running quickly. For example, one company that shall remain nameless went through a merger process and was trying to standardize some of their mail systems. Unfortunately, they unintentionally changed the primary email address of more than 100,000 employees with one small incorrect recipient policy change. Due to the type of mistake, this wasn't noticed internally. It took a couple of days for people outside of the company to notice and report the issue to the company before it got worked on and corrected. In the meanwhile, most email going into the company from the outside was not properly delivered.

See Also

Recipe 22.7, MS KB 249299 (How to Configure Recipient Policies in Exchange), MS KB 319201 (How to Use Recipient Policies to Control E-mail Addresses in Exchange 2000), MS KB 259381 (XADM: How to Create a Custom Recipient Policy Based on Routing Groups), MS KB 319188 (How to Use Recipient Policies to Control Mail-boxes in Exchange 2000 and Exchange 2003), MS KB 325921 (How to Configure E-mail Addresses Based on Domain Membership), and MS KB 328738 (XADM: How the Recipient Update Service Applies Recipient Policies)

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows