Analytics Made Easy - StatCounter

Setup Postfix + Antispam as MX backup


In mail-server architecture, MX backup is a solution that should be always implemented for redundancy and to avoid emails being returned with errors due to mail-server unavailability.

The working concept is pretty easy: when the mail-server is offline (failure or maintenance), incoming emails are collected and stored in the MX backup and released once the primary mail-server is back online again.



DNS configuration

To work properly, system requires a second MX record in the DNS entry with a lower priority to properly deliver incoming email to MX backup while mail-server is offline.

Mail-server and MX backup public IPs have to be also set to reflect the designed architecture.



Required packages installation

In order to use yum command to install all required packages, we need to add the RPMforge repository to our system.

# wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm
# rpm -Uvh rpmforge-release-0.5.2-1.el6.rf.x86_64.rpm


In addition to Postfix, the installation process includes additional packages to protect the server from spamming: ClamAV, Spamassassin and Amavisd-new.

# yum install postfix spamassassin clamd clamav-db amavisd-new


Because in this system we want to use only Postfix, if other packages are installed (Sendmail for instance) we need to set the correct MTA through the command alternatives selecting the right option.

# alternatives --config mta


Because in this example only the package Postfix is installed, the number option to type is 1.

If Sendmail is installed in the system, remove it using the yum command.

# yum remove sendmail


ClamAV configuration

Edit the file /etc/clamd.conf and check that communication between Amavisd-new -> ClamAV is made through the local UNIX socket instead of TCP socket.

# vi /etc/clamd.conf


Enable ClamAV option removing the #.



Amavisd-new configuration

Edit configuiration file /etc/amavisd.conf and set the parameters with values that reflect your network environment.

# vi /etc/amavisd.conf



Postfix configuration

Edit the file /etc/postfix/master.cf and add the following lines:

# vi /etc/postfix/master.cf


Edit the file /etc/postfix/main.cf .

# vi /etc/postfix/main.cf

Add the following two lines:


Change the configuration parameters with values that fit with your network environment.


If the relay_recipient_maps parameter is left blank, all the emails are processed by the MX backup regardless if recipients exist or not in the mail-server with the risk of storing also “junk” emails. By creating the file /etc/postfix/relay_recipients with existing accounts, the problem is solved and only emails addresses to existing recipients are kept. Of course if you have a dynamic environment with thousand mailboxes, this approach is perhaps not the best option.

# vi /etc/postfix/ relay_recipients

Enable installed services to be processed during system startup.

# chkconfig postfix on
# chkconfig amavisd on
# chkconfig clamd on
# chkconfig spamassassin on


Start the services following the correct sequence.

# service spamd restart
# service clamd restart
# service amavisd restart
# service postfix restart


If a warning related to an outdated ClamAV database is shown, you can manually update the signature by using the command:

# /usr/bin/freshclam


Signature is then updated to latest available release.



System test

Once the configuration is completed, we need to test the system to verify its correct functionality checking if emails are properly processed.

Using the telnet command, we test first if Amavisd service is listening on

# telnet localhost 10024


Next to test Postfix smtpd service is listening on

# telnet localhost 10025


Using another computer, connect the MX backup via telnet. In yellow are shown the instructions to enter.

# telnet mail2.nolabnoparty.com 25


If the message is delivered to the recipient, then the system is working properly.


If the message is delivered to the recipient, then the system is working properly.


Check Postfix logs activity to verify whether MX backup is processing messages or not.

# tail -f /var/log/maillog


To check the MX backup emails queue, the command mailq shows the messages received so far.

# mailq


On regular basis the system perform a flush action of queued messages based on the value specified in the  /etc/postfix/master.cf file (default 1000 seconds).

# vi /etc/postfix/mastercf


If you don’t want to wait for next flush schedule, a manual flush can be performed using the command postqueue and checking with mailq the queue status.

# postqueue -f
# mailq


When messages are released from the MX backup, if everything works as expected, emails are delivered to the email client.


Instead of buying some cloud resources that could be quite expensive, in the market are available some providers that offer the MX backup service with interesting fees.

With this solution no emails will be lost in case of mail-server failure and scheduled maintenance can be performed taking all the necessary time.

mx backup 1