MX Backup - Postfix Email Server

Powered by Drupal
Submitted by Sam Hobbs on

By far the most popular set of articles I have written is my Raspberry Pi Email Server tutorial. Clearly, there are plenty of people who don't like relying on freemail providers like Yahoo, Outlook and Gmail for a variety of privacy and security reasons. However, there is one major drawback of hosting your own email server: if your server is taken offline for maintenance, or your internet connection is interrupted, then incoming email can not be delivered and may bounce. This tutorial will describe how to set up another server to act as an MX backup. The backup server will be hosted on a separate internet connection with a different WAN IP address, and have a lower priority than your primary mail server in your Mail Exchanger (MX) DNS record. When your primary server is offline other MTAs will send email to the backup instead, and the backup will hold them until your primary mail server comes back online, and then deliver them. No more bounced emails. The biggest challenge when setting up a backup MX is convincing a friend or family member to allow you to run a RasPi or some other server on their network; the rest of the setup is a breeze compared to the full mail server installation described in the main tutorial, because fewer components are required (just Postfix). This guide is written for Debian and its derivatives (Raspbian, Ubuntu etc.) but since a basic postfix installation is more or less the same across different distributions you should be able to use it for any distro. My backup server runs openSUSE.


Postfix is the MTA. It is responsible for accepting incoming mail from other servers on the internet, sending mail to other servers on the internet, and delivering mail to your local mailbox. For an MX backup, it's pretty much all you need.


First, install Postfix. For Debian derivatives:

sudo apt-get update
sudo apt-get install postfix

Or for openSUSE:

sudo zypper refresh
sudo zypper in postfix

You may see a configuration wizard asking you what kind of setup you require. Choose "internet site", and when asked for a domain name, enter where "" is a domain you own. If you don't see this, don't worry - all the options can be changed in /etc/postfix/ later.


The majority of the Postfix configuration can be found in two files: /etc/postfix/ and /etc/postfix/ The file defines all of the different processes, and the is a place to put other parameters. You shouldn't have to edit, since it already defines the processes we need.


The first thing to do is open and make sure your hostname is correct. You should see:

myhostname =

This hostname is used by postfix when it connects to other servers on the internet, in the HELO command. If it isn't correct, edit it. The myorigin parameter should be set to the same domain name:

myorigin = $myhostname

myorigin is used as the domain part for locally posted mail (for example, if the fail2ban process sends an email from this host, the FROM email address will show The next parameter to check is mydestination - this is a list of domains that the server is the final destination for. Your root domain should not appear in this list, or Postfix won't forward any mail to your primary mail server! However, you might find it handy to be able to send email to this host sometimes, so should be in the list. Here's what it should look like:

mydestination =, hostname.lan, localhost.lan, localhost

The middle two items in the list will be filled in based on the domain name of the local network (e.g. .local or .lan for most routers, or .home for BT home hubs) and the hostname of the server (e.g. raspberrypi).

Allow relaying for your domain

Finally, we need to add your root domain to the list of domains that this server will relay email for.

relay_domains =

For the avoidance of doubt, you should leave relayhost blank, e.g:


This parameter is sometimes used to define a host that is used to forward all mail sent from the system (excluding local mail). For example, some people might have to set their ISP's email server as the relayhost for their primary server if the ISP blocks outgoing mail on port 25, or if they have a dynamic IP address and outgoing mail often ends up in spam folders because of poor IP reputation. You shouldn't need this for a backup MX - if port 25 is blocked you can just configure postfix to deliver to your primary server using a different port (e.g. 465), since the backup server will only ever have to send outgoing mail to your primary server. I don't think it would even be possible to set up a backup MX server that uses a relayhost, because the backup server would see delivery to the relayhost as successfully forwarding the email, regardless of whether the primary mail server is up or not.

Tell Postfix your WAN IP

If your server is behind a firewall and not connected directly to the internet, then it does not know its own WAN IP address. When your primary mailserver is offline, postfix will receive email for and do an MX lookup to figure out where to send it. To prevent it from trying to send the email to itself, you need to specify the WAN IP address of the firewall:

proxy_interfaces =

If your backup MX is on a dynamic IP address, then you can use a hostname instead of an IP address:

proxy_interfaces =

If you miss this step, you'll see messages like this in your log file:

Dec 27 20:40:55 NUC postfix/smtp[7904]: CEAB4335: to=,[]:25, delay=0.37, delays=0.1/0.06/0.21/0, dsn=4.4.6, status=deferred (mail for loops back to myself)

Use Maildir format for locally delivered mail

The final change to make is just personal preference. The following parameter will store mail delivered locally in Maildir format in the user's home folder (by default, postfix stores mailboxes in /var/mail):

home_mailbox = Maildir/

The following command will create the Maildir structure in your home directory, and set private file permissions so that only you can read the messages. Do this for any system users on the backup server that you expect to receive email:

mkdir -p ~/Maildir/{cur,new,tmp}
chmod 700 Maildir

Spam Control

Spam control is especially important for MX backups, because spammers will often deliberately connect to hosts with lower priorities in the MX record in the hope that they have more relaxed configurations.

Restriction lists

One method of controlling spam is the use of restriction lists. If you did the raspberry pi email server tutorial, you will be familiar with these. You can leave most of them at their default (empty) values, e.g:

smtpd_client_restrictions = 
smtpd_sender_restrictions = 

However, you can still cut down on spam by requiring clients to use a valid HELO hostname when they connect. The following parameters require the client to HELO before it can start sending messages, and check that the hostname is a fully qualified domain name for a real domain that has a DNS A or MX record.

smtpd_helo_required = yes

smtpd_helo_restrictions =

Since version 2.10, postfix has had a separate list for relay restrictions to reduce the risk of accidentally creating a permissive restriction list ( previously, relay and spam blocking policies were combined under smtpd_recipient_restrictions). If the empty recipient restrictions list looks strange to you, it's probably because the rules have been moved to the relay restrictions:

smtpd_recipient_restrictions = 

smtpd_relay_restrictions =

Helo restrictions on the primary server

If you used my raspberry pi email server tutorial to set up your primary server, you probably have something like this in your helo restrictions:

smtpd_helo_required = yes

smtpd_helo_restrictions =
        check_helo_access hash:/etc/postfix/helo_access

And in /etc/postfix/helo_access:          REJECT          Get lost - you're lying about who you are

The problem with this is that by default will match subdomains like too, because of this line in the default postfix configuration:

parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps

You can change this behaviour so that parent domains will only match subdomains if they are preceeded with a period ( by explicitly setting this parameter to empty in on the primary server, or by removing smtpd_access_maps from the list. I chose to clear the list completely:

parent_domain_matches_subdomains =

Require valid users

As things stand, any email submitted to your backup server addressed to a domain in relay_domains will be accepted, and the backup server will attempt to deliver it to the primary server. This is open to abuse by bots that send email to many addresses at once that may not exist ( causing the mail queue on the backup MX to fill up, and resources to be wasted on both your backup and primary mail servers as repeated connection attempts are made. The solution to the problem is to provide the backup with a list of valid users on the main server, so that it can reject email to addresses that don't exist. This parameter specifies the file to use:

relay_recipient_maps = hash:/etc/postfix/relay_recipients

You can then create the file:

sudo nano /etc/postfix/relay_recipients

... and populate it like this with any addresses you want to enable forwarding for: OK OK OK OK

Then use the postmap command to create a database out of the file:

sudo postmap /etc/postfix/relay_recipients

...which will create /etc/postfix/relay_recipients.db. If you make further changes to the file, you must postmap it again. Now Postfix will only relay mail for those addresses, and reject email for users that do not exist on the primary server.

Spamassassin on the MX backup

In the current configuration, the main server has to process every incoming message using spamassassin, which is quite a CPU intensive activity. If your MX backup is a lower powered machine, this may be what you want, but it may also be advantageous to filter emails before relaying them from the backup server, to take some load off your primary server. It should be possible to process the email with spamassassin, and drop it if the spam score exceeds a threshold. I haven't figured out how to set this up yet, but I'm planning on adding instructions in the future.


This section is about enabling transport encryption, for both incoming messages and outgoing messages to your primary email server. These two parameters require TLS for outgoing messages, and write information about encryption to the mail log (or journal, if you're using systemd):

smtp_tls_security_level = encrypt
smtp_tls_loglevel = 1

These two parameters enable TLS for incoming messages and write similar log messages:

smtpd_use_tls = yes
smtpd_tls_loglevel = 1

With this configuration TLS is not required for incoming messages, just enabled. Outgoing mesages must be sent with TLS. You must also make sure that these four parameters point to valid certificates & key files:

smtp_tls_cert_file = /etc/ssl/certs/
smtp_tls_key_file = /etc/ssl/private/
smtpd_tls_cert_file = /etc/ssl/certs/
smtpd_tls_key_file = /etc/ssl/private/

If you don't have a certificate, check out my CAcert tutorial for a free certificate, and optionally use my tutorial explaining the additional steps to set up a commercial certificate if you pay to get one signed by a different certificate authority.

DNS records for

An MX record is a list of one or more hosts able to receive email for a domain, where each item in the list has a priority. MTAs are supposed to fetch the list, and work down until they find a host that they can connect to, starting with the host with the highest priority (lowest number). This means that if you add to the MX record for with a lower priority than your primary mail server, other mail servers will use it when your primary mail server is offline. Your backup server will also need a DNS A record to map to its WAN IP address. If you want the backup to be the final destination for email addressed to as well as relaying mail to, you should create an MX record for too. Here's my setup (with namecheap): MX-backup-DNS.png The dig command can be used to retrieve DNS records, e.g. to fetch an MX record:

sam@NUC:~$ dig MX

; <<>> DiG 9.9.6-P1 <<>> MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37440
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

; EDNS: version: 0, flags:; udp: 4000
;                        IN      MX

;; ANSWER SECTION:         600     IN      MX      20         600     IN      MX      10

;; ADDITIONAL SECTION:         600     IN      A  64      IN      A

;; Query time: 18 msec
;; WHEN: Sat Jan 23 23:55:47 GMT 2016
;; MSG SIZE  rcvd: 114

For more information about DNS records, see my DNS tutorial. If you need to set up dynamic DNS for your backup server, you can use my ddclient tutorial to set it up without relying on the router of whoever has kindly let you host your backup server on their network.

Choice of Nameservers

It's important that your two email servers get their DNS information from the same place, or email could be accepted by your MX backup and rejected by the primary server, clogging up the mail queue on the backup and wasting the resources on both machines. I discovered this myself when I checked the queue on the backup to find about 5 spam emails that had got past the HELO checks on the backup, only to be rejected by the same HELO restrictions on the main server because the domain did not exist. How is this possible? Well, there's a certain amount of lag in the DNS system due to the time it takes for new records to propagate through from the root servers to whichever server you are querying. As for why a domain would exist on one server and not on another, spammers sometimes register new domains to send spam, which could then be removed shortly afterwards. When I had the problem, my main server was using openDNS and my backup was using BT's DNS servers. The solution is to change the DNS servers used by either the entirety of both networks (by changing setting in the router admin panel), or by changing it in your server configuration. Here are the IP addresses for two popular choices: openDNS:

Google public DNS:

If you want to change the DNS settings for the server only, and you configured a static IP address in /etc/network/interfaces you can specify nameservers with the dns-nameservers parameter like this:

auto eth0
iface eth0 inet static
        dns-nameservers localhost

If you're on openSUSE, you can change your nameservers in YaST (Network Devices -> Network Settings -> Hostname/DNS - > Name Servers and Domain Search List)

Port forwarding

The only port forward necessary for the backup MX to function is port 25. Remember to make sure your server has a static LAN IP address on your host's network. You may also want to forward port 22 for SSH so you can log in remotely. Remember to disable password logins in favour of publickey authentication to protect your friend's network.


Before starting the tests, restart Postfix to make sure all changes have taken effect:

sudo service postfix restart

Or with systemd:

sudo systemctl postfix restart

You may also have to tell postfix to start automatically when the system boots:

sudo systemctl enable postfix

Now log in to your primary mail server, and run this command to watch the mail logs in real time:

tail -f /var/log/mail.log

Or for systems with binary logging:

sudo journalctl -f -u postfix

Also open a second window, log in to your backup server, and run the same command. This will allow you to follow an email through its whole journey.

Test relaying by sending an email to the backup server

The telnet session is the same as the tests we used in the full email server tutorial:

telnet 25
Connected to
Escape character is '^]'.
220 ESMTP Postfix (Debian/GNU)
250 DSN
mail from:        
250 2.1.0 Ok
rcpt to:
250 2.1.5 Ok
354 End data with .
Subject: email relayed through MX backup
This is a test email
250 2.0.0 Ok: queued as A639C3EE6D
221 2.0.0 Bye

You should see the message be sent from your MX backup to the main server. The TLS loglevel settings we changed mean you should see a message in the logs about TLS being used for the connection between the backup and the primary server.

Test TLS is working for incoming mail submitted to the backup

We can use openssl s_client to check that TLS is working for incoming mail on the backup, and that the certificate is valid. For commercially signed certificates, the cert should already be in your trusted root store, so you can do this:

openssl s_client -starttls smtp -connect -CApath /etc/ssl/certs 

If you use CAcert and you haven't imported the root certificate yet, you might get output like this:

sam@T440s:~$ openssl s_client -starttls smtp -connect -CApath /etc/ssl/certs -quiet
depth=0 CN =
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN =
verify error:num=21:unable to verify the first certificate
verify return:1
250 DSN
221 2.0.0 Bye

If you don't want to add the CAcert root to the machine permanently you can download it to your home directory and use it just to test, like this:

curl -O --insecure

Which downloads it to ~/root.crt, and you can then ask openssl to check the certificate from the network against the CAcert root cert:

sam@T440s:~$ openssl s_client -starttls smtp -connect -CAfile ~/root.crt -quiet
depth=1 O = Root CA, OU =, CN = CA Cert Signing Authority, emailAddress =
verify return:1
depth=0 CN =
verify return:1
250 DSN
221 2.0.0 Bye

"Live" test

If everything has worked so far, it's time to do a live test. On the main server, stop Postfix:

sudo service postfix stop

or with systemd:

sudo systemctl postfix stop

Then send an email to your primary email address from a freemail account. If you log in to the backup server, you should be able to see the message waiting in the queue with the postqueue command:

sam@NUC:~$ sudo postqueue -p
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------                            
09712A82       3717 Sun Jan 24 18:32:35                               
                                (mail for loops back to myself)               
-- 4 Kbytes in 1 Request.

or you can use the following command, which does the same thing:


If you want to read a message from the queue, you can use the postcat command, specifying the unique ID of the message you would like to read, e.g.

sudo postcat -q 09712A82

Now you can bring Postfix back up on the primary server:

sudo service postfix start

or with systemd:

sudo systemctl postfix start

You can now either wait for postfix to attempt a redelivery, or manually flush the queue on the backup server with this command:

sudo postqueue -f

...which will force the backup to attempt delivery now, and the email should come through on the primary server. If you want to delete all email from the queue, you can use the following command:

sudo postsuper -d ALL


Mutt is a commandline email client that is perfect for checking email sent to using SSH if you don't want to do a full Dovecot installation like on the primary mail server.


To install mutt on debian derivatives:

sudo apt-get update
sudo apt-get install mutt

Or for openSUSE:

sudo zypper refresh
sudo zypper in mutt


Per-user configuration for Mutt is stored in ~/.muttrc. If the file doesn't exist, create it. The following parameters can be used to configure Mutt for use with the Maildir format we asked Postfix to use earlier (by default Mutt expects Mbox):

set mbox_type=Maildir                                                                        
set folder="~/Maildir"                                                                       
set mask="!^\\.[^.]"                                                                         
set mbox="~/Maildir"                                                                         
set record="+.Sent"                                                                          
set postponed="+.Drafts"                                                                     
set spoolfile="~/Maildir"

To launch mutt, simply type:


The interface is fairly self-explanatory, you can navigate through the messages in the inbox using the arrow keys, press enter to view the message, and when you're done press q to quit.

Useful links


Hi Sam,

I have followed the mail server setup - without spamassasin for the moment - and everything works perfectly. Next step is installing the backup mail server on a new RaspbertPi. Again, I have followed the tutorial. I had earlier generated * certificates (.crt and .key) as you suggested so presume these can be used on the backup server in /etc/ssl/certs and /etc/ssl/private.

Problem (perhaps): on restarting postfix at the end I get this messages repeated 6 times:
Starting Postfix Mail Transport Agent: postfixpostconf: warning: /etc/postfix/ unused parameter: smtpd_relay_restrictions=permit_mynetworks, reject_unauth_destination

followed by 16 identical messages from /usr/sbin/postconf. I have checked the text in which is:
smtpd_recipient_restrictions =
smtpd_relay_restrictions =

Can these warning messages be ignored? If these parameters are unused, are they needed?

Also, I added inet_protocols = ipv4 to to avoid a bunch of IPv6 complaints.


Hi John, Thanks for trying it out. Sounds like you might have an old version of Postfix (before 2.10). I wrote this assuming everyone would be using newer versions since Jessie came out a while ago and it ships with 2.11. If you're on Wheezy and you don't want to upgrade to Jessie, you need to combine the relay and recipient lists like in the main raspberry pi email server tutorial. See the Postfix manual for more info. Sam

Hi Sam,

Thanks for the comment. I'm surprised that apt-get install postifx does not install the latest version. Hmmm. What, then, does apt-get really do?

Ok...I'll wipe the SD card and install Jessie and try again.


It installs the latest version in the repos, but since Wheezy and Jessie are different stable releases of Debian they have different repos. There is a feature freeze at some point before the release, after which only bug and security fixes are included in the updates (no new features). If you want the latest version of every package, you have to use something like Debian Sid ("unstable"), or Tumbleweed on openSUSE. These distros aren't exactly unstable, but they are certainly more likely to break (sometimes upgrading one package will break compatibility with another, which is the reason for the feature freeze in stable distros). Not sure if there are any unstable/rolling release distros for RasPi, but even if there were I wouldn't recommend them for a server. Sam

Hi Sam,

I found jessie and installed this on my SD card. After setting up my usual infrastructure, installed postfix and followed the MX Backup tutorial without error mesages. Good.

Next step is to visit my son (on plusnet with a static IP address) who has agreed to host the backup server. Will get in touch again when this is tested in case I need further advice. (Maybe some weeks...)

Thanks again for your quick responses and help. Excellent...


Hi Sam,

The backup pi is now connected to a remote router (30 miles from me). I can ssh to I have successfully executed this line from my primary server here:
openssl s_client -starttls smtp -connect -CApath /etc/ssl/certs
and see my certificate. It concludes with this:
Start Time: 1456082630
Timeout : 300 (sec)
Verify return code: 0 (ok)
250 DSN
221 2.0.0 Bye

Next step: login to MX backup server and type the test as prescribed
telnet localhost 25
mail from:
rcpt to:
Subject: test
Email test

But there are problems shown in mail.log as follows: (where IP address has been replaced by

jmnpi3:~> sudo tail /var/log/mail.log
Feb 21 19:28:38 jmnpi3 postfix/smtp[13289]: Anonymous TLS connection established to[]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Feb 21 19:28:38 jmnpi3 postfix/smtp[13289]: AB2583FB1D: to=<>,[]:25, delay=34, delays=34/0.04/0.66/0.11, dsn=5.7.1, status=bounced (host[] said: 554 5.7.1 <>: Helo command rejected: Get lost - you are lying about who you are (in reply to RCPT TO command))
Feb 21 19:28:38 jmnpi3 postfix/cleanup[13287]: A448B3FB5B: message-id=<>
Feb 21 19:28:38 jmnpi3 postfix/qmgr[11956]: A448B3FB5B: from=<>, size=2427, nrcpt=1 (queue active)
Feb 21 19:28:38 jmnpi3 postfix/bounce[13290]: AB2583FB1D: sender non-delivery notification: A448B3FB5B
Feb 21 19:28:38 jmnpi3 postfix/qmgr[11956]: AB2583FB1D: removed
Feb 21 19:28:39 jmnpi3 postfix/smtp[13289]: Anonymous TLS connection established to[]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Feb 21 19:28:39 jmnpi3 postfix/smtp[13289]: A448B3FB5B: to=<>,[]:25, delay=0.69, delays=0.03/0.01/0.53/0.13, dsn=5.7.1, status=bounced (host[] said: 554 5.7.1 <>: Helo command rejected: Get lost - you are lying about who you are (in reply to RCPT TO command))
Feb 21 19:28:39 jmnpi3 postfix/qmgr[11956]: A448B3FB5B: removed
Feb 21 19:28:39 jmnpi3 postfix/smtpd[13263]: disconnect from localhost[::1]

On the primary server:

jmnpi2:~> more /etc/postfix/helo_access (and I had executed sudo postmap /etc/postfix/helo_access REJECT Get lost - you are lying about who you are REJECT Get lost - you are lying about who you are

(I have also tried replacing the in the helo_access file with without improvement)

The primary server has:
smtpd_helo_required = yes
smtpd_helo_restrictions =
check_helo_access hash:/etc/postfix/helo_access

dig MX shows everything correct.

Q1: It would appear I have got something wrong with ehlo checking.

Remote router has port 25 open to the MX backup. I am note sure where to begin looking for a solution - need your expert advice...


Hi John, You found the problem, and your solution (remove/edit those lines in the helo access file) should work if you postmap the file and reload postfix afterwards. Sam

Hi Sam,

I have tried two possibilities with helo_access


In both cases followed by: sudo postmap /etc/postfix/helo_access and sudo service postfix restart

I have tried (on the primary server) to change helo_restrictions to:
smtpd_helo_restrictions =
# reject_invalid_helo_hostname,
# reject_unknown_helo_hostname,
check_helo_access hash:/etc/postfix/helo_access

In every case I get the same rejection:
status=bounced (host[] said: 554 5.7.1 <>: Helo command rejected: Get lost

I have got something wrong. I have checked primary server and backup server several times against the documentation. really stuck. I would have thought that the # commented lines would have helped. Why not?


I was expecting you to either comment the line in /etc/postfix/helo_access, or comment the check_helo_access line in the restriction list, which is what I did. The other items in the list that you tried commenting aren't what is causing the problem. Anyway, I found a better way and wrote a new section on this under "Helo restrictions on the primary server", give that a go? Sam

Hi Sam,

A clue maybe: your tutorial states:

Now anyone who tries to ehlo with one of the hostnames you defined in that file gets rejected, and sees the “get lost” message. Your legitimate servers won’t have that problem, because they will already have been accepted higher up the list.

So I edited the helo_access file so that the entry is NOT my domain. It works!! So the statement above: ...because they will already have been accepted higher up the list.... what is meant by higher up the list?

Just seen your email: so your suggestion "comment the line in /etc/postfix/helo_access" is just what I did and reported above.

I'll now go and read the changes you made and remove the # I added to helo_restrictions in


Hi Sam,

Ok..I saw the comment and added the line:
parent_domain_matches_subdomains =
to the primary server

I also replaced REJECT in helo_access; postmap; restart

But mail is bounced again : helo command rejected.

It seems that helo_access file should not contain a proper

This is how my servers are configured, and it is working for me. It might be something else... What do you get in the logs on the client and server when you attempt to send an email through the backup? Sam

Hi Sam,

In a previous submission I sent the MX backup mail log. Here is an example of the primary server log:
Feb 21 20:56:18 jmnpi2 postfix/smtpd[20692]: connect from[]
Feb 21 20:56:19 jmnpi2 postfix/smtpd[20692]: NOQUEUE: reject: RCPT from[]: 554 5.7.1 <>: Helo command rejected: Get lost - you are lying about who you are; from=<> to=<> proto=ESMTP helo=<>
Feb 21 20:56:19 jmnpi2 postfix/smtpd[20692]: disconnect from[]
Feb 21 20:56:20 jmnpi2 postfix/smtpd[20692]: connect from[]
Feb 21 20:56:20 jmnpi2 postfix/smtpd[20692]: NOQUEUE: reject: RCPT from[]: 554 5.7.1 <>: Helo command rejected: Get lost - you are lying about who you are; from=<> to=<> proto=ESMTP helo=<>
Feb 21 20:56:20 jmnpi2 postfix/smtpd[20692]: disconnect from[]

Is there hint from this:

Now anyone who tries to ehlo with one of the hostnames you defined in that file gets rejected, and sees the “get lost” message. Your legitimate servers won’t have that problem, because they will already have been accepted higher up the list.

This points to an order in the authorisation process which, in my case, is out of step. That is: "has NOT already been accepted higher up the list" so gets caught in the helo trap.


PS: Thanks a lot for your assistance. But tempus fugit and I need to sign off for this evening. I'll try some more experiments tomorrow.

If your helo_access file on the main server has just this one line: REJECT Get lost - you're lying about who you are
And you have:
parent_domain_matches_subdomains =
in your on the main server, and it isn't overwritten later in the file, then the helo from your backup server ( doesn't match the hostnames you defined in the helo_access file ( and shouldn't be rejected. Are you certain you changed the parent_domain_matches_subdomains on the right server? Can you post the output of:
postconf -n
on your main server? Sam

Hi Sam,

OK..."parent_domain_matches_subdomains =" is definitely in I then deleted the second entry in helo_access. Immediate success. I think I was confused from the item in the postfix tutorial:

Add the following lines, edited for your domain: REJECT Get lost - you're lying about who you are REJECT Get lost - you're lying about who you are
where I thought a backup entry was required as well.

Then followed the next series of tests you suggest: primary server off; external email to primary server; observe email now in backup server; examine with postqueue -p; mailq; postqueue -q ABCDEF; then primary server on; postqueue -f on backup; observe email delivered to primary server.

Excellent. Your help, as always, is magic.

This begs a few operational questions about the backup server:
1. at what frequency does the backup server attempt a connection to the primary?
2. is this frequency a parameter?
3. how many times will the backup server attempt a connection before reporting to the original sender that email cannot be delivered?
4. is this counter also a parameter?

I have looked at the URL pointing to the list of Postfix configuration parameters but there are so many it's hard to pick out anything relevant.


Great :) glad it's sorted! In answer to your (excellent) questions:
  1. I don't know - like you, I tried to look it up, spent a while searching and couldn't find what I was looking for. I've been meaning to come back to it.
  2. Almost certainly, yes.
  3. Again, I don't know - I'll try and find out.
  4. Almost certainly, yes.
I'll do some more research and see what I can find. Sam

Hi Sam,

I did a search on "default" in the Postfix configuration list and found these items. Do you suppose these might have a bearing on what I was looking for?

maximal_backoff_time (default: 4000s)

The maximal time between attempts to deliver a deferred message.
This parameter should be set to a value greater than or equal to $minimal_backoff_time. See also $queue_run_delay.
Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is s (seconds).

minimal_backoff_time (default: 300s)

The minimal time between attempts to deliver a deferred message; prior to Postfix 2.4 the default value was 1000s.
This parameter also limits the time an unreachable destination is kept in the short-term, in-memory, destination status cache.
This parameter should be set greater than or equal to $queue_run_delay. See also $maximal_backoff_time.
Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is s (seconds).

queue_run_delay (default: 300s)

The time between deferred queue scans by the queue manager; prior to Postfix 2.4 the default value was 1000s.
This parameter should be set less than or equal to $minimal_backoff_time. See also $maximal_backoff_time.
Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is s (seconds).

maximal_queue_lifetime (default: 5d)

Consider a message as undeliverable, when delivery fails with a temporary error, and the time in the queue has reached the maximal_queue_lifetime limit.
Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is d (days).
Specify 0 when mail delivery should be tried only once.

Yep, those are the right parameters (you can get a list of all the default values by running postconf -d by the way!). I was expecting to find additional parameters to differentiate between "normal" mail and MX backup mail, but I has another rummage and it seems it's all treated the same way! I guess you can just set the maximal_queue_lifetime to a value longer than 5 days if you think your main server might be offline longer than that (hopefully not!) Sam

Hi Sam,

I thought the minimal_backoff_time of 5 mins was too short. I changed this to 30mins as a test and tried it. And yes, 30 mins later the test email arrived. So I think I can say that my new mailer plus backup server is in full operational order.

The reason for doing all this in the first place is that my ISP has already withdrawn from providing web services; they had handed over email services to Inty Ltd for "at least" 2 years but there is a suspicion that email service will also be withdrawn. It is also unlikely that they will provide FTTC serivce. I had to find an alternative. I came across your tutorials last year and later decided to go for it in full. I am satisfied that I now have a working system for our 9 email accounts and will start to migrate from my current email service. I have a contract until November at which point I will make the final move to FTTC via plusnet (probably) and my new mail system. I am indebted to you for your guidance and assistance and masterly tutorials. There is no way I could have set this up without them.

Best wishes....John

Fabio Almeida

Sat, 06/04/2016 - 19:18

Hi Sam,
First of all, thank you for your tutorials. I setup my home e-mail services, using most of the time your tutorial.
I suggest for e-mail home servers to contract DNS Made Easy service "Backup E-mail" to receive the e-mail when the home server is down. Once the home server is up, they deliver the e-mail to home server. It cost 12.95 a year, but you need to sign there DNS services for 29.95 a year. There DNS services are very professional and it is possible to setup DKIM for home email server.

HI Sam, Del here again. The following state Comcast's position on port 25. My qeustion is if I set up an email server using TLS/SSL if it would work with Comcast? Could you point me in the direction of a tutorial on how to do that?

Why is Comcast Supporting Port 587?
The original/legacy email ports, 25 and 110, have been in use since the inception of email and have limited or no security features. As a result, port 25 has been used for the transmission of spam and malware from infected computers for nearly a decade. Port 110 simply is not a secure means of retrieving email. Port 995 provides SSL encryption when downloading email.

It has been a long standing recommendation from M3AAWG, an international community of anti-abuse professionals, and the Internet Engineering Task Force (IETF), that port 25 be blocked. In an effort to provide our customers with the greatest security when using email, Comcast recommends the use of the industry-recommended port 587 with TLS/SSL enabled. The recommendations from M3AAWG can be read here and you can also view the IETF RFC 5068 and RFC 4409 (section 3.1, see below).

I can understand their concerns with security but surely there must be a way to run an email server on their network.

No, you won't be able to run an email server on their network that can send outside email directly. They must unblock the ports for some customers (e.g. small businesses) though, since they will run servers, are those price plans extortionate? Sometimes ISPs provide a mail proxy that can be used (usually how this works is your server authenticates with your broadband username & pw every time you send an email, the email is sent to your ISP's server, probably scanned & logged, and then relayed to its destination). This requires some extra configuration in Postfix and IMO defeats the point of hosting your own server (privacy etc.). Unfortunately, the config depends on your ISP, too, so I can't help you with that. Sam

Hello Sam,

for some reasons my counterparts receive an error when trying to send me an email (they use MS Outlook 365):

Remote Server returned '550 5.4.300 Message expired -> 450 4.1.0 Don't use the Backup MX '' while the Primary MX is available - please send your mail to xxx.xx

Is there anything within the postfix configuration to avoid this?

Thanks in advance,

Add new comment

The content of this field is kept private and will not be shown publicly.

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.