Configuring Postfix to act as a backup MX server

If you’re running your own mailserver for receiving e-mail, you probably want some kind of redundancy when it goes down so you don’t lose any mail. The solution to this is to configure several backup mail exchanger (or MX) servers. Postfix is a popular replacement for the classic *NIX sendmail program that, along with being a primary mail exchanger, can be configured to act as a secondary, backup MX.

Changes to Postfix’s

Postfix first needs to be allowed to work as a MX backup server, which can be done in addition to being a primary mail server for some other domain. This is done through configuring smtpd_recipient_restrictions in Postfix’s configuration file (usually located in /etc/postfix/). Add permit_mx_backup to the list of restrictions. For example:

smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination permit_mx_backup

Next, the domains to act as a backup. These are added to the relay_domains option. For example:

relay_domains = $mydestination

Now that postfix knows to accept mail destined for these domains, it needs to know what to do with it. Postfix’s transport maps feature can be used to specify to send mail back to the main mailserver. In, add a transport_maps configuration option, pointing to a database supported by Postfix (such as hashes), like so:

transport_maps = hash:/etc/postfix/transport

Postfix will then look to this file for any information on delivering the e-mail from domains specified in this file.

Setting up Postfix transports file

Assuming you are using Postfix’s hash database format, create a new file transport (in /etc/postfix/ if following the example above). This file is a space-separated list of domains and how to deliver mail for them. For example:

This tells Postfix to send mail destined for,, and via SMTP to,, and respectively.

After adding the above, a binary database that Postfix will actually use needs to be created. This can be made by running;

postmap transport

in the directory the file transport resides.

After doing all this, you’ll now have a backup MX server for your main mail server. If your main mail server goes down, mail will then get sent to this backup MX server and queued up for eventually delivery back to your main mail server when it comes back online.

Dealing with ISP Port 25 Blocking

Many ISPs these days have resorted to port blocking to curb “undesirable usage” (like running web servers, or spamming). A variant of this to prevent the sending of spam involves blocking connections on port 25 (the port for SMTP) to any server that isn’t the ISP’s SMTP server.

If you’re running a mail server behind and ISP that does this, you probably already know about relayhost which will relay all your e-mail through your ISP’s mail server rather than trying to connect to other mail servers directly.

However, for a server wanting to act as a backup MX, this will not work. Mail will be recieved, but since the backup MX cannot connect to the main MX servers specified in the transports file, mail will get stuck in the backup MXs queue indefinitely.

The easy solution to this is to open up another port on the main mail server, such as 2525. The backup MXs transport file could be changed to deliver mail on this port:

On the main mailserver, the smtp component of Postfix is going to have to be run on both port 25 and 2525 (complicated), or, if using Linux or some other OS with fairly lets… INCOMPLETE

Other considerations

Queue Lifetime

If your primary mail server ever is down for a long time (longer than 5 days), you may need some additional tweaking on your backup mail exchangers. By default, Postfix will expire anything sitting in it’s queue for longer than 5 days. These messages will get bounced back. So much for being a “backup.” You can avert this behavior by adding to

maximal_queue_lifetime = 60d

Messages will now stay in the queue for 60 days. If your primary mail server is down for longer than this, you probably have other problems. Notice that affects ALL messages in the queue, not just ones stored for being a backup mail exchanger, so it may have other consequences.


Like this article? Please support my writing! Flattr my blog (see my thoughts on Flattr), tip me via PayPal, or send me an item from my Amazon wish list.


Antonio Bonifati's picture

Glood explanation, thanks. Only a minor note: permit_mx_backup is not needed when domains are listed in relay_domains. permit_mx_backup can be vulnerable to mis-use when access is not restricted with permit_mx_backup_networks.