Setting Up Postfix As A Backup MX

In this tutorial, I will show how you can set up a Postfix mail server as a backup mail exchanger for a domain so that it accepts mails for this domain in case the primary mail exchanger is down or unreachable and passes the mails on to the primary MX once that one is up again.

1 Preliminary Note

I want to set up a backup MX for the domain In this example, the primary MX for is called (IP address, so I call the backup MX (IP address

I have created MX records for that look like this:               86400   IN      MX      10               86400   IN      MX      20

It's important that the primary MX has a lower number (10) and therefore a higher priority than the backup MX (20).

I'm assuming that the Postfix on is already installed and working.

2 Configuring Postfix on

To make a backup MX for the domain, all we have to do is change/add three lines to /etc/postfix/

nano /etc/postfix/

First make sure that smtpd_recipient_restrictions contain permit_mynetworks and reject_unauth_destination, so something like this would be ok:

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Then we must add to the relay_domains parameter; if there's no relay_domains parameter yet in /etc/postfix/, the following will do:

relay_domains = $mydestination,

And finally we add an empty relay_recipient_maps parameter to /etc/postfix/

relay_recipient_maps =

(That way we don't have to specify a list of valid email addresses to back up, which might be a daunting task if you have to manage hundreds of email accounts.)

There's one important thing I have to add: You must not list in the following parameters in /etc/postfix/

  • mydestination
  • virtual_alias_domains
  • virtual_mailbox_domains

That's it already. All we have to do now is restart Postfix:

service postfix restart

3 Testing

To test the new backup MX, we take down the MTA (Postfix, Sendmail, Exim, etc.) on and send an email from some remote server to an account (e.g. [email protected]).

If you have access to the mail log on the remote (sending) server, you should now find something like this in it:

Jun 6 18:29:16 mail postfix/smtp[17746]: AF814144146: to=<[email protected]>,[], delay=1, status=sent (250 2.0.0 Ok: queued as DCA5A1BF40F)

As you see, the mail has been sent to instead of because is unreachable. Now, let's take a look at the mail log of

Jun 6 18:29:16 mx2 postfix/qmgr[3049]: DCA5A1BF40F: from=<[email protected]>, size=892, nrcpt=1 (queue active)
Jun 6 18:29:16 mx2 postfix/smtpd[3051]: disconnect from mail.blabla.tld[]
Jun 6 18:29:16 mx2 postfix/smtp[3057]: connect to[]: Connection refused (port 25)
Jun 6 18:29:16 mx2 postfix/smtp[3057]: DCA5A1BF40F: to=<[email protected]>, relay=none, delay=0.07, delays=0.03/0.02/0.01/0, dsn=4.4.1, status=deferred (connect to[]: Connection refused) has accepted the mail and tried to connect to to deliver it to the primary MX. Because the primary MX is down, cannot deliver the mail and keeps it in the mailqueue until is available again.

Now we start the MTA on again. The backup MX will not immediately deliver the queued mail, but after some minutes you should see something like this in the mail log of

Jun 6 18:56:44 mx2 postfix/qmgr[3080]: DCA5A1BF40F: from=<[email protected]>, size=892, nrcpt=1 (queue active)
Jun 6 18:56:45 mx2 postfix/smtp[3083]: DCA5A1BF40F: to=<[email protected]>,[]:25, delay=1648, delays=1648/0.09/0.4/0.12, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 167995B0109)

The mail has been delivered to the primary MX where you can see this in the mail log:

Jun 6 18:56:45 mx1 postfix/local[4963]: 167995B0109: to=<[email protected]>, orig_to=<[email protected]>, relay=local, delay=0.54, delays=0.08/0.02/0/0.43, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -f-)

So no mails were lost while was down, and users can continue to retrieve their mails from

Share this page:

Suggested articles

12 Comment(s)

Add comment



Reading this tutorial I have to agree, that setting up a basic backup MX is indeed pretty easy. But problems are not too far away:

If you compare the configuration you are showing here with a typical modern anti-spam configuration almost everything is missing. This is what spammers like to see and that is the reason they like to send mail to lower priority MX servers, as they are more often than not not so well configured.

In my case using the herein described backup config in conjunction with my current primary MX setup this would lead to the following worst-case scenario:

My main MX server goes down. While our current mail server rejects well over 90% of the incoming mails (up to 50.000 per day over the last days) the backup MX would not. If the backup does not break under the heavy load our primary MX will, once it gets back online and the backup send it thousands of thousands of mails and none of them will get rejected and each and every mail will be virus and spam scanned.

It wouldn't take long until your primary mail server will shut down due to heavy load.

So, if you indeed intend to set up a backup mx, make sure it runs the same config in terms of spam rejection as your primary server. Otherwise you will notice an almost instant rise in spam mails that come through (relayed by your backup MX).

By: wursti

The Spammer Trick with the lower prio MX is a thing that should be hard to work around, especially when ure recieving Mail for several Domains.
Armoring the Backup MX the same way like the Primary would mean syncing Spamfilter Data. In my case (ASSP) sure possible but a thing that should be installed for every aditional domain.
File Access / Cronjobs would be needed on the Primary System, there should be FTP/SSH etc for File Transfer in Backup System

Mine "simple dirty fix idea" would be now to let the backup only recieve in case the primary mail exchanger is down.
A little php/perl script [e.g. fsockopen()] could do this monitoring, writing postix conf /restarting for the case the primary dont respond as it should.

The advantage would be that the relay stays up.
So spammers would get a responding tcp 25 presented on the Backup MX Record, maybe theres a possibility to delay them (lame them in fact...)

Im running some M$ Exchange servers , they are mostly in Client Workplaces on  thin dynamic-addressed DSL lines. This Environments are screaming for a BackupMX, so it would be a rly nice to have...

however, im not registered here.
if someone got the tune to make such running, contact my bnc quakenet (plz / #dswp)

By: Anonymous

This HOWTO misses out key elements.

 Postfix offers recipient address validation, where it will make a call-out to the primary server to check if an address exists. It will cache information about these addresses, so that it will be able to sensibly queue only emails to addresses that exist when the primary is down. Although you might want to ensure that it receives some email in normal operation to prime the cache (such as being listed as the first server to try for the domain).

See Postfix docs

The first question anyone should ask is do I need a backup MX? In the example described above there is nothing to cause the backup to flush its queue when the primary becomes available. So it may be that when the primary comes back email on this server will take longer to deliver than if no backup MX server had existed. Especially if there is no address validation being performed.

I agree about the spam issue in the first comment, the backup MX needs at least as good, or better spam filtering.

By: Anonymous

Running a backup mx is not as easy as it seems.  There is a lot of variables that go into making sure you aren't getting junk mail, making sure the messages get back to the primary ok, etc..  For that reason I simply use backup mx through


Can anybody write a good description?It doesn't work and really old.Thanks!

By: Shiva


  I have configured a backup mail server postfix for mass mailing.

  we are experiencing a problem while sending the E-Mail from Backup MX mail server its delivering as Spam, but when we are sending from main mail server its delivering as normal(not as Spam) can any one please suggest me what steps to be taken or it will be fixed by changing my IP ?


Thanking in advance


By: Skorupa

You have to set SPF record of your domain from which you send mails. If you do some form of DKIM or Domain Key, than you have to copy signing key to your backup MX.

Check your backup MX IP in sites like for blacklists and check mails from MX on for more information what is wrong, and why your mail is labeled as SPAM.

By: Lyubo

Thank you for the sumarrized tutorial. 

I did configured my backup mx server with postfix following the steps.

When I turn off my primary postfix, secondary is receiving the mails. So far so good.

However,  turning the primary back on doesn't get mails back from the secondary. They just stay in the secondary without sending the mails back to primary. 

Any ideas ?




By: Lyubo

Can you please share how you have set your "virtual_transport" parameter in 




By: Lyubo

I finally got it working by setting "virtual_transport = smtp:example:"

Now, when I turn the primary postfix off, the mails stays in the mailq of the secondary:


 C32DA8C0076: to=<[email protected]>, relay=none, delay=76, delays=76/0.02/0/0, dsn=4.4.1, status=deferred (connect to[]:25: Connection refused)


When I turn the primary on, it receives the mails back from the secondary:


postfix/smtp[17966]: C83EB8C0067: to=<[email protected]>,[]:25, delay=211, delays=208/0/0.43/2.5, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 74EB2E0B35)


Thanks again!


By: Ben Thijssen

I can not find anything about secure communication protocols for a mail backup server. Does it receive and send messages in plain text?

By: inka

I see the virtual_transport comment, is this howto up to date? Best practice to rejecting Spamers?

Making sure if main server goes offline that incoming mail will be collected till main server is back online and then it will be delivered. Are DKIM and SPF needed in this case when den backup MX is not going to be sending email?