Send as one domain, receive on another (Exchange 2013)

I am trying to set up Exchange 2013 so that it will send as alias@domaina.com but it won't receive on that email address. I want it to receive on alias@domainb.com.

More specifically, in my environment I have 2 email servers.
1, we use for generic pop3 email access to our retail locations using a program called Smartermail (it is smarthost enabled)

2, We use exchange 2013 for our offices and remote staff.

domaina (our primary domain name) is running currently, and active on smartermail. We essentially use smartermail as the gateway. It has paid antivirus and has connections to our Barracuda spam and virus firewall.

Exchange is running and installed on exchange.domaina.com

Right now everything works, except for if I try and send email from an exchange.domaina.com email address to a domaina.com email address. Exchange thinks that domain is internal and instead it sends it to itself. In 2013, I can't figure out how to just create an SMTP email address policy without also allowing exchange to receive on that email address.

May 25th, 2015 11:38am

The issue here is that if both servers consider themselves authoritative for domaina.com then they'll never send messages to non-local aliases to the other server. The way around this is to make one of the other server not be authoritative.

On the non-authoritative server you configure a send connector (or whatever it's called in smartermail) encompassing domaina.com, which then uses the other server as a smart host for that email. In either case local mail (from one alias to another on the same box) will still work as before, but any mail that isn't known locally will be passed on rather than rejected. If it's the exchange server you do it on have a look at http://exchangeserverpro.com/configuring-outbound-mail-flow-in-exchange-server-2013/ which shows where the send connector options can be configured.

On the authoritative server you need to configure rules / dummy aliases to re-route mail for specific intended aliases to dummy alternate ones that are running on the other server. So for instance, server1 is authoritative for domaina.com, and server2 is authoritative for dummydomain.com. If info@domaina.com lives on server2 you configure that address to be the default, but you also configure info@dummydomain.com as an additional alias. On server1 you also create info@domaina.com, but in this case you configure it to forward to info@dummydomain.com (see https://technet.microsoft.com/en-GB/library/dd351134(v=exchg.150).aspx for forwardings). Now if someone on server1 wants to email info@ they can, it reaches the local account, and then Exchange forwards it to the dummy address externally to server2 where it's received as normal.

Which way round you do it really depends on which server has the least mailboxes / aliases, since for every individual alias on the non-authoritative server that you want users on the authoritative server to be able to email you'll need to configure a rule/forwarding for it.

Free Windows Admin Tool Kit Click here and download it now
May 25th, 2015 4:02pm

I got it worked out.
It is actually my testing that was the problem.

If anyone else runs in to this :::

I added the domain as an internal relay. Then I added a new SMTP address to the existing default Email Address Policy.
I set it as the Reply Address using the boolean.

The issue was when sending emails to my domaina, it would always just go to that account on the exchange server directly and never hit my domainb send connector. The reason was, that user WAS already set up as an exchange user.

I had assumed, that this meant I couldn't email anyone else on domainb... it was just my stupidity in testing after spending 100 hours setting up exchange in an old, semi corrupt AD environment.

I sent to an email address on domainb that wasn't also already set on exchange and everything is flowing and working perfectly.

Thanks

May 25th, 2015 5:13pm

Glad to hear you found what was causing the issue. Suspect we've all had cases like that where the fault turns out to be us! ;-)
Free Windows Admin Tool Kit Click here and download it now
May 25th, 2015 5:39pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics