Actions: | Security

Navigation: Home | Services | Tools | Articles | Other

Postfix as a Secondary MX

Much as many people love to hate it, email is still a fundamental and important part of our communication toolset. As with all services, it is good practice to attempt to increase service reliability and availability.

If a Mail Transfer Agent(MTA) is unavailable for any reason, and of course, there are many possible reasons, messages for users of our domains should be received and queued for delivery once normal service is restored.

There are two primary steps:

  1. Create a new MX record in the DNS for your zone.
  2. Configure postfix on your secondary machine to accept messages for relaying to the domain.

The Postfix docs have information on backup MX servers.

Creating a new MX record

RFC 974 goes into great detail about MX records and how they should be used, but I have a short version. MX records specify hosts that are able to exchange mail messages for the domain, so I can add the following Resource Record(RR) to my DNS zone:

;domain                      hostname    IN MX 20
specifies the domain for which this MX record applies. ("For what domain do you want to accept messages?")
specifies that this is an MX record
specifies the prioritisation of this host as an MX (lower values have the highest priority)
specifies the hostname that will act as an MX. ("Which machine will be your secondary MX?")


There are various opinions about whether to deprioritise backup servers.

The thinking is that since they are backup servers, they should only be used in the event that the primary server is unavailable and so they should have a lower priority.

The traditional counterpoint is that this is the exact same behaviour if both primary and backup have the same MX priority and therefore you should not waste the processing capacity of the backup server by only using it when the primary is unavailable.

And I believe this is a valid point; however there are many circumstances when you specifically want to avoid using the secondary unless necessary. In one recent example, the secondary did not have access to the primary mailstore, so messages could not be finally delivered until the primary was available again anyway. Not an optimal situation, but we frequently have to create imperfect solutions. That's why I consider systems administration to be an engineering discipline -- it's full of compromise between competing constraints.

Configure Postfix to relay messages for the domain

All you need to accept messages for relaying to a particular domain is to add that domain to relay_domains in

relay_domains = $mydestination

Recipient Maps

Your backup MX should be performing all the same checks and techniques designed to prevent spam and the like that your primary server uses, otherwise the spammers will attempt to use it as an easy backdoor into your users' mailboxes.

You need to tell Postfix to only accept messages for valid recipients in domains for which you are relaying mail, using relay_recipient_maps:

relay_recipient_maps = hash:/etc/postfix/relay_recipients

The left side of the map contains the recipients' addresses, the right side must be non-empty:    OK    OK