Building a Secure Email Server: Part 2 – Deployment

Time to complete: 2-3 hours
Monthly cost: ~$12.50 ($12 DigitalOcean + $0.50 AWS S3)
Prerequisites: Part 1 (component selection), domain registered with Cloudflare DNS, basic Linux familiarity

Introduction

In Part 1, we selected components and justified the hybrid architecture: self-hosted mail server for receiving with commercial relay for sending. This article walks through the actual deployment, ending with a fully functional mail server that can receive email and provide IMAP access.

We’ll also confront the reality of outbound email delivery for small self-hosted servers—specifically why AWS SES denied our production access request and what we’re doing about it.

What you’ll have by the end:

• Mail server receiving email on your domain
• IMAP access from any email client
• TLS encryption throughout
• Automated backups to AWS S3
• Foundation for reliable outbound delivery (covered in Part 3)

Preparation

Server Provisioning

Create a $6/month DigitalOcean droplet with these specifications:

• Image: Ubuntu 24.04 LTS x64
• Plan: Basic Shared CPU, $6/month (1GB RAM, 25GB SSD, 1000GB transfer)
• Region: Choose geographically closest to you for lower latency
• Authentication: SSH keys (if you don’t have keys, generate them on your local machine first)
• Hostname: mail-[your-domain]
• Tags: mail, production (optional, for organization)

After the droplet is created, note the IP address and log in:

# Connect to your server
ssh root@[your-droplet-ip]

# You should see the Ubuntu welcome message

Update the system immediately:

# Update package lists
sudo apt update

# Upgrade all packages
sudo apt upgrade -y

# This may take 2-5 minutes

Set the hostname properly:

# Set the fully qualified domain name
sudo hostnamectl set-hostname mail.[your-domain].com

# Verify it was set
hostname -f
# Should output: mail.[your-domain].com

Configure the firewall (UFW) before anything else:

This is critical—configure all ports before enabling the firewall to avoid locking yourself out.

# Check current status (should be inactive)
sudo ufw status

# Set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH FIRST (critical - don't skip this!)
sudo ufw allow 22/tcp
# Output: Rules updated

# Allow mail server ports
sudo ufw allow 25/tcp    # SMTP (receiving mail from other servers)
sudo ufw allow 587/tcp   # SMTP submission (authenticated sending)
sudo ufw allow 993/tcp   # IMAPS (encrypted IMAP)

# Allow web ports for Let's Encrypt and future webmail
sudo ufw allow 80/tcp    # HTTP (Let's Encrypt challenge)
sudo ufw allow 443/tcp   # HTTPS (webmail)

# Enable the firewall
sudo ufw enable
# Press 'y' when prompted

# Verify all rules are in place
sudo ufw status verbose

Expected output:

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
25/tcp                     ALLOW       Anywhere
587/tcp                    ALLOW       Anywhere
993/tcp                    ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere

Create a non-root administrative user:

Running everything as root is a security risk. Create a dedicated user:

# Create user (you'll be prompted for password and info)
adduser [username]

# Add to sudo group for administrative privileges
usermod -aG sudo [username]

# Verify user was created
id [username]
# Should show uid, gid, and groups including sudo

For the rest of this guide, you can continue as root for service configuration, or switch to your new user with su - [username]. Service installation and configuration typically require sudo/root access.

Common issue: If you enable UFW before allowing port 22, you’ll be locked out immediately. Use DigitalOcean’s web console (droplet → Access → Launch Droplet Console) to regain access and run ufw allow 22/tcp && ufw reload.

DNS Configuration

Configure these records in Cloudflare before installing mail software. DNS propagation takes 2-10 minutes, so we set this up first.

Log into Cloudflare and select your domain.

Navigate to DNS → Records, then add each of these:

1. A Record (Mail Server IP):

Type: A
Name: mail
Content: [your-droplet-ip]
Proxy status: DNS only (gray cloud - CRITICAL)
TTL: Auto

Click “Save”. The proxy status must be DNS only (gray cloud icon, not orange). SMTP and IMAP protocols don’t work through Cloudflare’s HTTP proxy.

2. MX Record (Mail Destination):

Type: MX
Name: @ (or leave blank for root domain)
Mail server: mail.[your-domain].com
Priority: 10
Proxy status: DNS only
TTL: Auto

The priority value (10) determines which server receives mail if you have multiple MX records. Lower numbers have higher priority.

3. SPF Record (Sender Policy Framework):

Type: TXT
Name: @ (root domain)
Content: v=spf1 ip4:[your-droplet-ip] include:amazonses.com -all
TTL: Auto

This tells receiving servers which IPs are authorized to send mail from your domain. The -all means “reject all other senders.”

4. DMARC Record (Domain-based Message Authentication):

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc@[your-domain].com
TTL: Auto

DMARC tells receiving servers what to do with mail that fails SPF/DKIM checks. p=none is monitoring mode—good for initial setup. The rua address receives aggregate reports.

Your DNS records should now look like this:

Configure PTR Record (Reverse DNS):

PTR records map IP addresses back to hostnames. Many mail servers reject email if the sending IP doesn’t have a proper PTR record.

In DigitalOcean:

1. Go to your droplet page
2. Click the Networking tab
3. Scroll to “PTR Record” or “Reverse DNS”
4. Enter: mail.[your-domain].com
5. Click “Update” or “Save”

Some DigitalOcean regions show this differently—if you don’t see it, check Networking → Domains or submit a support ticket.

Wait 2-5 minutes for DNS propagation, then verify from your mail server:

# Test A record (should return your droplet IP)
dig mail.[your-domain].com +short

# Expected output:
# [your-droplet-ip]

# Test MX record
dig MX [your-domain].com +short

# Expected output:
# 10 mail.[your-domain].com.

# Test SPF record
dig TXT [your-domain].com +short

# Expected output (among other TXT records):
# "v=spf1 ip4:[your-droplet-ip] include:amazonses.com -all"

# Test PTR record (reverse lookup)
dig -x [your-droplet-ip] +short

# Expected output:
# mail.[your-domain].com.

If any of these fail, wait a few more minutes and try again. DNS propagation can take up to 10 minutes, occasionally longer.

Common issues:

1. dig mail.[your-domain].com returns 127.0.0.1: The server is resolving via /etc/hosts. Check and remove any lines containing your mail hostname:

# Check hosts file
cat /etc/hosts

# If you see mail.[your-domain].com mapped to 127.0.0.1, edit and remove it
sudo nano /etc/hosts
# Delete the offending line, save and exit

# Flush DNS cache
sudo systemd-resolve --flush-caches
sudo systemctl restart systemd-resolved

# Test again
dig mail.[your-domain].com +short

2. MX record shows Cloudflare IPs: You accidentally left proxy mode on. Go back to Cloudflare DNS, click the orange cloud next to the mail A record to turn it gray (DNS only).
3. PTR record not working: Some regions require 24 hours or a support ticket. You can proceed with setup, but deliverability will be limited until PTR is configured.

TLS Certificates

Modern email requires TLS encryption. We’ll use Let’s Encrypt to get free, trusted certificates that auto-renew.

Install Certbot:

# Install certbot and dependencies
sudo apt install certbot -y

# Verify installation
certbot --version
# Should show: certbot 2.x.x

Obtain certificates using standalone mode:

Standalone mode temporarily runs a web server on port 80 for the Let’s Encrypt ACME challenge. This is why we opened port 80 in the firewall earlier.

# Request certificates
sudo certbot certonly --standalone -d mail.[your-domain].com

You’ll be prompted for:

1. Email address: Enter your email (used for renewal notices) Enter email address (used for urgent renewal and security notices): [email protected]
2. Terms of Service: Type A and press Enter to agree Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.3... (A)gree/(C)ancel: A
3. Share email with EFF: Type Y or N (your choice) Would you be willing to share your email with the Electronic Frontier Foundation? (Y)es/(N)o: N

Expected output on success:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/mail.[your-domain].com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/mail.[your-domain].com/privkey.pem
This certificate expires on 2026-05-13.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Verify certificate files exist:

# List certificate directory
sudo ls -la /etc/letsencrypt/live/mail.[your-domain].com/

# You should see:
# cert.pem -> ../../archive/mail.[your-domain].com/cert1.pem
# chain.pem -> ../../archive/mail.[your-domain].com/chain1.pem
# fullchain.pem -> ../../archive/mail.[your-domain].com/fullchain1.pem
# privkey.pem -> ../../archive/mail.[your-domain].com/privkey1.pem

The files you’ll use in configuration:

• fullchain.pem: Certificate + intermediate certificates (for public presentation)
• privkey.pem: Private key (keep this secure, never share)

Verify auto-renewal is configured:

Let’s Encrypt certificates expire after 90 days. Certbot automatically sets up a systemd timer to renew them.

# Check renewal timer status
sudo systemctl status certbot.timer

# Should show: active (waiting)

Test the renewal process (dry-run):

# Simulate renewal without actually renewing
sudo certbot renew --dry-run

# Should end with: Congratulations, all simulated renewals succeeded

This confirms that renewal will work when needed.

Common issues:

1. Connection timeout during challenge: Ensure port 80 is open in UFW (sudo ufw status | grep 80). Some hosting providers also have network-level firewalls—check DigitalOcean’s Cloud Firewall settings if enabled.
2. DNS validation failed: Certbot can’t resolve mail.[your-domain].com. Check that your A record exists and propagated with dig mail.[your-domain].com +short.
3. Certificate already exists: If you’re re-running certbot, you’ll see “Certificate not yet due for renewal”. This is fine—use the existing certificates.

Mailbox Essentials

Postfix: Receiving Mail

Postfix is the MTA (Mail Transfer Agent) that handles receiving mail from other servers and routing it to user mailboxes.

Install Postfix:

sudo apt install postfix -y

During installation, a configuration screen will appear:

1. General type of mail configuration:
   • Use arrow keys to select: Internet Site
   • Press Enter
2. System mail name:
   • Enter: [your-domain].com (without the mail. prefix)
   • This is your email domain, not the server hostname
   • Press Enter

The installation configures Postfix with basic settings. We’ll customize it next.

Backup the original configuration:

# Always backup before editing
sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.backup

# Verify backup exists
ls -la /etc/postfix/*.backup

Edit the main configuration file:

sudo nano /etc/postfix/main.cf

Verify these basic settings (they should already be set from installation, around lines 30-50):

myhostname = mail.[your-domain].com
mydomain = [your-domain].com
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
inet_interfaces = all
inet_protocols = ipv4

What these mean:

• myhostname: The server’s fully qualified domain name
• mydomain: Your email domain
• myorigin: What domain appears in mail sent from this server
• mydestination: Domains this server accepts mail for (local delivery)
• inet_interfaces: Listen on all network interfaces (not just localhost)
• inet_protocols: Use IPv4 only (simplifies configuration)

Scroll to the end of the file and add these sections:

# ====== Maildir Configuration ======
home_mailbox = Maildir/
mailbox_command =

# ====== TLS Configuration ======
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.[your-domain].com/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mail.[your-domain].com/privkey.pem
smtpd_tls_security_level=may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# ====== SASL Authentication ======
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname

# ====== Recipient Restrictions ======
smtpd_recipient_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

Configuration explanations:

Maildir:

• home_mailbox = Maildir/: Store mail in ~/Maildir/ instead of /var/mail/username
• mailbox_command =: Empty value disables any custom delivery agent

Why Maildir over mbox:

• Each email is a separate file (safer, less corruption)
• Better IMAP performance (no file locking issues)
• Can handle concurrent access properly
• Standard for modern mail servers

TLS Settings:

• smtpd_tls_cert_file/key_file: Point to Let’s Encrypt certificates
• smtpd_tls_security_level=may: Offer TLS but don’t require it (some servers don’t support it)
• smtpd_tls_loglevel = 1: Log TLS connections for debugging
• Session caches improve performance for repeated connections

SASL Authentication:

• smtpd_sasl_type = dovecot: Use Dovecot for authentication
• smtpd_sasl_path = private/auth: Socket path where Dovecot listens
• smtpd_sasl_auth_enable = yes: Enable SASL authentication
• noanonymous: Don’t allow anonymous authentication

Recipient Restrictions:

• permit_mynetworks: Allow mail from localhost
• permit_sasl_authenticated: Allow mail from authenticated users
• reject_unauth_destination: Reject mail to external domains (prevents open relay)

Save and exit: Ctrl+X, Y, Enter

Check for configuration errors:

# Postfix will report syntax errors
sudo postfix check

# If there are no errors, nothing is printed
# If there are errors, fix them before proceeding

Restart Postfix to apply changes:

# Restart the service
sudo systemctl restart postfix

# Check status
sudo systemctl status postfix

Expected output:

● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (exited) since Wed 2026-02-12 18:10:22 UTC

Verify Postfix is listening on port 25:

sudo ss -tlnp | grep :25

Expected output:

LISTEN 0    100    0.0.0.0:25    0.0.0.0:*    users:(("master",pid=12345,fd=13))

This confirms Postfix is listening on all interfaces (0.0.0.0) on port 25.

Check Postfix logs for any errors:

# View recent Postfix logs
sudo journalctl -u postfix -n 50 --no-pager

# Look for lines like:
# postfix/master[xxxxx]: daemon started -- version 3.x.x

If you see errors, address them before proceeding.

Common issues:

1. Postfix won’t start – configuration error: Run sudo postfix check for details. Common issues:
   • Typo in configuration file
   • Missing = sign or semicolon
   • Wrong certificate path
2. Port 25 not listening: Check if another service is using port 25: sudo lsof -i :25
3. Permission denied on certificates: Ensure Postfix can read Let’s Encrypt files: sudo ls -la /etc/letsencrypt/live/mail.[your-domain].com/ # Should be readable by root

Dovecot: IMAP Access

Dovecot provides IMAP access so email clients can retrieve mail. It also handles authentication for Postfix.

Install Dovecot packages:

# Install core Dovecot and IMAP daemon
sudo apt install dovecot-core dovecot-imapd dovecot-lmtpd -y

# Verify installation
dovecot --version
# Should show: 2.3.x or higher

Dovecot configuration is split across multiple files in /etc/dovecot/conf.d/. We’ll edit four key files.

1. Configure Authentication (10-auth.conf):

sudo nano /etc/dovecot/conf.d/10-auth.conf

Find and modify (around line 10):

disable_plaintext_auth = yes

This prevents password transmission without TLS. Uncommitted if it has a # at the start.

Find and modify (around line 100):

auth_mechanisms = plain login

This enables standard authentication methods. Again, remove # if present.

What this does: Requires TLS before accepting passwords (disable_plaintext_auth), and accepts both PLAIN and LOGIN auth methods (compatible with all email clients).

Save and exit: Ctrl+X, Y, Enter

2. Configure Mail Location (10-mail.conf):

sudo nano /etc/dovecot/conf.d/10-mail.conf

Find and set (around line 30):

mail_location = maildir:~/Maildir

Remove the # if present. This tells Dovecot to look for mail in each user’s ~/Maildir directory.

Save and exit: Ctrl+X, Y, Enter

3. Configure SSL/TLS (10-ssl.conf):

sudo nano /etc/dovecot/conf.d/10-ssl.conf

Find and set (around line 6):

ssl = required

Change from ssl = yes to ssl = required to enforce TLS.

Find and modify (around lines 12-14):

ssl_cert = </etc/letsencrypt/live/mail.[your-domain].com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.[your-domain].com/privkey.pem

Important: Note the < before the path. This tells Dovecot to read the file contents.

Replace the default paths (pointing to /etc/dovecot/private) with your Let’s Encrypt certificates.

Save and exit: Ctrl+X, Y, Enter

4. Configure Postfix Authentication Socket (10-master.conf):

This is the most critical configuration—it allows Postfix to authenticate users via Dovecot.

sudo nano /etc/dovecot/conf.d/10-master.conf

Find the service auth section (around line 95). It will look like:

service auth {
  # auth_socket_path points to this userdb socket by default. It's typically
  # used by dovecot-lda, doveadm, possibly imap process, etc. Users that have
  # full permissions to this socket are able to get a list of all usernames and
  # get the results of everyone's userdb lookups.
  #
  # The default 0666 mode allows anyone to connect to the socket, but the
  # userdb lookups will succeed only if the userdb returns an "uid" field that
  # matches the caller process's UID. Also if caller's uid or gid matches the
  # socket's uid or gid the lookup succeeds. Anything else causes a failure.
  #
  # To give the caller full permissions to lookup all users, set the mode to
  # something else than 0666 and Dovecot lets the kernel enforce the
  # permissions (e.g. 0777 allows everyone full permissions).
  unix_listener auth-userdb {
    #mode = 0666
    #user = 
    #group = 
  }
}

Replace the entire service auth section with:

service auth {
  unix_listener auth-userdb {
    #mode = 0666
    #user = 
    #group = 
  }
  
  # Postfix smtp-auth
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

What this does: Creates a Unix socket at /var/spool/postfix/private/auth that Postfix can use to verify user credentials. The permissions (0660) and ownership (postfix:postfix) allow Postfix to access it.

Save and exit: Ctrl+X, Y, Enter

Add Dovecot user to Postfix group:

This ensures Dovecot has permission to create the socket in Postfix’s directory:

# Add dovecot to postfix group
sudo usermod -aG postfix dovecot

# Verify
groups dovecot
# Should show: dovecot : dovecot postfix

Ensure the private directory exists with correct permissions:

# Check if directory exists
sudo ls -la /var/spool/postfix/private/

# If it doesn't exist, create it
sudo mkdir -p /var/spool/postfix/private/

# Set ownership and permissions
sudo chown postfix:postfix /var/spool/postfix/private/
sudo chmod 750 /var/spool/postfix/private/

Restart Dovecot:

# Restart to apply all configuration changes
sudo systemctl restart dovecot

# Check status
sudo systemctl status dovecot

Expected output:

● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled)
     Active: active (running) since Wed 2026-02-12 18:15:30 UTC

Verify the authentication socket was created:

sudo ls -la /var/spool/postfix/private/auth

Expected output:

srw-rw---- 1 postfix postfix 0 Feb 12 18:15 /var/spool/postfix/private/auth

The s indicates a socket file, and permissions rw-rw---- mean read/write for user and group (postfix).

Verify Dovecot is listening on port 993:

sudo ss -tlnp | grep :993

Expected output:

LISTEN 0    100    0.0.0.0:993    0.0.0.0:*    users:(("dovecot",pid=31055,fd=37))

Check Dovecot logs:

sudo journalctl -u dovecot -n 50 --no-pager

Look for:

• master: Dovecot v2.3.x starting up
• No error messages

Common issues:

1. Auth socket not created: Most common issue. Solutions: # Verify dovecot is in postfix group groups dovecot # Restart both services in order sudo systemctl restart dovecot sudo systemctl restart postfix # Check again sudo ls -la /var/spool/postfix/private/auth
2. Port 993 not listening: Dovecot may have failed to start. Check logs: sudo journalctl -u dovecot -n 100 --no-pager | grep -i error
3. SSL certificate errors: Verify paths are correct and files are readable: sudo ls -la /etc/letsencrypt/live/mail.[your-domain].com/ sudo dovecot -n | grep ssl_cert
4. “doveconf: Fatal: Error in configuration file”: Syntax error in a config file. Check which file: sudo doveconf -n # Will show the error location

Submission Port Configuration

Port 587 is the standard port for mail submission (sending) with authentication. We’ll enable it now so it’s ready for future SMTP relay configuration.

Edit Postfix master configuration:

sudo nano /etc/postfix/master.cf

Find the submission section (around lines 17-30). It will be commented out with # symbols:

#submission inet n       -       y       -       -       smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes

Uncomment and configure it to look like this (remove ALL # symbols from these lines):

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject

Important: The lines starting with -o must have leading spaces (not tabs). They are option overrides for this specific service.

What each option does:

• syslog_name=postfix/submission: Log entries clearly marked for port 587
• smtpd_tls_security_level=encrypt: Require TLS (unlike port 25 which is optional)
• smtpd_sasl_auth_enable=yes: Enable authentication
• smtpd_tls_auth_only=yes: Only allow authentication over TLS
• smtpd_reject_unlisted_recipient=no: Accept mail for any domain (relay it)
• smtpd_client_restrictions=permit_sasl_authenticated,reject: Only authenticated users
• smtpd_relay_restrictions=permit_sasl_authenticated,reject: Only relay for authenticated users

Why port 587 instead of 465:

• Port 587 uses STARTTLS (start with plain text, upgrade to TLS)
• Port 465 uses implicit TLS (TLS from the start)
• 587 is the modern standard, supported by all email clients
• You can enable 465 later if needed, but 587 is sufficient

Note about port 465: There’s a submissions section further down in master.cf. Leave it commented out for now. We’re only using port 587.

Save and exit: Ctrl+X, Y, Enter

Restart Postfix to enable the submission port:

sudo systemctl restart postfix

# Check for any errors
sudo systemctl status postfix

Verify port 587 is now listening:

sudo ss -tlnp | grep :587

Expected output:

LISTEN 0    100    0.0.0.0:587    0.0.0.0:*    users:(("master",pid=31782,fd=14))

Verify all three mail ports are listening:

sudo ss -tlnp | grep -E ':(25|587|993)'

Expected output:

LISTEN 0    100    0.0.0.0:25     0.0.0.0:*    users:(("master",pid=31782,fd=13))
LISTEN 0    100    0.0.0.0:587    0.0.0.0:*    users:(("master",pid=31782,fd=14))
LISTEN 0    100    0.0.0.0:993    0.0.0.0:*    users:(("dovecot",pid=31055,fd=37))

All three ports should show “LISTEN”.

Common issue: If port 587 doesn’t appear, check that you uncommented all the submission lines and that there are no syntax errors:

# Check for configuration errors
sudo postfix check

# View recent Postfix logs for errors
sudo journalctl -u postfix -n 30 --no-pager

Create Mail User and Test Reception

Now that Postfix and Dovecot are configured, create a user account and test that email actually works.

Create a system user for email:

# Create user (choose a username - we'll use "collin" as an example)
sudo adduser collin

You’ll be prompted for:

• Password (choose a strong one – you’ll use this to log into email)
• Full name (optional, press Enter to skip)
• Room number, phone, etc. (all optional, press Enter through these)
• Confirm: Y

Create the Maildir structure:

Even though Postfix will create Maildir automatically on first delivery, it’s better to create it now with correct permissions:

# Create Maildir for the user
sudo -u collin maildirmake.dovecot /home/collin/Maildir

# Verify it was created
sudo ls -la /home/collin/

# You should see: drwx------ Maildir/

Set proper permissions:

# Ensure ownership is correct
sudo chown -R collin:collin /home/collin/Maildir

# Ensure permissions are restrictive (only user can read)
sudo chmod -R 700 /home/collin/Maildir

# Verify
sudo ls -la /home/collin/Maildir/

Expected Maildir structure:

drwx------ 5 collin collin 4096 Feb 12 18:49 .
drwx------ 3 collin collin 4096 Feb 12 18:49 ..
drwx------ 2 collin collin 4096 Feb 12 18:49 cur
drwx------ 2 collin collin 4096 Feb 12 18:49 new
drwx------ 2 collin collin 4096 Feb 12 18:49 tmp

The three subdirectories:

• new/ – Unread messages
• cur/ – Read messages
• tmp/ – Temporary files during delivery

Send a test email from external provider:

Using Gmail, ProtonMail, or any other email account, send an email to:

collin@[your-domain].com

Subject: Test Email
Body: Testing my new mail server!

Wait 10-30 seconds for delivery, then check the logs:

# Watch for the delivery in real-time
sudo journalctl -u postfix -f

# Press Ctrl+C to stop watching

Or check recent entries:

# View last 50 Postfix log entries
sudo journalctl -u postfix -n 50 --no-pager

# Search specifically for delivered messages
sudo journalctl -u postfix --no-pager | grep -i delivered

Look for a line like:

postfix/local[32242]: 8AE4841E68: to=<collin@[your-domain].com>, relay=local, delay=0.18, delays=0.16/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)

The key part is status=sent (delivered to mailbox).

Check if the email file exists:

# List new mail
sudo ls -la /home/collin/Maildir/new/

# You should see a file with a name like:
# 1707683045.V801I12345M654321.mail

Read the email (optional):

# View the raw email
sudo cat /home/collin/Maildir/new/*

You’ll see the full email including all headers, which is useful for debugging.

Test IMAP access with an email client:

Now configure an email client to make sure IMAP works. Use any of these:

• Thunderbird (desktop)
• iOS Mail (iPhone/iPad)
• Android Gmail or K-9 Mail
• macOS Mail

IMAP Settings:

Server: mail.[your-domain].com
Port: 993
Connection security: SSL/TLS
Authentication: Normal password
Username: collin
Password: [the password you set for collin user]

SMTP Settings (for future sending):

Server: mail.[your-domain].com
Port: 587
Connection security: STARTTLS
Authentication: Normal password
Username: collin
Password: [the password you set for collin user]

In Thunderbird, for example:

1. Open Thunderbird
2. File → New → Existing Mail Account
3. Enter:
   • Your name: Your Name
   • Email address: collin@[your-domain].com
   • Password: [collin’s password]
4. Click “Configure manually”
5. Enter the IMAP and SMTP settings above
6. Click “Done”

You should:

• Connect successfully
• See your “Test Email” in the inbox
• Be able to read it

Common issues:

1. Email doesn’t arrive – check logs: # Check for errors or bounces sudo journalctl -u postfix -n 100 --no-pager | grep -i error # Check mail queue sudo mailq # Should be empty if mail was delivered
2. Email delivered to /var/mail/collin instead of Maildir: # Check traditional mailbox location sudo ls -la /var/mail/collin # If mail is there, Postfix isn't using Maildir # Verify main.cf has: home_mailbox = Maildir/ sudo grep "home_mailbox" /etc/postfix/main.cf # Restart Postfix if you changed anything sudo systemctl restart postfix
3. IMAP connection refused: # Verify Dovecot is running sudo systemctl status dovecot # Verify port 993 is listening sudo ss -tlnp | grep :993 # Check Dovecot logs for errors sudo journalctl -u dovecot -n 50 --no-pager
4. Authentication failed in email client: # Verify user exists id collin # Try testing authentication manually telnet localhost 143 # Type: a1 LOGIN collin password # Should return: a1 OK Logged in # Type: a2 LOGOUT
5. TLS/SSL errors: # Verify certificates are readable sudo ls -la /etc/letsencrypt/live/mail.[your-domain].com/ # Test TLS connection openssl s_client -connect mail.[your-domain].com:993 -quiet # Should show certificate chain and connect

If your email client connects and shows the test email, mail reception is fully working. You can now receive email on your domain and access it via IMAP from any device.

The Outbound Challenge

Email Reputation Reality

Your mail server can now receive email perfectly. Sending is where things get complicated.

The problem: Email providers (Gmail, Outlook, etc.) evaluate sender reputation based on:

1. IP reputation – Is this IP known to send spam?
2. Sending volume – Do they send enough mail to establish patterns?

Why VPS IPs struggle:

• Cloud provider IP ranges are constantly cycled by spammers
• If another DigitalOcean customer in your subnet sends spam, your IP can be blacklisted by association
• Personal mail servers send 5-10 emails/day, which isn’t enough volume for ML models to build trust

The solution: Use a commercial SMTP relay service with established IP pools and reputation. They handle deliverability; you handle learning mail infrastructure.

This isn’t defeat—it’s pragmatic architecture. You’re still running the full mail stack, just routing outbound through a reliable path.

AWS SES: Setup and Reality Check

Amazon Simple Email Service (SES) was our first choice for outbound relay due to its excellent deliverability and cost-effectiveness ($0.10 per 1,000 emails). Here’s what happened during setup.

Create or log into your AWS account:

Navigate to: https://console.aws.amazon.com/

Access the SES Console:

1. In the top search bar, type “SES”
2. Click Simple Email Service
3. Important: Check your region in the top-right corner
   • Choose: us-east-2 (Ohio) or us-east-1 (Virginia)
   • SES isn’t available in all regions
   • Remember which region you choose—use it consistently

Verify your domain:

1. In the SES dashboard, left sidebar → Verified identities
2. Click Create identity (orange button)
3. Select: Domain
4. Domain name: [your-domain].com (without mail. prefix)
5. Check these boxes:
   • ✅ Use a default DKIM signing key (RSA_2048_BIT)
   • ❌ Publish DNS records to Route 53 – UNCHECK (we’re using Cloudflare)
6. Click Create identity

You’ll see a verification screen with DNS records:

AWS generates three DKIM CNAME records. Copy each one to a text file:

[random-string-1]._domainkey.[your-domain].com → [value-1].dkim.amazonses.com
[random-string-2]._domainkey.[your-domain].com → [value-2].dkim.amazonses.com
[random-string-3]._domainkey.[your-domain].com → [value-3].dkim.amazonses.com

Plus a domain verification TXT record:

_amazonses.[your-domain].com → [verification-code]

Add DKIM records to Cloudflare:

Go to Cloudflare DNS → Add record (do this 3 times):

Type: CNAME
Name: [random-string-1]._domainkey
Target: [value-1].dkim.amazonses.com
Proxy: DNS only
TTL: Auto

Repeat for all three DKIM records. After 2-5 minutes, AWS will verify them and show “Successful” next to DKIM configuration.

Generate SMTP credentials:

These credentials allow Postfix to authenticate with SES as an SMTP relay.

1. SES Console → Left sidebar → SMTP settings
2. Click Create SMTP credentials
3. IAM User Name: Keep default (ses-smtp-user-[date]) or customize
4. Click Create user
5. Critical: Download or copy the credentials immediately:
   • SMTP username: (starts with AKIA…)
   • SMTP password: (long random string)
   • You cannot retrieve the password later!

Save these in a secure location (password manager). We’ll use them in Part 3 for SMTP2GO, or later when SES is approved.

Request production access:

By default, SES operates in “sandbox mode,” which only allows sending to verified email addresses. For real-world use (like job applications), you need production access.

1. SES Console → Left sidebar → Account dashboard
2. Look for Production access section
3. Click Request production access button

Fill out the form:

• Mail type: Transactional
• Website URL: https://[your-domain].com
• Use case description: Personal mail server for professional blog ([your-domain].com) and job application correspondence.Low volume (50-100 emails per month). Self-hosted Postfix MTA using SES as SMTP relay for reliable delivery.All mail is individual professional correspondence—no bulk sending or marketing.
• Describe how you will comply with AWS Service Terms: Monitor SES console daily for bounces and complaints. Remove invalid addresses immediately.Maintain low complaint rate. All recipients are legitimate contacts (job recruiters, blog readers who contacted me).
• Acknowledge compliance: Check the box
• Click Submit request

The response (24-48 hours later):

This is what AWS actually sent back:

Hello,

Thank you for submitting your request to increase your sending limits. We would like to gather more information about your use case.

[…]

Due to some limiting factors on your account currently, you are not eligible to send SES messages in US East (Ohio) region. You will need to show a pattern of use of other AWS services and a consistent paid billing history to gain access to this function.

We enforce these limitations on all new accounts. Your continued usage of other AWS services will give us greater flexibility to increase your spending limits in the future.

Please open a new case after you have a successful billing cycle and additional use of other AWS services and we will gladly review your account.

What this means:

AWS is being conservative with new accounts to prevent spammers. They want to see:

1. “Pattern of use of other AWS services” – Not just SES, but S3, Lambda, CloudWatch, etc.
2. “Consistent paid billing history” – At least 1-2 billing cycles ($2-10/month minimum)
3. Time – Proving you’re not a fly-by-night spam operation

This isn’t a permanent “no”—it’s “not yet, prove you’re legitimate first.”

This is frustrating but common. Many new AWS accounts experience this, especially for SES. The solution is to build up AWS usage over 60-90 days, then reapply with evidence of legitimate usage.

Why we’re not giving up on SES:

• Best long-term economics ($0.10/1000 emails vs $19.95/month for SendGrid at scale)
• Excellent deliverability when approved
• AWS experience is valuable for cybersecurity roles
• Learning AWS infrastructure is part of the project

The strategy:

1. Use SMTP2GO immediately (1,000 emails/month free tier) for projects and correspondence
2. Build AWS usage history with S3 backups (next section)
3. Optionally use Lambda, CloudWatch for additional AWS activity
4. After 60-90 days, reapply to SES with proof:
   • “I’ve been using S3 for automated backups for 3 months”
   • “Consistent billing history attached”
   • “Professional mail infrastructure in production”
5. Much higher approval odds the second time

This approach is both pragmatic (email works now via SMTP2GO) and strategic (positioning for SES approval later).

Building AWS Usage History: S3 Backups

The strategy to get SES approved: generate consistent AWS usage and billing history while also creating something useful. Automated mail backups to S3 accomplish both.

Benefits:

• Generates AWS billing (~$0.50-1/month)
• Shows regular service usage
• Actually protects your mail
• Positions you for SES approval in 60-90 days

Install AWS CLI v2:

The awscli package isn’t in Ubuntu 24.04 repositories. Install the official AWS CLI v2:

# Download the installer
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# Install unzip if not present
sudo apt install unzip -y

# Unzip the installer
unzip awscliv2.zip

# Run the installer
sudo ./aws/install

# Verify installation
aws --version
# Should show: aws-cli/2.x.x Python/3.x.x Linux/...

# Clean up
rm -rf aws awscliv2.zip

Create IAM user with S3 access:

Don’t use your root AWS account credentials. Create a dedicated IAM user for the mail server:

1. AWS Console → Search for IAM → Click IAM
2. Left sidebar → Users
3. Click Create user (orange button)
4. User name: mail-server-admin
5. Click Next

Set permissions:

1. Select Attach policies directly
2. Search for and select these policies:
   • ✅ AmazonS3FullAccess (for backups)
   • ✅ CloudWatchLogsFullAccess (optional, for future log monitoring)
   • ✅ AWSLambda_FullAccess (optional, for future automation)
3. Click Next
4. Review and click Create user

Create access keys for CLI access:

1. Click on the user you just created: mail-server-admin
2. Click Security credentials tab
3. Scroll down to Access keys section
4. Click Create access key
5. Select use case: Command Line Interface (CLI)
6. Check the confirmation checkbox: “I understand the above recommendation…”
7. Click Next
8. Description (optional): “Mail server backups and automation”
9. Click Create access key

Save your credentials:

You’ll see:

• Access key ID: AKIA… (20 characters)
• Secret access key: Long random string (40 characters)

Critical: Click Download .csv file and save it securely. You cannot view the secret again!

Copy both values to use in the next step.

Configure AWS CLI on your mail server:

# Run configuration wizard
aws configure

Enter when prompted:

AWS Access Key ID [None]: AKIA[your-key-here]
AWS Secret Access Key [None]: [your-secret-key-here]
Default region name [None]: us-east-2
Default output format [None]: json

Verify credentials work:

# Test authentication
aws sts get-caller-identity

Expected output:

{
    "UserId": "AIDA...",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/mail-server-admin"
}

If you see your account number and the mail-server-admin user, configuration is correct.

Create S3 bucket for backups:

Bucket names must be globally unique across all AWS accounts. Add a timestamp to ensure uniqueness:

# Create bucket (replace [your-domain] with your actual domain)
aws s3 mb s3://[your-domain]-mail-backups-$(date +%s)

# Example output:
# make_bucket: secblues-mail-backups-1707928699

Note the full bucket name (including the timestamp). You’ll need it for the backup script.

Verify bucket was created:

# List all your buckets
aws s3 ls

# Should show:
# 2026-02-12 20:38:22 [your-domain]-mail-backups-1707928699

Create backup script:

# Create the script file
sudo nano /usr/local/bin/backup-mail.sh

Paste this script (replace placeholders with your actual values):

#!/bin/bash

# Mail backup script for S3
# Backs up Maildir and mail configuration daily

BACKUP_DATE=$(date +%Y-%m-%d-%H%M%S)
BUCKET_NAME="[your-full-bucket-name-including-timestamp]"
MAIL_USER="[your-mail-username]"
BACKUP_DIR="/tmp/mail-backup-${BACKUP_DATE}"

# Create temporary backup directory
mkdir -p ${BACKUP_DIR}

# Backup Maildir (user's mail)
tar -czf ${BACKUP_DIR}/maildir-${BACKUP_DATE}.tar.gz \
    -C /home/${MAIL_USER} \
    Maildir/

# Backup mail server configuration
tar -czf ${BACKUP_DIR}/mail-config-${BACKUP_DATE}.tar.gz \
    /etc/postfix/main.cf \
    /etc/postfix/master.cf \
    /etc/dovecot/

# Upload Maildir backup to S3
aws s3 cp ${BACKUP_DIR}/maildir-${BACKUP_DATE}.tar.gz \
    s3://${BUCKET_NAME}/maildir/

# Upload config backup to S3
aws s3 cp ${BACKUP_DIR}/mail-config-${BACKUP_DATE}.tar.gz \
    s3://${BUCKET_NAME}/config/

# Cleanup temporary files
rm -rf ${BACKUP_DIR}

echo "Backup completed: ${BACKUP_DATE}"

What this script does:

• Creates timestamped backups of Maildir and configurations
• Compresses them with gzip
• Uploads to separate S3 folders (maildir/ and config/)
• Cleans up temporary files
• Logs completion

Save and exit: Ctrl+X, Y, Enter

Make the script executable:

# Set execute permission
sudo chmod +x /usr/local/bin/backup-mail.sh

# Verify permissions
ls -la /usr/local/bin/backup-mail.sh
# Should show: -rwxr-xr-x (executable)

Test the backup script:

# Run manually
sudo /usr/local/bin/backup-mail.sh

Expected output:

Backup completed: 2026-02-12-204716

Verify files were uploaded to S3:

# List all objects in bucket
aws s3 ls s3://[your-bucket-name]/ --recursive

Expected output:

2026-02-12 20:47:21   3529 maildir/maildir-2026-02-12-204716.tar.gz
2026-02-12 20:47:21  28314 config/mail-config-2026-02-12-204716.tar.gz

If you see both files, backups are working!

Schedule automatic daily backups with cron:

# Edit root's crontab
sudo crontab -e

If prompted to select an editor:

• Choose 1 for nano (easiest)

Add this line at the end:

# Daily mail backup at 2:00 AM
0 2 * * * /usr/local/bin/backup-mail.sh >> /var/log/mail-backup.log 2>&1

What this does:

• Runs backup script daily at 2:00 AM
• Logs output to /var/log/mail-backup.log
• 2>&1 captures both stdout and stderr

Save and exit: Ctrl+X, Y, Enter

Verify cron job was added:

# List crontab
sudo crontab -l

# Should show your backup line

Check cron service is running:

sudo systemctl status cron
# Should show: active (running)

Configure S3 lifecycle policy (auto-delete old backups):

Keep backups for 30 days, then automatically delete them to control costs:

# Create lifecycle policy file
cat > /tmp/lifecycle.json << 'EOF'
{
  "Rules": [
    {
      "Expiration": {
        "Days": 30
      },
      "ID": "DeleteOldBackups",
      "Status": "Enabled",
      "Prefix": ""
    }
  ]
}
EOF

# Apply policy to bucket
aws s3api put-bucket-lifecycle-configuration \
  --bucket [your-bucket-name] \
  --lifecycle-configuration file:///tmp/lifecycle.json

# Verify policy was applied
aws s3api get-bucket-lifecycle-configuration \
  --bucket [your-bucket-name]

Expected output:

{
    "Rules": [
        {
            "Expiration": {
                "Days": 30
            },
            "ID": "DeleteOldBackups",
            "Status": "Enabled",
            "Prefix": ""
        }
    ]
}

This keeps your S3 costs predictable—after 30 days, old backups are automatically deleted.

Cost estimation:

• S3 storage: $0.023/GB/month
• Estimated usage: 20GB (mail + configs, 30 days retention)
• Lifecycle policy: Automatically deletes after 30 days
• Monthly cost: ~$0.50-1.00

Small cost for AWS usage history plus actual backup protection.

What you’ve accomplished:

✅ AWS CLI configured and authenticated
✅ S3 bucket created
✅ Automated daily backups working
✅ 30-day retention policy
✅ AWS billing started (usage history building)
✅ Actual useful backup system

Timeline for SES:

• Month 1-2: S3 backups generate consistent usage
• Month 2-3: 2+ billing cycles complete
• Month 3: Reapply to SES with evidence: “3 months of S3 usage, consistent billing history”
• Expected: Much higher approval rate

Testing the backup:

The cron job runs daily at 2 AM. To test it now:

# Run backup manually
sudo /usr/local/bin/backup-mail.sh

# Check the log (will be created after first cron run)
tail /var/log/mail-backup.log

# Verify S3 has new files
aws s3 ls s3://[your-bucket-name]/ --recursive --human-readable

You should see increasing file counts daily.

Restoring from backup (if needed):

# List available backups
aws s3 ls s3://[your-bucket-name]/maildir/

# Download specific backup
aws s3 cp s3://[your-bucket-name]/maildir/maildir-2026-02-12-204716.tar.gz /tmp/

# Extract
cd /home/[username]
tar -xzf /tmp/maildir-2026-02-12-204716.tar.gz

# Verify mail restored
ls -la /home/[username]/Maildir/new/

Verification and Testing

Run through this comprehensive checklist to confirm everything is configured correctly.

System and Network Checks

Verify all ports are listening:

# Check all three mail ports at once
sudo ss -tlnp | grep -E ':(25|587|993)'

Expected output:

LISTEN 0    100    0.0.0.0:25     0.0.0.0:*    users:(("master",pid=31782,fd=13))
LISTEN 0    100    0.0.0.0:587    0.0.0.0:*    users:(("master",pid=31782,fd=14))
LISTEN 0    100    0.0.0.0:993    0.0.0.0:*    users:(("dovecot",pid=31055,fd=37))

All three should show “LISTEN”.

Verify firewall rules:

sudo ufw status verbose | grep -E '(25|587|993|80|443)'

Expected output:

25/tcp                     ALLOW IN    Anywhere
587/tcp                    ALLOW IN    Anywhere
993/tcp                    ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

DNS Verification

Re-verify all DNS records:

# A record
dig mail.[your-domain].com +short
# Should return: [your-droplet-ip]

# MX record
dig MX [your-domain].com +short
# Should return: 10 mail.[your-domain].com.

# SPF record
dig TXT [your-domain].com +short | grep spf
# Should include: "v=spf1 ip4:[your-ip] include:amazonses.com -all"

# DMARC record
dig TXT _dmarc.[your-domain].com +short
# Should return: "v=DMARC1; p=none; rua=mailto:dmarc@..."

# PTR record (reverse DNS)
dig -x [your-droplet-ip] +short
# Should return: mail.[your-domain].com.

If any fail, revisit the DNS configuration section.

Service Status Checks

Verify all services are running:

# Postfix status
sudo systemctl status postfix --no-pager -l

# Dovecot status
sudo systemctl status dovecot --no-pager -l

# Both should show: Active: active (running)

Check for errors in logs:

# Postfix errors
sudo journalctl -u postfix -n 100 --no-pager | grep -i error

# Dovecot errors
sudo journalctl -u dovecot -n 100 --no-pager | grep -i error

# If both return nothing, that's good - no errors

Postfix Configuration Checks

Verify Postfix is using Maildir:

sudo postconf | grep home_mailbox
# Should show: home_mailbox = Maildir/

Verify TLS certificates are configured:

sudo postconf | grep smtpd_tls_cert_file
sudo postconf | grep smtpd_tls_key_file

# Both should point to /etc/letsencrypt/live/mail.[your-domain].com/

Verify SASL is enabled:

sudo postconf | grep smtpd_sasl_auth_enable
# Should show: smtpd_sasl_auth_enable = yes

Dovecot Configuration Checks

Verify mail location:

sudo doveconf -n | grep mail_location
# Should show: mail_location = maildir:~/Maildir

Verify SSL is required:

sudo doveconf -n | grep "^ssl "
# Should show: ssl = required

Verify auth socket exists:

sudo ls -la /var/spool/postfix/private/auth
# Should show: srw-rw---- 1 postfix postfix

Email Delivery Test

Send test email from external provider:

From Gmail, ProtonMail, or any other email service, send to: [your-username]@[your-domain].com

Monitor delivery in real-time:

# Watch logs
sudo journalctl -u postfix -f

# Press Ctrl+C when you see the delivery

Verify delivery:

# Check for "delivered to mailbox"
sudo journalctl -u postfix --no-pager | grep "status=sent"

# Example output:
# status=sent (delivered to mailbox)

Verify email file exists:

# List new mail
sudo ls -la /home/[your-username]/Maildir/new/

# Should see a file with timestamp in name

IMAP Connection Test

Test with command-line:

# Test IMAP over SSL
openssl s_client -connect mail.[your-domain].com:993 -quiet

# After connection, type:
a1 LOGIN [username] [password]
# Should return: a1 OK Logged in

# List mailboxes
a2 LIST "" "*"
# Should show: * LIST (\HasNoChildren) "." "INBOX"

# Logout
a3 LOGOUT

Test with email client:

Configure any IMAP client with these settings and verify:

• Connection succeeds
• Test email appears in inbox
• Can read the email

Connection details:

IMAP:
  Server: mail.[your-domain].com
  Port: 993
  Security: SSL/TLS
  Username: [your-username]
  Password: [user's password]

SMTP (for future):
  Server: mail.[your-domain].com
  Port: 587
  Security: STARTTLS
  Username: [your-username]
  Password: [user's password]

AWS S3 Backup Verification

Verify backup script runs:

# Run manual backup
sudo /usr/local/bin/backup-mail.sh

# Check output
# Should show: Backup completed: [timestamp]

Verify files in S3:

# List all backups
aws s3 ls s3://[your-bucket-name]/ --recursive --human-readable

# Should show files in maildir/ and config/ folders

Verify cron job:

# Check crontab
sudo crontab -l | grep backup-mail

# Should show: 0 2 * * * /usr/local/bin/backup-mail.sh

Verify lifecycle policy:

# Check policy
aws s3api get-bucket-lifecycle-configuration \
  --bucket [your-bucket-name]

# Should show 30-day expiration rule

TLS Certificate Verification

Check certificate expiration:

# Check cert details
sudo certbot certificates

# Should show:
# Certificate Name: mail.[your-domain].com
# Expiry Date: [90 days from creation]
# Certificate Path: /etc/letsencrypt/live/mail.[your-domain].com/fullchain.pem

Verify auto-renewal:

# Check renewal timer
sudo systemctl status certbot.timer

# Should show: Active: active (waiting)

Test renewal process:

# Dry run (doesn't actually renew)
sudo certbot renew --dry-run

# Should end with: Congratulations, all simulations succeeded

Security Verification

Check file permissions on sensitive files:

# Maildir should be 700 (user-only access)
sudo ls -ld /home/[username]/Maildir
# Should show: drwx------

# Certificate private key should be 600
sudo ls -la /etc/letsencrypt/live/mail.[your-domain].com/privkey.pem
# Should show: -rw-r--r-- (lrwxrwxrwx if symlink)

# Postfix config should be 644
sudo ls -la /etc/postfix/main.cf
# Should show: -rw-r--r--

Verify no open relay:

# Test if server allows relaying without auth
telnet mail.[your-domain].com 25

# After connection, type:
HELO test.com
MAIL FROM: [email protected]
RCPT TO: [email protected]

# Should get: 554 5.7.1 Relay access denied
# This is GOOD - server refuses to relay

Final Checklist

Run through this checklist and verify each item:

• [ ] All ports listening (25, 587, 993)
• [ ] All DNS records verified (A, MX, SPF, DMARC, PTR)
• [ ] Postfix running without errors
• [ ] Dovecot running without errors
• [ ] TLS certificates valid and auto-renewing
• [ ] External email received successfully
• [ ] Email visible in Maildir
• [ ] IMAP client connection works
• [ ] Can read received email in client
• [ ] Auth socket exists and accessible
• [ ] S3 backups working
• [ ] Cron job scheduled
• [ ] AWS usage generating billing
• [ ] No open relay (relay access denied without auth)

If all items are checked, your mail server is fully operational for receiving email.

What’s working:

• Receiving email from any sender
• IMAP access from any email client
• TLS encryption throughout
• Automated backups
• AWS usage history building

What’s pending:

• Outbound relay configuration (Part 3: SMTP2GO)
• Spam filtering (Part 3: SpamAssassin)
• Additional security hardening (Part 3)
• AWS SES approval (60-90 days)

Conclusion

You’ve built a production-ready mail server from scratch. Let’s review what you’ve accomplished and what comes next.

What You’ve Built

Infrastructure:

• DigitalOcean droplet running Ubuntu 24.04 LTS
• Hardened firewall (UFW) with only necessary ports open
• TLS certificates from Let’s Encrypt with automatic renewal
• Complete DNS configuration (A, MX, SPF, DMARC, PTR)

Mail Services:

• Postfix: Receiving mail on port 25, submission on port 587
• Dovecot: IMAP access on port 993
• Maildir format: Each email as a separate file
• TLS encryption: All connections encrypted
• Authentication: Dovecot SASL integration with Postfix

Backup and AWS Integration:

• AWS CLI configured and authenticated
• S3 bucket for automated backups
• Daily backup script running via cron
• 30-day retention policy
• Consistent AWS usage generating billing history

Current Capabilities

Fully Functional:

• Receiving email: Anyone can send mail to [username]@[your-domain].com
• IMAP access: Connect from any email client (Thunderbird, iOS Mail, Android, etc.)
• Multiple devices: Access same mailbox from phone, laptop, tablet
• Encrypted connections: TLS for SMTP and IMAP
• Automated backups: Daily backups to S3
• Professional setup: Proper SPF, DMARC, PTR records

Pending Configuration:

• Sending email: Requires SMTP relay (Part 3)
• Spam filtering: SpamAssassin configuration (Part 3)
• Security hardening: fail2ban, additional restrictions (Part 3)
• Monitoring: Log analysis, alerting (Part 3)

Monthly Costs

Current expenses:

• DigitalOcean droplet (mail server): $6.00/month
• DigitalOcean droplet (WordPress, existing): $6.00/month
• AWS S3 backups: ~$0.50/month
• Total: ~$12.50/month

Cost breakdown by function:

• Receiving email: $6/month (droplet)
• Backup protection: $0.50/month (S3)
• AWS usage history: $0.50/month (S3, building toward SES)
• WordPress hosting: $6/month (existing)

Comparison to alternatives:

• Google Workspace: $6/user/month = $72/year (email only, no custom setup)
• Fastmail: $5/month = $60/year (email only)
• Your setup: $12.50/month = $150/year (email + blog + learning experience)

The AWS SES Situation

Current status: Production access denied due to new account

What we learned: AWS requires established usage history before approving SES for new accounts. This is common anti-spam policy, not a rejection of your use case.

The path forward:

1. Now – Month 2: S3 backups generate consistent AWS usage and billing
2. Month 2-3: Additional AWS services (optional: Lambda automation, CloudWatch logging)
3. Month 3: Reapply to SES with evidence:
   • “90 days of consistent S3 usage”
   • “3 billing cycles with charges”
   • “Professional mail infrastructure in production”
4. Expected outcome: Much higher approval rate

Why we’re not giving up on SES:

• Best long-term economics ($0.10/1,000 emails)
• Excellent deliverability
• AWS experience valuable for cybersecurity careers
• Natural fit with existing AWS infrastructure (S3 backups)

Timeline: 60-90 days until SES reapplication

What’s Next: Part 3 and Beyond

The next article will cover:

1. SMTP2GO SMTP Relay (Immediate Solution)

• Sign up for free tier (1,000 emails/month)
• Configure Postfix to relay via SMTP2GO
• Test outbound email delivery
• Verify deliverability to Gmail, Outlook, etc.

Why SMTP2GO:

• Works immediately (no waiting period)
• Free tier sufficient for personal use
• Proven deliverability
• Temporary until SES approval

2. SpamAssassin Configuration

• Install and configure spam filtering
• Bayesian learning
• Custom rules
• Integration with Dovecot

3. Security Hardening

• fail2ban for brute-force protection
• Rate limiting
• Additional Postfix restrictions
• Log monitoring
• Intrusion detection

4. Monitoring and Maintenance

• Log rotation
• Performance monitoring
• Disk usage alerts
• Backup verification
• Certificate renewal checks

Skills Acquired

Through this deployment, you’ve gained hands-on experience with:

Linux System Administration:

• User and permissions management
• Firewall configuration (UFW)
• Service management (systemd)
• Cron job automation
• Log analysis

Email Infrastructure:

• SMTP protocol and Postfix configuration
• IMAP protocol and Dovecot setup
• TLS certificate management
• DNS records (MX, A, SPF, DMARC, PTR)
• Maildir format and mail delivery

Cloud Infrastructure:

• AWS IAM user and policy management
• AWS CLI configuration
• S3 bucket creation and lifecycle policies
• Multi-cloud architecture (DO + AWS + Cloudflare)

Troubleshooting:

• Service debugging via journalctl
• DNS propagation issues
• Permission and socket configuration
• Log analysis and error resolution

Documentation for Future Reference

Key file locations:

Configuration Files:
/etc/postfix/main.cf          - Postfix main configuration
/etc/postfix/master.cf        - Postfix service configuration
/etc/dovecot/conf.d/          - Dovecot configuration directory
/etc/letsencrypt/live/        - TLS certificates
/usr/local/bin/backup-mail.sh - Backup script

Mail Data:
/home/[username]/Maildir/     - User mailbox
/var/spool/postfix/           - Postfix queue and sockets

Logs:
journalctl -u postfix         - Postfix logs
journalctl -u dovecot         - Dovecot logs
/var/log/mail-backup.log      - Backup logs (after first cron run)

AWS:
~/.aws/credentials            - AWS CLI credentials
~/.aws/config                 - AWS CLI configuration

Important commands:

# Service management
sudo systemctl restart postfix
sudo systemctl restart dovecot
sudo systemctl status postfix dovecot

# View logs
sudo journalctl -u postfix -f
sudo journalctl -u dovecot -n 100

# Check mail queue
sudo mailq

# Test configuration
sudo postfix check
sudo doveconf -n

# Manual backup
sudo /usr/local/bin/backup-mail.sh

# List S3 backups
aws s3 ls s3://[bucket-name]/ --recursive

Final Thoughts

Building a mail server is one of the more complex self-hosting projects, which is why many people avoid it. But you’ve done it the right way:

• Security-first: TLS, proper authentication, restricted permissions
• Properly configured: Following best practices for DNS, file permissions, service configuration
• Documented: Understanding why each component exists and how they interact
• Backed up: Automated protection for your data
• Pragmatic: Using commercial relay for deliverability while building toward full self-hosting

You now have a fully functional mail server that receives email reliably, integrates with any email client, and provides the foundation for complete email independence.

Part 3 will complete the picture by adding outbound sending capabilities and additional security layers, giving you a production-ready mail server suitable for professional correspondence.

Published:
Last updated:
Time to complete: 2-3 hours
Part of series: Building a Secure Email Server
Next: Part 3 – Outbound Relay, Spam Filtering, and Security Hardening

By Collin

Project Overview

Email infrastructure is one of the most complex yet fundamental services on the internet. Despite using email daily, most people—even many in tech—don’t understand how it actually works under the hood. SMTP, IMAP, DKIM, SPF, DMARC, spam filtering, TLS encryption, mail queues, DNS configurations… the list of interacting components is extensive.

This project aims to build a production-grade email server from scratch, not as a quick setup following a tutorial, but as a deep dive into email security, protocols, and infrastructure management. The goals are threefold:

1. Learn email security from the infrastructure side – understanding how authentication protocols (SPF/DKIM/DMARC) work, how spam filtering detects threats, how mail servers get compromised, and how to harden them.
2. Gain hands-on experience with production services – managing a real mail server with actual deliverability requirements (job applications, blog correspondence) forces you to understand reliability, monitoring, and troubleshooting in ways that lab environments don’t.
3. Document the process – turning the learning experience into comprehensive guides that help others understand not just the “how” but the “why” behind email infrastructure decisions.

The server will host email for secblues.com, providing a professional email address for professional and blog correspondence. This is real-world usage with real consequences if misconfigured—which makes it an excellent learning opportunity.

Why Build Your Own Mail Server in 2026?

It’s a fair question. Commercial email services like Google Workspace, Fastmail, and ProtonMail are reliable, secure, and cost-effective. Why take on the complexity of self-hosting?

The answer: learning. Running your own mail server teaches you:

• How email authentication prevents spoofing and phishing
• Why some emails go to spam (and how to fix it)
• How mail servers defend against abuse and attacks
• The practical implementation of cryptography (DKIM signing, TLS)
• DNS configuration beyond basic A records
• Log analysis and threat detection
• Incident response when things inevitably break

These are skills that translate directly to security operations, DevOps, and systems administration roles. You can’t learn them by using Gmail.

The Deployment Architecture

For this project, I’m deploying a hybrid architecture using DigitalOcean for hosting with AWS SES for outbound email relay. This combines self-hosted infrastructure for learning with commercial relay for reliable delivery.

Why hybrid instead of pure self-hosted?

The harsh reality of email reputation: even with perfect configuration (SPF, DKIM, DMARC, PTR records), small mail servers face two massive obstacles:

1. VPS IP reputation: Spammers constantly rotate through VPS IP ranges. If another customer in your /24 subnet sends spam, your IP can be blacklisted by association via services like UCEPROTECT-3.
2. The volume gap: Gmail and Outlook use sending volume as a trust signal. A personal server sending 5-10 emails per day never generates enough data for their machine learning models to establish trust. You remain in “unknown sender” territory indefinitely, which often defaults to the spam folder.

Building IP reputation takes months of consistent sending, and even then, there are no guarantees. For job applications and professional correspondence, this risk is unacceptable.

The hybrid solution:

Inbound (full learning experience):
  Internet → Your VPS (Postfix receives on port 25)
           → Spam filtering (SpamAssassin)
           → Storage (Dovecot/IMAP)
           → You (email clients via IMAP)

Outbound (reliable delivery):
  You → Your VPS (Postfix on port 587)
      → SMTP Relay (AWS SES)
      → Recipient (delivered from established IP)

What you still learn:

• Complete Postfix configuration (receiving, routing, queues, relay setup)
• Dovecot and IMAP protocols
• SPF/DKIM/DMARC implementation (still required for your domain)
• Spam filtering and content analysis
• Mail server security and hardening
• TLS configuration
• Log analysis and troubleshooting

What you outsource:

• IP reputation management for outbound delivery
• Deliverability monitoring and blacklist management
• Dealing with major providers’ spam filters

The deployment will run on Ubuntu 24.04 VPS with the following stack:

• Postfix for SMTP (receiving + relay to SES)
• Dovecot for IMAP (accessing mail from clients)
• SpamAssassin for spam filtering
• OpenDKIM for email signing
• AWS SES for outbound relay
• Let’s Encrypt for TLS certificates
• Roundcube for webmail (optional)

Now let’s examine why each of these components was chosen over alternatives.

Component Selection: Understanding the Tradeoffs

Building a mail server requires choosing between multiple competing implementations for each role. Here’s the decision-making process for each component, with comparisons to alternatives.

Mail Transfer Agent (MTA): The SMTP Server

Role: The MTA is the core of any mail server. It accepts incoming mail on port 25, sends outgoing mail to other servers, manages mail queues, and routes messages to local delivery agents.

Postfix ✓ (Recommended)

Homepage: https://www.postfix.org/

Postfix is the industry-standard MTA, originally written by Wietse Venema in the late 1990s as a secure alternative to Sendmail. It’s designed with security as the primary concern—the entire architecture is built around privilege separation and defense in depth.

Why Postfix:

• Security-first architecture: Runs as multiple processes with different privilege levels. If one component is compromised, the damage is contained by the privilege separation model.
• Industry standard: Most widely deployed MTA in production environments. What you learn applies directly to enterprise mail infrastructure.
• Excellent documentation: Decades of deployment experience means extensive guides, troubleshooting resources, and community knowledge.
• Modular integration: Easy to add spam filters, virus scanners, content filters, and authentication mechanisms.
• Performance: Efficiently handles high volume while remaining resource-efficient for small deployments.
• Active maintenance: Regular security updates and active development community.

Logging and troubleshooting: Postfix has exceptional logging. Every mail transaction is logged with clear, parseable messages that make troubleshooting straightforward. For a learning project, this is invaluable.

Alternatives Comparison

Verdict: Postfix offers the best balance of security, documentation, industry relevance, and learning value. Exim is a solid alternative if you’re already in Debian ecosystem. OpenSMTPD is interesting for security purists but has less industry adoption. The skills you develop configuring Postfix transfer directly to most professional environments.

IMAP/POP3 Server: Mail Access

Role: While the MTA handles mail transport, users need a way to access their mailboxes. The IMAP server stores mail and provides access for email clients (phones, desktop apps, webmail).

Dovecot ✓ (Recommended)

Homepage: https://www.dovecot.org/

Dovecot is the de facto standard IMAP/POP3 server, designed specifically for high performance and security. It pairs naturally with Postfix—the two projects evolved together and are commonly deployed as a matched set.

Why Dovecot:

• Performance: Optimized for efficiency with intelligent indexing and caching. Fast even with large mailboxes.
• Security: Solid track record, supports all modern authentication mechanisms (including 2FA integration).
• Standards compliance: Excellent implementation of IMAP protocol, handles edge cases properly.
• Integration: Standard pairing with Postfix, well-documented configuration patterns.
• Features: Sieve mail filtering, full-text search, quota management, virtual users.
• Flexibility: Supports multiple storage formats (maildir, mbox) and authentication backends.

Learning value: Understanding Dovecot teaches you how email storage works, authentication mechanisms, and the IMAP protocol’s capabilities and limitations.

Alternatives Comparison

Verdict: Dovecot is the clear choice for modern mail servers under 1000 users. It’s what you’ll encounter in most professional environments, and the Postfix+Dovecot pairing is well-tested and extensively documented. Cyrus is only worth considering if you’re building infrastructure for a large organization or need specific enterprise features like clustering.

Spam Filtering: Defending Your Inbox

Role: Spam filtering analyzes incoming mail and determines whether it’s legitimate or junk. This is critical for both usability (clean inbox) and security (blocking phishing attempts).

SpamAssassin ✓ (Recommended for Learning)

Homepage: https://spamassassin.apache.org/

SpamAssassin is a mature, rule-based spam filter that scores emails based on hundreds of heuristics. It’s been the standard open-source spam solution since 2001.

Why SpamAssassin:

• Transparent scoring: Every email gets a detailed score breakdown showing which rules triggered. This is invaluable for learning how spam detection works.
• Highly configurable: Extensive rule sets you can customize and audit. You understand exactly why mail was classified as spam.
• Bayesian learning: Can be trained on your mail to improve accuracy over time.
• Integration: Standard content filter for Postfix, well-documented setup.
• Educational value: Reading SpamAssassin rules teaches you spam techniques and detection methods.

Example scoring output:

X-Spam-Status: Yes, score=8.2 required=5.0
  tests=BAYES_99,HTML_MESSAGE,MIME_HTML_ONLY,RCVD_IN_BRBL_LASTEXT,
  RCVD_IN_XBL,URIBL_BLACK

You can see exactly why the mail was flagged (HTML-only, blacklisted sender IP, URL in known spam database).

rspamd (Alternative for Production)

Homepage: https://rspamd.com/

rspamd is the modern alternative to SpamAssassin—faster, more accurate, and feature-rich.

Why rspamd:

• Performance: Significantly faster than SpamAssassin, uses Redis for caching.
• Machine learning: Neural network classification and statistical learning.
• All-in-one: Includes DKIM signing/verification, greylisting, rate limiting, and more.
• Modern architecture: Asynchronous, event-driven design.

Tradeoff: rspamd is less transparent about scoring. It works better but teaches you less about spam detection techniques.

Alternatives Comparison

Recommendation for this project: Start with SpamAssassin to learn spam filtering fundamentals. The transparent scoring teaches you how spam detection actually works – you can see exactly which rules triggered and why. After understanding the principles, consider migrating to rspamd for better performance.

Article angle: Document both. Show SpamAssassin setup and detailed rule analysis, then migration to rspamd, explaining what you learned from each approach.

Email Authentication: DKIM Signing

Role: DKIM (DomainKeys Identified Mail) cryptographically signs outbound email, allowing recipients to verify the message came from your domain and wasn’t altered in transit.

OpenDKIM ✓ (Recommended)

Homepage: http://www.opendkim.org/

OpenDKIM is the standard open-source implementation of DKIM signing and verification.

Why OpenDKIM:

• Postfix integration: Standard milter (mail filter) interface, well-documented.
• Simple: Does one job well—signs outgoing mail, verifies incoming signatures.
• Debugging tools: Includes utilities to test and validate signatures.
• Widely deployed: Industry standard implementation you’ll encounter in production.

How it works: OpenDKIM signs outgoing mail with your private key, and publishes your public key in DNS. Recipients verify the signature using the public key, confirming the mail came from your domain.

Alternatives

The reality is that OpenDKIM is the standard implementation. The only alternative worth mentioning:

• rspamd built-in DKIM (https://rspamd.com/): If you’re using rspamd for spam filtering, it includes DKIM signing and verification. This eliminates the need for a separate OpenDKIM daemon and reduces moving parts.

Verdict: Use OpenDKIM if running the Postfix+SpamAssassin stack. If you’re using rspamd, use its built-in DKIM functionality to keep your architecture simpler.

SMTP Relay: Reliable Outbound Delivery

Role: Accepts mail from your server and delivers it to recipients using established IP addresses with proven reputation. This solves the deliverability problem that plagues small self-hosted mail servers.

Why Use an SMTP Relay?

The harsh reality of email reputation:

Even with perfect technical configuration (SPF, DKIM, DMARC, PTR records), self-hosted mail servers face two significant obstacles:

1. VPS IP reputation: Cloud provider IP ranges are constantly cycled by spammers. If another customer in your subnet sends spam, your IP can be blacklisted by association through services like UCEPROTECT-3 or Spamhaus. You have no control over your “neighbors.”
2. Volume-based trust: Gmail, Outlook, and other major providers use sending volume as a trust signal. A personal server sending 5-10 emails per day doesn’t generate enough data for their machine learning models to establish trust. Low-volume senders often remain in “unknown/neutral” status indefinitely, which frequently defaults to spam folder placement.

Building IP reputation can take months of consistent sending, with no guarantee of success. For professional correspondence and job applications, this uncertainty is unacceptable.

How SMTP relay solves this: Relay services maintain large pools of IP addresses with established reputations. They handle deliverability monitoring, blacklist management, and relationships with major email providers. Your mail is delivered from their trusted IPs while still being signed by your domain.

Amazon SES ✓ (Recommended)

Homepage: https://aws.amazon.com/ses/

Amazon Simple Email Service is AWS’s managed email platform, designed for both transactional and marketing email at any scale.

Why Amazon SES:

• Best economics at any scale: $0.10 per 1,000 emails after free tier
  • 10,000 emails/month = $1.00
  • 50,000 emails/month = $5.00
  • No minimum fee, pure pay-per-use
• AWS ecosystem integration: Learn AWS services (IAM, CloudWatch, SNS)
• Experience value: “Configured AWS SES integration” demonstrates cloud platform experience
• Excellent deliverability: Amazon’s reputation and infrastructure
• Detailed analytics: Bounce tracking, complaint monitoring, delivery metrics
• Scalability: Grows from personal use to enterprise without migration

Setup complexity: Moderate

• AWS account verification (24-48 hour wait for production access)
• IAM user creation and access key management
• SMTP credentials generation
• Learning AWS console navigation

Cost example for personal use:

• 0-3,000 emails/month (job apps + blog): ~$0.30/month
• Essentially free compared to VPS costs

Alternatives Comparison

Recommendation for this project: Amazon SES (long-term target)

• Best long-term economics (matters if blog grows)
• AWS experience is valuable for cybersecurity roles
• More interesting article content (AWS integration)
• Scales without migration or pricing cliffs

Immediate relay while waiting for SES approval: SMTP2GO

• 15-minute setup, 1,000 emails/month free tier
• Free tier doesn’t lock personal accounts (unlike SendGrid — see Part 3 for the full story)
• Same Postfix relay configuration as any other provider — can migrate to SES later with a two-line config change

Setup time comparison:

• SendGrid: 15 minutes (API key, configure Postfix, done)
• Mailgun: 20 minutes (similar to SendGrid)
• Amazon SES: 1-2 hours initial setup + 24-48 hour verification wait
• SMTP2GO: 15 minutes
• Postmark: 20 minutes (but costs money immediately)

Why not just use SES for everything (inbound + outbound)?

You could configure SES to receive mail, but then you’d:

• Lose all the learning about Postfix, Dovecot, spam filtering
• Have to build custom tooling for mail access (no standard IMAP)
• Miss the entire point of this project (understanding mail infrastructure)

SES for outbound relay gives you reliable delivery while preserving the learning experience.

TLS Certificates: Encrypting Connections

Role: TLS certificates encrypt SMTP and IMAP connections, preventing eavesdropping on email content and credentials.

Let’s Encrypt + Certbot ✓ (Recommended)

Homepage: https://letsencrypt.org/ and https://certbot.eff.org/

Let’s Encrypt revolutionized TLS by providing free, automated certificates trusted by all major clients.

Why Let’s Encrypt:

• Free: No cost for certificates that would cost $50-200/year from commercial CAs.
• Automated renewal: Certbot handles the entire lifecycle—request, install, renew.
• Trusted: Certificates are trusted by all email clients, browsers, and operating systems.
• Learning value: Understand the ACME protocol, certificate management, and PKI concepts.
• Industry standard: Same technology securing most of the web.

Certbot automation:

# Initial certificate
certbot certonly --standalone -d mail.secblues.com

# Automatic renewal (runs twice daily via systemd timer)
systemctl status certbot.timer

Alternatives Comparison

Verdict: Let’s Encrypt is the standard choice. Free, automated, and trusted by all email clients. ZeroSSL and Buypass are viable alternatives if you want CA diversity or encounter Let’s Encrypt rate limits, but offer no compelling advantage for a typical mail server deployment.

Webmail Interface (Optional)

Role: Provides browser-based access to email without configuring an IMAP client. Useful for accessing mail from untrusted computers or as a backup access method.

Note: Webmail is optional. Native email clients (iOS Mail, Thunderbird, K-9 Mail) provide better user experience and offline access.

Roundcube ✓ (Recommended)

Homepage: https://roundcube.net/

Roundcube is a relatively modern, feature-complete webmail client with a clean interface and active development.

Why Roundcube:

• Modern UI: Clean, responsive design similar to Gmail.
• Feature-complete: Rich text editing, contacts, calendar (via plugins), threaded conversations.
• Active development: Regular updates, security patches, new features.
• Plugin ecosystem: Extensible with hundreds of community plugins.
• Lightweight: PHP-based, runs efficiently on the same server.

Alternatives Comparison

Verdict: Roundcube for reliability, extensive plugin ecosystem, and community support. Snappymail if you prioritize modern UI and performance. SOGo only if you need full groupware features.

Honest assessment: For day-to-day use, native email clients (iOS Mail, Thunderbird, K-9 Mail) provide superior experience and offline access. Webmail is best for:

• Emergency access from untrusted computers
• Administrative tasks (checking spam folders, bulk operations)
• Demonstrating your setup to others
• Quick checks when you don’t have your devices

Web Server (for Webmail)

Role: Serves the webmail interface over HTTPS.

Nginx ✓ (Recommended)

Homepage: https://nginx.org/

Since you’re already running Nginx for your WordPress blog, using it for webmail eliminates an additional dependency.

Why Nginx:

• Already deployed: No additional service to manage.
• Performance: Excellent for serving PHP applications via PHP-FPM.
• Security: Strong track record, regular updates, good defaults.
• Reverse proxy: Can easily proxy to additional services later.
• Documentation: Extensive guides for PHP application deployment.

Alternatives Comparison

Verdict: Nginx since you’re already using it for your WordPress blog. Apache is equally valid if you prefer its ecosystem or need .htaccess support. Caddy is interesting for greenfield projects but less common in production mail server deployments.

Operating System Choice

Ubuntu 24.04 LTS is the foundation for this deployment. Here’s why:

Why Ubuntu:

• Long-term support: 5 years of security updates (until 2029).
• Up-to-date packages: Recent versions of Postfix, Dovecot, and other components.
• Documentation: Extensive community guides for mail server deployment.
• Stability: Proven in production environments, good testing before release.
• Package management: APT ecosystem is mature and well-maintained.

Alternatives:

• Debian Stable: More conservative (older packages), longer support cycle, excellent stability.
• Rocky Linux / AlmaLinux: RHEL-compatible, good for enterprise environments using RPM packages.
• FreeBSD: Excellent security, performance, and documentation, but smaller community for mail server guides.

Verdict: Ubuntu LTS offers the best balance of current packages and long-term support for a learning project.

The Complete Stack

Bringing it all together, here’s the recommended component stack with justifications:

Hybrid Architecture Stack:

Operating System: Ubuntu 24.04 LTS
  └─ Long-term support (5 years), current packages, extensive documentation

MTA: Postfix
  └─ Industry standard, security-first design, excellent logging
  └─ Configured for: receiving mail (port 25) + relay to SES (port 587)

IMAP: Dovecot
  └─ Standard pairing with Postfix, high performance, feature-complete

Spam Filter: SpamAssassin
  └─ Transparent scoring for learning, migrate to rspamd later for production

DKIM: OpenDKIM
  └─ Standard implementation, simple configuration

SMTP Relay: Amazon SES
  └─ Reliable outbound delivery, AWS experience, best long-term economics
  └─ Solves IP reputation and deliverability challenges

TLS: Let's Encrypt + Certbot
  └─ Free, automated, trusted certificates

Web Server: Nginx
  └─ Already deployed for WordPress, efficient, good PHP support

Webmail: Roundcube (optional)
  └─ Modern interface, active development, good feature set

DNS: Cloudflare
  └─ Free DNS, good UI for mail-specific records (MX, SPF, DKIM)

Hosting: DigitalOcean Droplet
  └─ Predictable pricing, simple management, good for learning

Monthly cost breakdown:

• DigitalOcean droplet (mail server): $6/month
• DigitalOcean droplet (WordPress blog): $6/month (already paying)
• Amazon SES (outbound relay): ~$0.10-0.30/month (negligible)
• Total: ~$12/month (~$6/month incremental over existing blog)

Experienced Gained:

• Complete mail server administration (Postfix, Dovecot, spam filtering)
• Email authentication protocols (SPF, DKIM, DMARC)
• SMTP relay integration (hybrid cloud architecture)
• AWS services (SES, potentially S3 for backups)
• TLS configuration and certificate management
• Security hardening and monitoring
• Multi-cloud architecture patterns

What you outsource:

• IP reputation management for outbound delivery
• Deliverability monitoring at scale
• Dealing with major email provider spam filters

Alternative Stack: The Modern Performance Approach

For comparison, here’s what a performance-optimized stack looks like:

Modern Performance Stack (still hybrid):

MTA: Postfix (unchanged - still the best)
IMAP: Dovecot (unchanged - still the best)
Spam/Auth/Signing: rspamd (replaces SpamAssassin + OpenDKIM)
  └─ Faster, ML-based, all-in-one solution (DKIM built-in)
Caching: Redis
  └─ Required for rspamd, improves performance significantly
SMTP Relay: Amazon SES (unchanged - still needed for deliverability)
TLS: Let's Encrypt (unchanged)
Web Server: Nginx (unchanged)
Webmail: Snappymail
  └─ Modern UI, lightweight, faster than Roundcube

Tradeoff: Better performance and modern architecture, but less educational transparency. You won’t learn as much about spam filtering rules or DKIM internals because rspamd abstracts them behind ML models and integrated functionality.

Recommendation: Start with the learning stack (SpamAssassin/OpenDKIM), migrate to the performance stack (rspamd) once you understand the fundamentals. Document both in your article series to show you understand the evolution from traditional to modern approaches.

Note on IP reputation: Even the performance stack uses SMTP relay (SES) for outbound delivery. The IP reputation problem affects all small self-hosted servers regardless of which spam filter you use. The relay is not a “learning wheels” component—it’s a pragmatic solution to a real infrastructure challenge.

What to Explicitly Avoid

Turnkey solutions (Mail-in-a-Box, MailCow, iRedMail):

These all-in-one Docker stacks or installer scripts set up a complete mail server in minutes. While they work well for “just get me email,” they defeat the learning purpose:

• Mail-in-a-Box (https://mailinabox.email/): Excellent turnkey solution, but you learn almost nothing about how email works.
• MailCow (https://mailcow.email/): Modern Docker-based stack, well-maintained, but opaque configuration.
• iRedMail (https://www.iredmail.org/): Comprehensive installer, supports multiple Linux distributions, but automated setup teaches you little.

When to use them: Production deployments where time is more valuable than learning. Or as reference implementations to see how components should integrate.

When to avoid them: Learning projects like this one. Build it manually to understand each piece.

Further Reading and Resources

Official Documentation

• Postfix Documentation: http://www.postfix.org/documentation.html
  • The authoritative reference, well-written and comprehensive
• Dovecot Wiki: https://doc.dovecot.org/
  • Excellent configuration examples and troubleshooting guides
• SpamAssassin Wiki: https://wiki.apache.org/spamassassin/
  • Detailed rule explanations and training guides

Email Protocol Standards (RFCs)

• RFC 5321 – SMTP: https://www.rfc-editor.org/rfc/rfc5321
  • The SMTP protocol specification
• RFC 3501 – IMAP: https://www.rfc-editor.org/rfc/rfc3501
  • IMAP protocol details
• RFC 6376 – DKIM: https://www.rfc-editor.org/rfc/rfc6376
  • DKIM signing and verification
• RFC 7208 – SPF: https://www.rfc-editor.org/rfc/rfc7208
  • Sender Policy Framework
• RFC 7489 – DMARC: https://www.rfc-editor.org/rfc/rfc7489
  • Domain-based Message Authentication, Reporting & Conformance

Security Hardening Guides

• NSA Email Server Security Guide: https://media.defense.gov/2023/Sep/12/2003299662/-1/-1/0/CTR_NSA_MAIL_SERVER_HARDENING.PDF
  • Comprehensive security recommendations from the NSA
• CIS Benchmark for Mail Servers: https://www.cisecurity.org/benchmark/mail_servers
  • Industry-standard security baselines

Deliverability and Reputation

• Google Postmaster Tools: https://postmaster.google.com/
  • Monitor your domain’s reputation with Gmail
• Microsoft SNDS: https://sendersupport.olc.protection.outlook.com/snds/
  • Check your IP reputation with Outlook/Hotmail
• MXToolbox: https://mxtoolbox.com/
  • Test DNS records, check blacklists, verify configuration

SMTP Relay Services

• Amazon SES Documentation: https://docs.aws.amazon.com/ses/
  • Official AWS SES documentation and integration guides
• SendGrid Documentation: https://docs.sendgrid.com/
  • SendGrid API and SMTP relay documentation
• Mailgun Documentation: https://documentation.mailgun.com/
  • Mailgun API and integration guides
• Email Service Provider Comparison: https://postmarkapp.com/compare
  • Independent comparison of major email sending services

Community Resources

• r/selfhosted: https://www.reddit.com/r/selfhosted/
  • Community discussions on self-hosting (including mail servers)
• Postfix Users Mailing List: http://www.postfix.org/lists.html
  • Active community for Postfix questions
• Server Fault: https://serverfault.com/questions/tagged/postfix
  • Q&A for mail server administration

Books

• “The Book of Postfix” by Ralf Hildebrandt and Patrick Koetter
  • Comprehensive guide to Postfix administration
• “Postfix: The Definitive Guide” by Kyle D. Dent
  • In-depth coverage of Postfix configuration and troubleshooting

Testing and Validation Tools

• mail-tester.com: https://www.mail-tester.com/
  • Test your outbound mail configuration and spam score
• MX Toolbox DMARC Analyzer: https://mxtoolbox.com/dmarc.aspx
  • Validate DMARC records
• DKIM Validator: https://dkimvalidator.com/
  • Test DKIM signing

Next Steps

Now that we’ve justified the component choices, the next article in this series will cover the actual deployment:

1. Initial server setup and hardening (SSH, firewall, updates)
2. Postfix installation and configuration (SMTP receiving + relay configuration)
3. AWS SES setup (account verification, SMTP credentials, relay integration)
4. Dovecot setup (IMAP access)
5. DNS configuration (MX, SPF, DKIM, DMARC records)
6. Spam filtering (SpamAssassin integration)
7. TLS encryption (Let’s Encrypt certificates)
8. Testing and validation (deliverability checks, relay verification)
9. Monitoring and maintenance (log analysis, queue management, performance monitoring)

The deployment will follow security best practices from the start—there’s no point in learning how to build an insecure mail server only to harden it later. The hybrid architecture (self-hosted receiving with SES relay for sending) will be configured from the beginning, ensuring reliable delivery for professional correspondence while maintaining the full learning experience.

Conclusion

Email infrastructure is more complex than it appears. Each component serves a specific purpose, and the interactions between them create the complete system. Understanding why we choose Postfix over alternatives, SpamAssassin over rspamd initially, or a hybrid architecture over pure self-hosted is more valuable than just following installation commands.

The hybrid approach—self-hosting for learning while using commercial relay for deliverability—reflects real-world engineering tradeoffs. It acknowledges that:

• IP reputation is a genuine infrastructure challenge, not a configuration problem
• Professional deliverability matters when using email for job applications
• Learning value comes from running the full stack, even if outbound goes through a relay
• Multi-cloud architecture is increasingly common in production environments

These decisions reflect the tension between idealism and pragmatism. A purely self-hosted mail server is educational but risks poor deliverability. A fully managed service is reliable but teaches nothing. The hybrid approach captures the learning value while ensuring the infrastructure actually works for its intended purpose.

By documenting the reasoning behind each choice, you build transferable knowledge that applies beyond this specific deployment. You’ll understand when to use traditional MTAs vs managed services, when spam filtering transparency matters vs performance, and when to self-host vs outsource. These are the engineering judgment skills that separate following tutorials from building production systems.

The next article will put these components into action, building a secure, functional mail server with reliable delivery from day one.

This is Part 1 of the “The Mailroom” email server build series.

Published: 12/25