Friday, 18 September 2015

Exchange Internal relay accepted domain

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.


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.

No comments:

Post a comment