Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am managing a mail server, which will be temporarily closed for three or four days due to the data center maintenance. I want to find a solution to (completely or partly) solve the lost mails during this unavailable period. Because the data volume is huge, it is very hard to migrate it to other data center.

One approach I think out is to setup a temporary mail server in other data center, and when new mail received, the mail server automatically sends a return mail to tell the sender "We are temporarily closed for three or four days. Please send the mail later or contact in other means."

I am wondering is this approach possible with existed mail server ? Or something better available ? (free solution is preferred for it is only for temporary)

share|improve this question

migrated from Sep 17 '12 at 6:25

This question came from our site for professional and enthusiast programmers.

What email services (IMAP, SMTP) and which software (qmail, Postfix, Exchange) are you using? – jimp Sep 17 '12 at 4:17
Is this an inside exchange server or a real mail server?..being pointed to be a real MX record? – chris Sep 17 '12 at 4:18
This very much depends on your mail architecture. Generally speaking, for inbound mail, messages attempt to deliver to the recipients' domains' mail exchangers in order of priority. If the highest priority MX is offline, delivery is attempted to the next highest and so on. Once a mail is received by an MX under your control, you can do whatever you want with it. For outbound email, mail clients will need to be reconfigured or else they will complain to their users. – eggyal Sep 17 '12 at 4:19

Point a secondary MX record your temporary server. Here's a quick example:      1299    IN  MX  5      1299    IN  MX  10

When it comes time for maintenance, drop your primary server offline. Since anything sending mail to it should be non-interactive, nobody will really notice any timeout issues. When the mailserver fails to contact your primary, it will fallback to the next higher numbered server (the 5 / 10 just before the server name in this example).

That higher numbered server should be configured to act as a secondary mailserver as well. It doesn't have to deliver the mail to a mailbox, just hold it until it can reach the primary. Here's a configuration example for Postfix.

share|improve this answer
I would do it this way! Keep an eye on the delivery timeouts, so that the mails are really spooled. Or frozen until the real mailserver comes up back again. – Michuelnik Sep 17 '12 at 7:24

You could setup a clone of your current mail system (users and structure), make the new server the email config for the domains you serve, confirm delivery is working to the new server, and take the old MX down so it won't receive messages. At this point, your users will see their emails at the data center under maintenance "disappear," but they will see their current emails at least. Once the data center maintenance is done, you can bring the old MX back online and undo the temporary domain email config, and then use rsync to transfer the 3-4 days of emails from the temp server back to the users' "real" mailboxes.

FWIW, I think you will embarrass your email users if their senders get a bounce back like that. Only use that as a last resort.

share|improve this answer

What you are looking for is a "store and forward" service, of which there are many. Well before you take your systems down you edit the MX records to point to the store and forward system. While your system is up all mail will be delivered normally. When you'r system is down the other system will accept mail on your behalf and store them. When your system is up again the held mail will be delivered to your system.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.