In some situations it is necessary to share an email domain between two distinct email systems. This is referred to as Shared SMTP Namespace and is common when:
- Two companies merge but maintain separate systems for a period of time
- Non-Exchange systems are involved in the email environment, eg a Unix Sendmail server
Because Exchange Server handles this so easily it is generally best to send email to that domain name to the Exchange server first, and then let Exchange determine which recipients are local and which need to be sent on to another host.

First take a look at the domain name that you want to share. It is likely configured as an Authoritative domain in your Accepted Domains list.
[PS] C:\>Get-AcceptedDomain | fl domainname, *type* DomainName : mycompany.local DomainType : Authoritative
To share the namespace we simply change the DomainType to Internal Relay.
[PS] C:\>Set-AcceptedDomain mycompany.local -DomainType InternalRelay
Now that the domain type has been changed we need a Send Connector to tell Exchange where to send the emails that do not have a local recipient.
[PS] C:\>New-SendConnector -Name "Internal Relay" -Custom -AddressSpaces mycompany.local -SmartHosts 10.8.0.25 -SourceTransportServers ex2007.mycompany.local
Identity AddressSpaces Enabled
-------- ------------- -------
Internal Relay {smtp:mycompany.local;1} True
In that example the IP address of the other email system is 10.8.0.25, and the Hub Transport server to use to send the emails is ex2007.mycompany.local.
Now when an email arrives on the Exchange server that has no matching local recipient address, it will forward it on to the other mail system for delivery.
Update: In the comments below and via email some readers have described situations in which this does not work as simply as I outline above. The most common scenario reported to me is that it doesn’t work without setting up Contacts in each organization for the users in the other organization. Without those Contacts emails to recipients in the other organization result in an NDR.
This can happen when recipient filtering is occuring on the Exchange servers, or on a server running a third party anti-spam product, that rejects email that is addressed to invalid recipients. This check is usually performed with an LDAP lookup against Active Directory. However in a shared SMTP namespace scenario like this, any given Active Directory does not contain all of the valid recipients for all of the organizations sharing the namespace.
So to avoid NDRs when using shared SMTP namespace you will need to either disable recipient filtering, configure the product to do LDAP queries against all directories that share the namespace, or create Contacts.

Quick question: When changing the DomainType from “Authoritative” to “InternalRelay” this will not impede mail flow in anyway will it?
I’ve never had a problem with it, but as with all changes I suggest you schedule it for a low impact time of day and have a test/rollback plan ready just in case.
Don’t you have to have contacts in the local Exchange forest for it to forward to the target environment? I’ve heard of people doing this, it failing, and needing to create contacts that will handle the e-mail addresses that come in that will then have the forwarding address that will then use the Send Connector. And I’ve heard that you also need an e-mail address policy as well otherwise the Accepted Domain will be useless. Do you know whether these are true?
iamme, I’ve never had a problem like you describe, it has always worked fine for me as shown in the article. I’ve never had to resort to using Contacts to handle the email forwarding.
You might be thinking of using Contacts so that user in the other domain show up in the GAL. There are other ways of syncing the GAL between orgs that don’t require you to create Contacts.
And yes, for any local recipient to receive email to a given domain you will either need an Email Address Policy to assign them addresses, or manually assign them.
However, it is the Accepted Domain that controls whether or not the Exchange org accepts mail for the domain and what it does with it, not the EAP. So the lack of an EAP doesn’t necessarily make the Accepted Domain “useless”.
It really is very simple to set up shared SMTP namespace between to orgs like this so I’m not sure why you’ve heard so many bad stories.
I’m trying to do the exact same thing as we have 2 orgs and want mail for domainB to route via domainA and mailboxes are spilt between the 2 domains i.e. some in domainA and some in domainB. So we’ve got an accepted domain for domainB as internal relay and a corresponding connector set to relay mail to domainb via it’s smarthost. It works if we have a contact object in domainA only if not we get an unknown address 550 NDR.
Some posts I read say we don’t need contacts (like yours) and some say we need that or at least gal sync in between the 2 orgs. What gives? Even MS says you don’t need it:
http://technet.microsoft.com/en-us/library/bb676395%28EXCHG.80%29.aspx
But it won’t work unless you do.
I’ve just updated the post to explain why NDRs occur in some situations when SMTP namespace sharing is implemented. The common cause seems to be due to recipient filtering.