There’s an occasional question that I get asked: how do I
configure mail flow if I’m migrating from a non-Exchange messaging system or an
Exchange organisation in a different forest to an Exchange 2010 or 2013
messaging system and the two systems need to coexist but the problem is that
the email domain is the same and needs to be ‘spanned’ across the two messaging
systems? In this post, I’ll discuss how to tackle this.
Background
First a bit of background about accepted domains. By
default, when you install the first Exchange 2007 – 2013 server in your AD
forest, you’ll find that a default accepted domain is created and this is
usually your internal domain DNS name. I.e. if you installed Exchange in the US
sub domain of the contoso.local forest then the default accepted domain will be
us.contoso.local and new mailboxes will have SMTP addresses of alias@us.contoso.local.
If you run the cmdlet Get-AcceptedDomain,
you’ll see that this default accepted domain is an authoritative accepted domain. This means
that Exchange believes that all mailboxes that have email addresses for
us.contoso.local are hosted on one of the Exchange servers in the organization
and that there are no other mailboxes with these SMTP addresses on any other
mail server. This basically means that Exchange will receive emails for this
domain and deliver them to the relevant mailbox but that if it cannot find a
mailbox for a particular email address, it’ll provide a recipient not found
NDR.
Internal relay domains
Authoritative accepted domains don’t achieve what we want
but we can now look at the internal relay accepted domain. You configure an
internal relay accepted domain using New-AcceptedDomain
for a new domain or Set-AcceptedDomain
if you need to modify an existing accepted domain. An internal relay accepted
domain will receive email for the domain and attempt to deliver it to a mailbox
in the organisation however the difference is that if it cannot find a mailbox
with the right SMTP address, it’ll attempt to send the email to another SMTP
server.
In order to specify the SMTP server it’ll relay these emails
to, you should create a Send Connector that is configured with the accepted
domain as an address space and specify a smart host or set of smart hosts. This
is often important when firewalls are involved and you need to ensure that only
the required ports are only open to the required SMTP servers. It’s also good
practice to ensure you control and document the mail flow paths. With this
configuration, any emails sent to your internal relay accepted domain where the
mailboxes are not in your Exchange organization are relayed on to these smart
hosts. This way, Exchange can use the same address space or domains as other
non-Exchange mail systems and email can flow both ways, as long as the other
mail system is capable of this (of course).
Internal relay domains are also useful when doing a cross
forest Exchange migration where you have Exchange installed in both the source
and destination forests.
More information can be found here.