Sembee Blog of Exchange MVP Simon Butler

The Problem with Backup MX Services and an Alternative

2. February 2007 21:30 by Simon Butler in MS Exchange Server

As email becomes more critical to a company the issue of what happens with email if the server or internet connection fails is often raised.
One solution that is frequently mentioned is backup MX services. This is where a server located elsewhere is listed in your MX records with a higher MX value. The theory being that in the event of your server being available, the backup server will collect your email and then pass it on once the server has returned.
However a backup MX service will cause you grief outside of the times when it becomes useful, which basically makes the disadvantages outweigh the advantages considerably.
If you are having significant outages where a backup service becomes important to your business then you need to review the overall service of the primary server. A backup MX service should be something that is never used - or used once or twice a year at most.

What is the problem with Backup MX Services?

The number one problem with backup MX services is the fact that most spam goes to the higher MX records. Spammers have worked out that most higher MX records will not have the same level of spam protection and there is a higher chance of their message getting delivered.
As the most effective anti spam methods block the spam at the point of delivery, if you have the messages going through another server then you cannot use any of those methods. The only methods of dealing with spam is the traditional detection methods - which struggle with image based spam.
Furthermore dropping email delivered to non-existent users is almost impossible. Depending on the backup MX service that you use, they may insist on your server accepting all email, then dealing with it once it has been delivered. As most spam is spoofed, that means finding some way of dropping the messages once it has been delivered.

Do you need a backup solution at all?

SMTP email delivery has some robustness built in. Most email servers will attempt to deliver email for 48 hours, so as long as you can get something else in place in that time window you are fine. I work on the theory that if you cannot get an alternative solution in place in 48 hours then you have bigger problems to worry about.

Alternative Server Solutions

The way that I prefer to work is to put something in place in the event of something happening. I can have an alternative email service in place in less than 30 minutes. Obviously that is only setup if the outage is confirmed as being many hours or even days. If it is simply a power failure then I don't tend to bother.
However the biggest hurdle with dealing with alternative server solutions that are put in place after the event is DNS replication.
To get round the DNS issue, I use a dynamic DNS service.
I have my own domain registered with one of the dynamic DNS service providers. Each client has a host in my domain with that service and that host is pointing to their existing mail server's IP address. You could use one of the dynamic DNS provider's domains if you don't have a spare domain to use.
The host appears in their MX records.
Thus:
mail.domain.com cost: 10
client.mydomain.net cost: 20
mail.domain.com type: A IP Address: 123.123.123.123
client.mydomain.net type: A IP Address: 123.123.123.123
Note that both IP addresses are the same at this time.
In the event of a failure, I simply switch the dynamic DNS IP address to the address of the alternative server. That IP address change is live in less than 20 minutes, usually within two or three minutes, as the dynamic DNS services are configured for frequent changes to the IP addresses and make them accessible across the internet very quickly.
As the host is already in the DNS for the client's domain, I don't have to wait for any DNS changes to propagate.
When the primary server is available, the dynamic DNS host is switched back.

Alternative Server Software

For an alternative server, pretty much anything that supports SMTP can be used.
IIS makes a very good queueing only server. Someone with some asp skills could easily knock up a front-end that allows the messages in the queue to be viewed with a standard web browser. Access would need to be very restricted as it would show all messages in the queues.
You could even sign up with a host and create accounts in their email package. As long as the host has a decent web based front end for the email the end users can work with their email. When service is resumed, export the email to PST files and import it in to the mailbox.
If you are going to use a host, try and find one that supports IMAP connections. Then restrict the users to web based access and configure the server to store a copy of the sent items. That will ensure that you can download and import sent and received items in to Exchange when the server is available.

The Key is Forward Planning

As with many system failure procedures, the key is forward planning. By getting the DNS changes made in advance, you can reduce the downtime for email considerably, resulting in less downtime for your end users.  While it may not be a perfect solution, it will give you access to the email allowing phone calls to be made and business to operate - if not at optimum levels.

Comments are closed