Configure Postfix Mail Server High Availability on Ubuntu VPS

Understanding Mail Server High Availability Architecture

Mail server downtime kills business communications and frustrates customers. When you configure Postfix mail server high availability on your Ubuntu VPS, you build an email infrastructure that survives server failures without dropping messages.

The setup involves two or more Postfix servers working in tandem. Your primary server handles daily operations while backup servers watch its health.

If the primary fails, traffic switches to a backup within minutes.

This guide walks through creating a master-backup Postfix configuration with shared storage, health monitoring, and automatic failover. You'll need at least two Ubuntu VPS instances and shared storage like NFS or GlusterFS.

Prerequisites and Server Setup Requirements

Both servers need these specifications:

• Ubuntu 20.04 LTS or newer with root access
• At least 2GB RAM and 20GB storage per server
• Static IP addresses for both servers
• Domain with proper DNS configuration
• Shared storage accessible from both servers

Your DNS needs multiple MX records pointing to both servers with different priorities. Give the primary server priority 10.

Backup servers get priority 20 and higher.

Install base packages on both servers:

apt update && apt upgrade -y
apt install postfix postfix-mysql dovecot-core dovecot-imapd dovecot-pop3d \
  nfs-common keepalived rsync -y

Set each server's hostname and update /etc/hosts with both server entries. This prevents DNS lookup delays during failover.

Setting Up Shared Mail Storage

Shared storage lets both servers access identical mailboxes and configuration files. Set up an NFS share on your primary server or use dedicated storage.

Create the shared directory structure:

mkdir -p /shared/mail/{domains,config}
chown -R mail:mail /shared/mail
chmod 755 /shared/mail

Configure NFS exports on your storage server in /etc/exports:

/shared/mail 192.168.1.10(rw,sync,no_subtree_check) 192.168.1.11(rw,sync,no_subtree_check)

Mount shared storage on both mail servers:

echo "192.168.1.5:/shared/mail /var/mail nfs defaults 0 0" >> /etc/fstab
mount -a

Test write access from both servers. Create test files and verify they appear on both systems immediately.

Configure Postfix Mail Server High Availability Settings

Your Postfix configuration must work identically on both servers. Configure the primary server's /etc/postfix/main.cf:

myhostname = mail1.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4
mydestination = localhost
relayhost =
relay_domains =
home_mailbox = Maildir/
mailbox_command =

# Virtual domain configuration
virtual_mailbox_domains = /etc/postfix/virtual_domains
virtual_mailbox_maps = /etc/postfix/virtual_mailboxes
virtual_alias_maps = /etc/postfix/virtual_aliases
virtual_mailbox_base = /var/mail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000

# Security settings
smtpd_tls_cert_file = /etc/ssl/certs/mail.crt
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache

Use identical settings on the backup server. Change only the hostname to mail2.example.com.

Store all virtual domain files on shared storage.

When working with Hostperl VPS hosting, our support team can optimize these configurations for your specific setup and traffic patterns.

Implementing Keepalived for Failover Management

Keepalived manages the virtual IP address that clients connect to. Configure /etc/keepalived/keepalived.conf on the primary server:

vrrp_script chk_postfix {
    script "/usr/local/bin/check_postfix.sh"
    interval 30
    weight -2
    fall 3
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ChangeMe123
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
    track_script {
        chk_postfix
    }
    notify_master "/usr/local/bin/postfix_master.sh"
    notify_backup "/usr/local/bin/postfix_backup.sh"
}

On the backup server, change state to BACKUP and reduce priority to 100. Both servers monitor Postfix health.

They automatically promote the backup when the primary fails.

Create the health check script at /usr/local/bin/check_postfix.sh:

#!/bin/bash
if systemctl is-active --quiet postfix; then
    if netstat -ln | grep -q ":25 "; then
        exit 0
    fi
fi
exit 1

Make the script executable and test it manually.

Database Replication for User Management

If using MySQL for virtual domain management, set up master-slave replication between mail servers. This keeps user accounts and aliases synchronized.

Configure the master server's MySQL in /etc/mysql/mysql.conf.d/mysqld.cnf:

[mysqld]
log-bin = mysql-bin
server-id = 1
binlog-do-db = mailserver
binlog-ignore-db = mysql

Create a replication user on the master:

CREATE USER 'replicator'@'192.168.1.11' IDENTIFIED BY 'strong_password';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'192.168.1.11';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;

Configure the slave server using the binlog position from the status output. Test replication by creating test records.

Verify they appear on both servers.

Our email hosting warm-up strategies help you properly introduce your new setup to email providers.

Setting Up Health Monitoring and Alerts

Monitoring catches issues before they affect users. Install monitoring tools on both servers:

apt install nagios-nrpe-server monitoring-plugins -y

Create custom checks for mail server components. Monitor queue size, disk usage, memory consumption, and service availability:

#!/bin/bash
# Check mail queue size
queue_size=$(postqueue -p | tail -1 | cut -d' ' -f5)
if [ "$queue_size" -gt 100 ]; then
    echo "CRITICAL: Mail queue size is $queue_size"
    exit 2
fi
echo "OK: Mail queue size is $queue_size"
exit 0

Set up email alerts for failover events and queue threshold breaches. Run checks every 5 minutes for critical services.

Run them every 15 minutes for capacity metrics.

Log all failover events and mail server statistics. This data reveals patterns and helps optimize your configuration.

Testing Failover and Recovery Procedures

Regular testing ensures your setup works when needed. Create a testing checklist covering various failure scenarios.

Test primary server failure by stopping Postfix:

systemctl stop postfix
# Wait 2-3 minutes
ip addr show  # Verify VIP moved to backup
tail -f /var/log/syslog  # Monitor keepalived logs

Send test emails during failover to verify continued delivery. Check that users can still authenticate and access mailboxes through IMAP/POP3.

Test recovery by restarting Postfix on the primary:

systemctl start postfix
# Verify VIP returns to primary
# Check that queued messages process normally

Document procedures and maintain logs of each test. Include performance metrics like failover time and message delays during transitions.

Performance Tuning for Load Distribution

Distribute load across multiple servers for better performance. Configure DNS with equal priority MX records to balance incoming mail:

example.com.     IN  MX  10  mail1.example.com.
example.com.     IN  MX  10  mail2.example.com.

This distributes new connections between servers while maintaining failover capability. Monitor connection distribution.

Adjust DNS caching TTL values as needed.

Tune Postfix for your expected message volume:

# Increase concurrent connections
default_process_limit = 200
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 100

# Optimize queue processing
max_queue_run_delay = 300s
minimal_backoff_time = 120s
maximal_backoff_time = 4000s

Review our Postfix performance monitoring guide for detailed optimization strategies.

Security Hardening for Production Deployment

High availability mail servers need extra security measures. They handle more traffic and have complex configurations.

Configure fail2ban with mail-specific rules:

[postfix-sasl]
enabled = true
port = smtp,ssmtp,submission
filter = postfix-sasl
logpath = /var/log/mail.log
maxretry = 3
bantime = 3600

[dovecot]
enabled = true
port = pop3,pop3s,imap,imaps,submission,ssmtp
filter = dovecot
logpath = /var/log/mail.log
maxretry = 3
bantime = 3600

Implement rate limiting for SMTP connections to prevent abuse:

# In /etc/postfix/main.cf
smtpd_client_connection_rate_limit = 100
smtpd_client_message_rate_limit = 100
smtpd_client_recipient_rate_limit = 1000

Configure SSL/TLS properly across both servers with identical certificates. Use Let's Encrypt or commercial certificates.

Ensure both servers access the same certificate files through shared storage.

Frequently Asked Questions

How long does failover take with this Postfix HA setup?

Typical failover completes within 2-3 minutes using keepalived. The health check runs every 30 seconds.

After 3 consecutive failures (90 seconds), keepalived promotes the backup server. DNS propagation may add 1-2 minutes depending on TTL settings.

Can I use this setup with more than two mail servers?

Yes, you can configure multiple backup servers by adjusting keepalived priorities. Set the primary to 110, first backup to 100, second backup to 90, and so on.

All servers need access to shared storage and identical configurations.

What happens to emails in transit during failover?

Emails being received during failover may be temporarily rejected with a 4xx error. This causes sending servers to retry.

Messages in the queue on the failed server will be processed once it recovers. You can also manually move queue files to the active server.

How much additional storage do I need for shared mail data?

Plan for 150-200% of your current mailbox storage to account for backups, logs, and growth. A typical small business setup needs 100-500GB of shared storage.

Larger organizations may require several terabytes.

Should I use the same database server for both mail servers?

For true high availability, use database replication rather than a single shared database server. A single database creates a single point of failure.

This defeats the purpose of having redundant mail servers.