Exchange Server 2007 Recipient Policies and Accepted Domains

The e-mail address recipient policy concept in Exchange 2003 is separated into two concepts in Exchange 2007: E-mail Address Policies (EAP) and Accepted Domains. This blog post covers the relationship of EAP and accepted domains in Exchange 2007 and how the functionality of e-mail address recipient policies in Exchange 2003 maps to EAP and Accepted Domains in Exchange 2007.

Relationship of EAP and Accepted Domains in Exchange 2007

EAP defines the e-mail proxy addresses that are stamped onto recipient objects. Accepted domains define the SMTP namespaces for which an Exchange organization routes e-mail. Any accepted domain added to the system can be linked to an EAP so that it will generate recipient e-mail addresses for this accepted domain. And every EAP must link to an existing accepted domain so that e-mails sent to e-mail addresses that are defined by the EAP can be routed by Exchange 2007 transport servers.

In Exchange 2007, authoritative and relay domains are managed together as accepted domains. In Exchange Management Console, the Accepted Domains tab of Hub Transport node under Organization Configuration work center is used to manage all accepted domains defined in the organization.

E-Mail Address Policy wizard provides the console GUI used to select an accepted domain for which a new e-mail address policy applies. Only accepted domains defined in the Exchange 2007 organization can be added to the list in the EAP.

PowerShell cmdlets can also be used to manage accepted domains and e-mail address policy.

E-Mail Address Recipient Policies in Exchange 2003

In Exchange 2003, there are two kinds of recipient policies: e-mail address recipient policies and mailbox manager recipient policies. Mailbox manager recipient policies are not the focus of this blog post and will not be discussed further. E-mail address recipient policies combined the concepts of EAP and accepted domains in Exchange 2007. Below is the ESM GUI to configure a domain to be stamped with recipient e-mail addresses. Notice that there is an option (highlighted with a red rectangle) to set this domain as an authoritative domain or not – the accepted-as-authoritative-domain equivalent in Exchange 2003.

There are three problems with this combined e-mail address recipient policy concept:

  1. If a domain is specified for an e-mail address recipient policy but not set as an authoritative domain, e-mails sent to recipients with e-mail addresses defined by the policy will not be routed within the Exchange organization for this domain. This is an invalid scenario, but the ESM GUI doesn’t block this.
  2. The authoritative domain concept is hidden under the e-mail address recipient policy GUI, which is not very discoverable.
  3. Relay domains are managed through Connector GUI; a completely different location than authoritative domain management, which increases managing complexity. Below is the snapshot of managing relay domains through Connectors ESM GUI.

For these reasons, the e-mail address recipient policy concept in Exchange 2003 is separated into EAP and Accepted Domains for better discoverability and management in Exchange 2007.

- Jared Zhang

Comments (9)
  1. KW says:

    In the most recent E2K7 release I have, the EAP can only be filtered based upon a limited set of parameters through the GUI (Company, Department, etc.).  Is this the plan long term or will this be extended?  In 2003 the LDAP method could be problematic if people were tempted to try and get too fancy without understanding the LDAP queries they used, but it also provided a way to apply a policy or policies based on group membership or OU structure.  This does not appear to be an option at this point.

  2. Jared (Ji-Chao) Zhang says:

    For E2K7 RTM, we support a set of attributes (Company, Department, State or Province and custom attributes) in the precanned filter for EAP/AL/DDG in GUI. This avoids OPATH syntax filter to make it easier to understand. PowerShell cmdline can be used to create custom OPATH filters for EAP/AL/DDG.  

  3. MartinW says:

    So, hypothetically speaking, if I had a domain that was only partially hosted in the exchange organisation, how would I forward emails out of it to another organisation.  I can do this in 2000 and 2003 by doing this:

    I’m a bit confused about the difference between the ‘Internal Relay Domain’ and ‘External Relay Domain’ options for accepted domain.  Would I select one of those options an set up a send connector to forward it out to the second organization?

  4. PeterL says:

    I have the same question as MartinW, is there an answer?

  5. Anonymous says:

    Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects….

  6. Anonymous says:

    I have previously listed the progress we’ve been making in posting ITPro focused Systems Management blog

  7. Johan says:


    Is there possible to enter a LDAP Query as i E2K3?

    I base my Recipeint Policys on memberOf…

    For example;



  8. Josh43 says:

    In reply to MartinW, since I found his question while searching for my own answer:

    I found the documentation here:

    That basically hints at the solution:


    Internal Relay Domain:

    To specify that recipients in this domain do not have mailboxes in this Exchange organization but do have contacts in the address book and that mail will be relayed for this domain through Hub Transport servers in this Exchange organization, select this option."

    Which states that email for this domain will go through the hub transport servers (standard send connectors); so, set the domain as an internal relay

    This is working flawlessly in the test config I have, though a hint: you need an external DNS server manually specified, and probably the external IP or FQDN specified as the reply to EHLO.

  9. Dave Baird says:

    I have an issue with multiple EAPs using Custom Attributes to stamp mailboxes with an appropriate SMTP address.  

    My environment needs to accept email for several domains, and a large number of users need more than one email address. I used Custom Attributes to specify strings for the users (i.e. dept1, dept2) but have found it only stamps the mailboxes with the highest one in the order. i.e. Policy 1 has the highest priority and uses Custom Attrib1, Policy 2 has priority 2 and uses Custom Attrib2.  If I enter both Custom Attribs only the SMTP address for Policy1 gets stamped on the mailbox.

    I have found through elimination that I need to apply the custom attributes in reverse order and let the lower priority/lower attrib number SMTP address be stamped before applying the next attribute, or I only get the highest priority policy address. This is very time consuming.

    For users with only one Custom Attrib, it works fine.

    Has anyone else seen anything similar?

Comments are closed.

Skip to main content