Supporting Two SMTP Mail Domains and Sharing an SMTP Mail Domain with Another System

Special situations (mergers and acquisitions, in particular) necessitate the support of two namespaces and the sharing of a namespace with another system. To help explain such a situation, consider the merger of two fictitious companies: Contoso, Ltd. and Fourth Coffee. Contoso (contoso.com) acquires Fourth Coffee (fourthcoffee.com). The process of consolidating domain namespaces is as follows:

1. Contoso configures its Exchange organization to accept mail for the non-local domain of fourthcoffee.com. For more information about accepting mail for multiple domains, see "Supporting Two SMTP Mail Domains" later in this topic.

2. Both systems eventually share the SMTP mail domain contoso.com.

3. Finally, the users are migrated to a single Exchange organization, and the old organization or system is removed.

Supporting Two SMTP Mail Domains

Supporting two SMTP mail domains is common during the initial phase of a merger or acquisition. As an example of how one Exchange organization can support two SMTP mail domains, consider the same merger scenario involving Contoso and Fourth Coffee. In the initial phases of the acquisition, Contoso continues to use its local SMTP mail domain of contoso.com. However, to allow Fourth Coffee employees to receive e-mail messages with their original address, Contoso must also accept mail for the non-local mail domain of fourthcoffee.com. The following figure illustrates how both the domains of fourthcoffee.com and contoso.com are supported.

Supporting two SMTP mail domains

To accept mail for the non-local domain of the newly acquired company, Fourth Coffee, an administrator at Contoso creates an SMTP connector to fourthcoffee.com. This connector is configured with an address space of the SMTP domain that is used by Fourth Coffee (fourthcoffee.com) and configured to relay messages to this domain. To do this, the administrator opens the SMTP connector's properties, clicks the Address space tab, and then selects the Allow messages to be relayed to this domain check box.

Additionally, for the mail domain (fourthcoffee.com) that the administrator wants to accept mail, he ensures that an MX record exists on the Internet DNS server. This MX record should point to the IP address of the gateway server that accepts inbound mail. For more information about DNS, see "DNS" in Transport Dependencies for Exchange Server 2003.

Using Address Rewrite as an Interim Solution

With Exchange 2003, you can use a new tool called Address Rewrite as an interim step in a merger or acquisition scenario. This tool rewrites e-mail addresses on outgoing messages that are sent to Exchange and destined to external or Internet addresses. (Address Rewrite is similar to the Exchange 5.5 feature, ReRouteViaStore.) In a merger or acquisition, you can rewrite all outgoing Internet mail with a single SMTP mail domain of the parent and continue to support both the SMTP domains of the parent company and the acquired company until you are ready to migrate all users to your Exchange system.

Using the example of the acquisition of Fourth Coffee by Contoso, assume that as an interim solution in this acquisition, you want all users of Fourth Coffee to begin using the SMTP mail domain of contoso.com. Because these users have not yet been migrated to your Exchange system, you can use Address Rewrite to rewrite all outgoing e-mail messages that are sent from users on the Fourth Coffee system with the e-mail address of contoso.com. However, you also want to continue to accept e-mail messages that are sent to the users with the old e-mail address of fourthcoffee.com.

To rewrite outgoing addresses and continue to support both SMTP domains, perform the following steps:

1. Use Address Rewrite to rewrite all outgoing e-mail addresses that are sent from Fourth Coffee users.

2. Create contacts in Active Directory for all users on the Fourth Coffee mail system with a target address of fourthcoffee.com and a primary SMTP address of contoso.com.

3. Create an SMTP connector with an address space of fourthcoffee.com.

Step 1:  Use Address Rewrite to Rewrite E-mail Addresses

After you configure the mail system that is used by Fourth Coffee Company to route outgoing Internet mail using SMTP through your Exchange server, you then need to enable Address Rewrite on the SMTP virtual servers in your Exchange organization that are responsible for accepting mail from the subsidiary company's mail system. In this example, you enable address rewrite on all SMTP virtual servers that accept mail from the subsidiary company, Fourth Coffee.

The following conditions must exist for Address Rewrite to work properly:

• The message is externally submitted SMTP mail that is sent to the Exchange bridgehead server.

• E-mail messages are destined to the Internet.

Internal mail or mail sent from other Exchange servers in your organization to the bridgehead server where address rewrite is enabled bypass address rewrite. There is one exception; mail submitted using Outlook Express or any other SMTP client undergoes an address rewrite on this bridgehead server.

Remember that the intent of this tool is to rewrite addresses only for mail coming from the subsidiary company (externally SMTP submitted) into your company's e-mail servers and then destined to the Internet.

You can download the Address Rewrite tool (exarcfg) from the Microsoft website at https://go.microsoft.com/fwlink/?LinkId=25097. After you download the tool, use the following procedure to enable address rewrite on the appropriate SMTP virtual servers.

For detailed instructions, see How to Enable Address Rewrite by Using the Exarcfg Tool.

Step 2:  Create Contacts in Active Directory for Fourth Coffee Users

In Active Directory Users and Computers, you must create a contact for each user on the Fourth Coffee company mail system. Each contact must have a target address of fourthcoffee.com and a primary SMTP address of contoso.com.

The target address appears on the Exchange General tab of a contact's properties. You set the primary SMTP address on the E-mail Address tab of a contact's properties. You can use an automated process to add these contacts to Active Directory, or you can perform the steps manually.

The How to Create a Contact in Active Directory procedure shows how to create a contact in Active Directory manually by using the target address of the non-Microsoft mail system, which is Fourth Coffee in this example, and a primary SMTP address that is used by your Exchange organization, which is Contoso in this example.

Step 3:  Create an SMTP Connector with an Address Space of fourthcoffee.com

To accept mail for Fourth Coffee Company users, an administrator at Contoso creates an SMTP connector to fourthcoffee.com and specifies each SMTP virtual server that accepts incoming Internet mail as a local bridgehead server for the connector. This connector is configured with an address space of the SMTP domain that is used by Fourth Coffee (fourthcoffee.com) and is configured to relay messages to this domain. To do this, the administrator opens the SMTP connector's properties, clicks the Address space tab, and then selects the Allow messages to be relayed to this domain check box.

The following figure illustrates the topology that is used by Contoso and Fourth Coffee. Note that one Exchange server accepts outgoing mail from Fourth Coffee, and a separate server routes incoming mail to Fourth Coffee users. The SMTP virtual server that accepts mail from Fourth Coffee can also function as an outbound gateway server, but this is not a requirement. This SMTP virtual server can either route Internet mail that is received from Fourth Coffee users directly to the Internet, or it can route this mail to the appropriate gateway server

Topology with address rewrite enabled

Sharing an SMTP Mail Domain with Another System

Sharing an SMTP mail domain between an Exchange 2003 organization and another e-mail system or another Exchange 2003 organization is common during the final stages of a merger or acquisition. To continue with the previous scenario, assume that Contoso is in the final stages of consolidating its systems with those of the newly acquired company, Fourth Coffee. Mailboxes in both the Exchange 2003 organization (which contains all of the employees of Contoso) and the other system (which contains all of the employees of Fourth Coffee) now use the same SMTP domain of contoso.com in their addresses. Ideally, the best way to share an SMTP mail domain is to allow Exchange to accept incoming mail from the Internet, locate a matching recipient in the Exchange organization, and then forward the mail to the users on the other mail system. The following figure illustrates a shared domain with another system.

Sharing an SMTP domain

If Exchange functions as the first mail server, there are two methods you can use to configure Exchange to share an SMTP address space.

• Method 1:  Sharing Selected Namespaces

  In Method 1, the mail systems share only selected SMTP address spaces—Exchange remains authoritative over the others. This is the preferred method because it is the most flexible. Also, you must use this method or use the Address Rewrite tool described previously if any of the following conditions exist in your environment:

  • You create contacts in Active Directory for sending mail to external recipients.

  • The target SMTP addresses of those external recipients matches any of the SMTP domains that are configured in Exchange 2003 recipient policies. For example, if the address @contoso.com is configured on one of your recipient policies, and you want to create contacts with a target address of @contoso.com, you must use this method to share the @contoso.com SMTP mail domain.

• Method 2:  Share All Address Spaces

  Although Method 2 is less flexible, it is easier to configure in small environments. However, you cannot use this method if contacts exist in Active Directory for the external recipients on the other mail system. For more information about using contacts in a shared SMTP domain, see Microsoft Knowledge Base article 319759, "XADM: How to Configure Exchange 2000 Server to Forward Messages to a Foreign Messaging System That Shares the Same SMTP Domain Name Space."

Method 1:  Sharing Selected Namespaces

Method 1 offers excellent flexibility because you can create contacts in Active Directory and more easily migrate users to a single system. This method uses two basic principles:

• **An SMTP connector is created with an address space of the remote domain, fourthcoffee.com.   **The connector allows messages to be relayed to this domain. Allowing relay to the remote domain permits Exchange to accept inbound messages for this domain.

• **Exchange is nonauthoritative over the domain.   **If Exchange is authoritative over a domain, it assumes that all the addresses in the domain exist in its organization. Therefore, if messages cannot be resolved locally, Exchange never attempts to send the messages through an external connector. By configuring Exchange to be nonauthoritative for the domain, if the user cannot be found locally, Exchange routes the message through the connector to the remote system.

  Note

  In this case, because this SMTP mail domain is nonauthoritative, it is irrelevant that Exchange accepts messages that are inbound for domains that it is authoritative over. The connector configuration ensures that the Exchange organization accepts mail for this domain—this is because the connector is configured with an SMTP address space of the remote domain and allows relaying to this domain. Exchange accepts only inbound e-mail for the shared SMTP domain because the connector to the remote e-mail system allows messages to be relayed to this address space. Because Exchange is nonauthoritative for the shared mail domain, if you remove the connector, Exchange stops accepting inbound mail for this SMTP domain. Therefore, if you remove the connector, remember to change the recipient policy and make Exchange authoritative for this SMTP mail domain.

There are three main steps to using Method 1 (each step is detailed further in the sections following):

1. Determine if Exchange is authoritative over the SMTP mail domain you want to share.

2. Configure the recipient policy for the SMTP mail domain that you want to share. How you do this depends on whether the SMTP mail domain exists on the default recipient policy, on another recipient policy, or if it does not yet exist on a recipient policy.

3. Create an SMTP connector to route mail to the other mail system or host.

Step 1:  Determine if Exchange is Authoritative Over the SMTP Mail Domain You Want to Share

Before you configure your recipient policy for the SMTP mail domain that you want to share, you must determine if Exchange is authoritative over the domain.

Remember, depending on whether Exchange 2003 is authoritative or nonauthoritative, Exchange handles e-mail messages differently for particular SMTP addresses. Because Exchange does not forward messages that it cannot resolve locally for an authoritative domain, you must ensure that Exchange is not authoritative over the SMTP mail domain you want to share.

For detailed instructions, see How to View the Setting that Determines Whether Exchange Server is Authoritative.

Step 2:  Configure the Recipient Policy for the SMTP Mail Domain You Want to Share

When configuring the recipient policy for the SMTP mail domain that you want to share, there are three possible scenarios you may encounter:

• Scenario 1   The SMTP mail domain that you want to share exists on the default recipient policy.

• Scenario 2   The SMTP mail domain that you want to share exists on another recipient policy.

• Scenario 3   The SMTP mail domain that you want to share does not exist on a recipient policy.

Scenario 1: Configuring a Shared SMTP Domain that Exists on the Default Recipient Policy

You cannot set Exchange to be nonauthoritative over the default recipient policy's primary SMTP address space. To prevent Exchange from being authoritative over this domain, you need to change the default recipient policy by adding a new primary address space that is strictly for internal use. This address could be similar to @localhost, signifying that it is used solely for internal mail flow within your Exchange organization. After you add the new address space, you must make the shared address space nonauthoritative.

To configure Exchange to share a mail domain that exists as the primary address space on the default recipient policy, you must perform the following tasks:

1. On the default recipient policy, add a new primary address space over which Exchange is authoritative, and then make the shared address space nonauthoritative.

2. Create a second recipient policy that has the same search filter as the default recipient policy. Then, assign the second recipient policy a higher priority than the default recipient policy so the reply-to or return address is displayed as the shared address space.

   This step is necessary because Exchange uses the primary address space as the reply-to address that is displayed in outgoing mail. Because you want outgoing messages to display the shared namespace on the reply-to line, you must create another recipient policy that is also nonauthoritative but has a higher priority; therefore, Exchange uses this address space on the return address of outgoing mail. Because the new recipient policy is not the default recipient policy, you can make this address space nonauthoritative.

Perform the How to Modify the Default Recipient Policy procedure to create a new primary address space on the default recipient policy and make the shared address space nonauthoritative.

Changing the default recipient policy in this way causes Exchange to use the new primary address as the return or reply-to address in outgoing e-mail messages. In the example above, all users in this policy now have a return e-mail address that matches the new primary address space of @localhost. Because you want all your users to have the return address of the shared mail domain (in this case, contoso.com), you must create a new recipient policy with a higher priority recipient policy that contains the contoso.com address space. Exchange uses the higher priority recipient policy on the return address. Furthermore, because this recipient policy is not the default recipient policy, you can make it nonauthoritative. (Remember, this address space must be nonauthoritative for Exchange to route it through the connector to the external system.)

Perform the How to Create a Higher Priority Recipient with the Shared Mail Domain procedure to create a higher priority recipient policy so that outgoing e-mail messages display the correct return (reply-to) address.

Scenario 2:  The SMTP Domain You Want to Share Exists on Another Recipient Policy

If the SMTP domain that you want to share is not on the default recipient policy, you can make the address space nonauthoritative.

For detailed instructions, see How to Modify an Existing Recipient Policy for the SMTP Domain that You Want to Share.

Scenario 3: The SMTP Domain You Want to Share Does Not Exist on a Recipient Policy

If the SMTP domain that you want to share does not exist on a recipient policy, you can create a new recipient policy with the address space and make it nonauthoritative.

For detailed instructions, see How to Create a New Recipient Policy for an SMTP Mail Domain that Does Not Exist on a Recipient Policy.

Step 3:  Create an SMTP Connector to Route Mail to the Other Mail System

Now that Exchange 2003 is nonauthoritative for the shared SMTP domain, when Exchange 2003 cannot find a matching address in Active Directory, it attempts to locate an external path to this domain. To find this path, Exchange first searches for a connector and then checks Domain Name System (DNS). Unless the mail exchanger (MX) record for that domain already points to the server on which the other mail system resides (in many cases the MX record points to the Exchange 2003 server itself), you must create an SMTP connector to route the mail to a specific host.

For detailed instructions, see How to Create an SMTP Connector to Route Mail to a Specific Host.

After you configure these settings, when Exchange 2003 cannot locate a local address match in that SMTP domain, Exchange forwards the mail to the host that has the matching address space, as specified on the SMTP connector.

Method 2:  Sharing All Address Spaces

This method involves sharing all address spaces or SMTP mail domains. Although this configuration is easier to implement, it is much less flexible than Method 1. In this configuration, Exchange 2003 is authoritative for all address spaces. You cannot have any contacts in your directory that have a target address matching a domain over which Exchange 2003 is authoritative.

For detailed instructions, see How to Share All Address Spaces in Your Exchange Organization.

Remember, this setting affects only authoritative domains. Therefore, in an authoritative domain, any message sent to an unresolved address is forwarded to the server that is specified on the SMTP virtual server. Any nonauthoritative domain in Exchange 2003 is not affected by this setting. Any message that is sent to an unresolved address in a nonauthoritative domain is routed to a matching SMTP connector, if present. If no matching SMTP connector is located, the message is sent to the server that is specified in the MX record found in DNS.

Supporting Additional Mail Systems

As described in the preceding scenarios, the other mail system that receives mail forwarded by Exchange may perform the same tasks as Exchange and forward mail to a third e-mail system. To avoid mail looping, it is essential that the last e-mail system (to which mail is forwarded) is authoritative for the domain. In other words, the final receiving mail system must search for a matching recipient; if the system does not find a matching recipient, it generates a non-delivery report (NDR) for the message. Mail looping occurs when the receiving system searches for a match in its recipients and then forwards the mail back to the original system when a match is not found.

If Exchange is the last system in this configuration, by default, it will return an NDR for any unresolved messages. However, it is preferable to create custom recipients in Active Directory for all recipients that reside on a different mail system. These recipients should have target addresses similar to @subdomain.contoso.com, where subdomain provides additional address information to distinguish the address space from the typical @example.com namespace; for example, @sales.contoso.com.