Email Namespace Sharing: How to quickly rebrand a new acquisition

As soon as a merger or acquisition deal closes, there is a great urgency to integrate the two companies on a single, unified Exchange environment. This allows everyone in the new company to appear in the same Global Address List (GAL) and enables all users to share calendars. More importantly, however, it brands everyone under the same email address. When a new acquisition keeps using their old email address for an extended period, it appears that they are still operating as a two separate companies.

However, a full cross-forest Exchange migration can be a large undertaking. It is often accompanied by a domain migration which requires significant time and resources. It’s often desirable to rebrand everyone’s new email address ahead of completing a full cross-forest migration.

The quickest and easiest method to achieve this namespace sharing is by architecting a non-authoritative mail loop between the two (or more) Exchange organizations. The diagram below represents two companies sharing the “” email address namespace:

Generic Namespace Sharing

The key aspect of this design is that both Exchange organizations are non-authoritative for the namespace. This way, when Company A receives an email for a user in Company B, it will try and find the user locally, fail, and then forward the mail (via a send connector) to Company B where it will be successfully delivered to the user.

The potential downside to this design is that if an email is sent to a user who does not exist (for example, if the sender makes a typo) the email will bounce back and forth between the two Exchange organizations as neither of them will be able to find the recipient. Luckily, Exchange 2007 and later is able to detect these mail loops and will eventually email the sender a non-delivery report.

The first step to implement this design is to connect the two organizations via a secure point-to-point connection. Internal emails will be sent cross-organization, so they must be securely encrypted. Once the two Exchange organizations have full network connectivity, the following powershell commands can run (these have been tested on Exchange 2010) to establish non-authoritative mail routing:

Commands to run on Company A assuming there there are two servers with Hub Transport roles (Amail1 and Amail2 with IP addresses and respectively):

New-SendConnector -Name " connector to Company B" -Usage Internal -AddressSpaces -SmartHosts, -SmartHostAuthMechanism ExternalAuthoritative -SourceTransportServers, -DNSRoutingEnabled $false –ProtocolLoggingLevel Verbose 


New-ReceiveConnector -Name " receive connector from Company B" -Server Amail1 -PermissionGroups ExchangeServers -RemoteIPRanges -AuthMechanism ExternalAuthoritative -Bindings -ProtocolLoggingLevel Verbose


New-ReceiveConnector -Name " receive connector from Company B" -Server Amail2 -PermissionGroups ExchangeServers -RemoteIPRanges -AuthMechanism ExternalAuthoritative -Bindings -ProtocolLoggingLevel Verbose


New-AcceptedDomain -Name "" -DomainName -DomainType InternalRelay

Commands to run on Company B assuming there there are two servers with Hub Transport roles (Bmail1 and Bmail2 with IP addresses and respectively):

New-SendConnector -Name " connector to Company A" -Usage Internal -AddressSpaces -SmartHosts, -SmartHostAuthMechanism ExternalAuthoritative -SourceTransportServers, -DNSRoutingEnabled $false –ProtocolLoggingLevel Verbose 


New-ReceiveConnector -Name " receive connector from Company A" -Server Bmail1 -PermissionGroups ExchangeServers -RemoteIPRanges -AuthMechanism ExternalAuthoritative -Bindings –ProtocolLoggingLevel Verbose


New-ReceiveConnector -Name " receive connector from Company A" -Server Bmail2 -PermissionGroups ExchangeServers -RemoteIPRanges -AuthMechanism ExternalAuthoritative -Bindings –ProtocolLoggingLevel Verbose


New-AcceptedDomain -Name "" -DomainName -DomainType InternalRelay

Running these four commands on each organization will create the necessary cross-forest send and receive connectors and add as an internal relay accepted domain. From here, you should point the MX record for at either organization (Company A in this example) and test cross-organizational mail flow.

It’s important to be aware of any directory-based edge blocking being performed by a message hygiene service such as Forefront Online Protection for Exchange (FOPE) or Cisco Ironport. This feature will block emails sent to users in Company B because they are not seen in the directory of Company A. The message hygiene service will have to be reconfigured to synchronize with both directories in order to allow all users to receive mail from external senders. It is recommended to continue using directory-based edge blocking, however, to prevent spam and give senders a quick non-delivery report if they try to email a non-existent user.

With cross-forest mailflow fully tested for the namespace, every user can be given a email address as their new primary address. This can be performed with Email Address Policy or powershell depending on the situation. They should keep their old email address as a secondary so that they will continue to receive email at that address.

One known issue is when users “reply all” to an email on their Activesync smartphone, the phone will include them in the “reply all” recipients and so they will send a copy of the email to themselves. This will not occur in Outlook or OWA, but this can be annoying for heavy phone users. The fix for iPhone users is to simply change the email address on the account to, but in my limited testing I found that Android phones needed to completely remove the Exchange account and re-add it with the address. This can be especially tricky because the autodiscover record for can only point to one Exchange organization. For the other organization, users will have to manually specify their server settings in conjunction with their email address.

This method is fast and simple, but does not enable a unified GAL and therefore does not support cross-forest calendar sharing. If those are strict requirements, a Galsync tool must be implemented between the two organizations to enable cross-organizational mail flow, synchronized GALs, and cross-forest availability.

1 Comment

  • Curtis April 19, 2014 6:07 pm

    Nice write up. This strategy was effective with our most recent engagement with West Monroe. I would also add the importance of legacy dn entries especially during the migration phase or if aquired company is going to use it’s former address for any time. Bringing the legacy dn over as an x500 address saves confusion for the users and helps to ensure mail flow. Because this was uncovered in a migration that West Monroe was a part of I was able to use it successfully in a subsequent migration and it saved our helpdesk calls from users.

Phone: 312-602-4000
222 W. Adams
Chicago, IL 60606
Show Buttons
Share On Facebook
Share On Twitter
Share on LinkedIn
Hide Buttons