Today’s I’ve invited Greg Mulholland to talk about an MX record design that I found very helpful in maintaining an efficient mail deliver system that delivery doesn’t reach across the globe to send mail to local mailboxes. I hope you find this as interesting and I did:
==================================================
You know when you have those moments when you call into question why you do things the way you do? Well I had one of them the other day.
First, as a backgrounder, you should know that we have a number of offices around the world. I was dealing with a particular issue of routing outbound Internet email on our Exchange 2007 servers in Melbourne Australia and Melbourne Florida. I think the whole thing came about because I somehow noticed that our UK mail server had different Internet Connector smart host settings than the American, Australian, and Italian mail servers; some were using DNS and others were using some MX servers and not the others. So I started to ask questions as to whether this had been purposely done or if it was an adhoc (i.e., seems like a good idea at the time) approach.
I sat down to draw up an approach that I would be able to implement across the board. The problem that we faced was that for the sake of redundancy we wanted multiple smart hosts. However, since the MX servers were on different continents, we potentially were sending mail across the world to an MX server to deliver it back down the pipe and to a clients mail server in the original country. Not really ideal when you have a mail limit of 20mb and some offices have bandwidth limits.
So I was faced with a problem, how do I provide for guaranteed local MX delivery when everything is working normally, but still provide redundancy in the event of problems and this is what I came up with:
The normal method is to use specific host names as smart hosts, which can route mail in a load balanced way meaning if I sent 20 mails, 12 might send from the first smart host and 8 might send via the second. Certainly this is what occurred in testing and it was less than ideal as the secondary was all the way in Tampa and I am in Melbourne, AU. In this case I decided to set the smart host to a domain name instead of a hostname and see if exchange would perform a DNS lookup for the MX priority and deliver mail based on the MX priority.
Right now would be a good idea to explain the mx setup.
Our mx records look like this
domain.com MX preference = 10, mail exchanger = mx-mel.domain.com
domain.com MX preference = 20, mail exchanger = mx-tpa.domain.com
domain.com MX preference = 30, mail exchanger = mx-mlb.domain.com
So I still had the same problem. Although exchange would now obey my MX priority, that would mean that in AU it would work a treat, as we are the primary (mx-mel), however it causes an obviously problem in the US, Asia, Europe etc.
The simple solution was to create new zones on the DNS server for each region i.e. Au.domain.com, us.domian.com, uk.domian.com etc
In this way I could set different MX preferences for these zones like the example below
us.domain.com MX preference = 10, mail exchanger = mx-tpa.domain.com
us.domain.com MX preference = 15, mail exchanger = mx-mlb.domain.com
us.domain.com MX preference = 20, mail exchanger = mx-mel.domain.com
au.domain.com MX preference = 10, mail exchanger = mx-mel.domain.com
au.domain.com MX preference = 20, mail exchanger = mx-tpa.domain.com
au.domain.com MX preference = 30, mail exchanger = mx-mlb.domain.com
Now all I had to do was the change the smart host entry on the US mail servers to us.domain.com and the mail server in AU to au.domain.com and test.
I was able to verify that mail was delivered by the primary MX server (which was local if it set up the DNS zone correctly) and if the local server happened to be powered off then delivery would be handled by the secondary MX server.
This solution was developed out of a specific need. It may not be ideal for many setups however it seems to work in all our testing and we have not had any issues that we have encountered thus far.
Thanks
Greg Mulholland
==================================================
Great info Greg!
Thanks!
Tom
Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer
Prowess Consulting www.prowessconsulting.com
PROWESS CONSULTING | Microsoft Forefront Security Specialist
Email: [email protected]
MVP — Forefront Edge Security (ISA/TMG/IAG)