The Hidden Value of a Backup MX Host

Property value (photo by Sapfizz)A colleague of mine is not fond of backup <acronym title="Mail eXchange">MX</acronym> hosts. He (correctly) points out that all incoming mail should be transmitted through another mail server anyway, so the backup MX hosts only serves as an attack point for spammers.

For the most part I agree with him, and that's a good thing. After all, the fellow runs some fairly busy mail servers!

The original purpose of having multiple mail servers servicing a domain at different priorities was to ensure that mail intended for the domain actually made it there. In the days of cross-country 56k Frame Relay connections, this was a good idea.

Things have changed since then. Most mail servers are available most of the time, and it is very rare for a mail server to be offline long enough for the sending mail server to bounce the mail back to the user. A typical mail server configuration will warn the sender that the message has been undeliverable after 4 hours, and then bounce the mail back usually between 1 and 5 days. In my opinion, it's this 4 hour undeliverable message that makes a backup MX host so attractive.

I once worked on a project to expand the RAID array for an existing Microsoft Exchange Server. Unfortunately, expanding this array required the Exchange Server to be offline for about 8 hours. Without a backup MX host, this company's clients would have started receiving undeliverable warnings during this outage. Although this downtime was anticipated by the company, it would have looked very bad to clients that were not "in the loop".

By having a mail server under our control that could accept mail during the downtime, we were able to ensure that all mail sent to the domain was properly queued while simultaneously protecting the company's image.

My Bookshelf

Reading Now

Other Stuff