Running a Private Email Server on a VPS: Complete 2025 Guide

Why Run Email on a VPS?

The case for a self-hosted VPS email server comes down to three things: control, privacy, and economics at scale.

Control is the most immediate benefit. When you run your own mail server, you set the retention policies. You choose what gets logged and what doesn't. You decide which TLS cipher suites are acceptable. You control access lists, delivery rules, and filtering behaviour. Nothing is dictated by a provider's feature roadmap or their interpretation of acceptable use. If a regulatory body issues a takedown or data request, it comes to you directly — not to a third party that may comply silently.

Privacy follows from control. A self-hosted VPS email server means your messages are never stored on infrastructure shared with other organisations or individuals whose security posture you can't assess. You are not subject to a provider's data-sharing arrangements with partners or advertisers. For journalists, lawyers, security researchers, and privacy advocates, this distinction is substantive rather than theoretical.

Cost at scale is often underestimated. Commercial email providers price per mailbox. If you're managing email for a team of 50, or running a high-volume transactional sender, the per-seat costs compound quickly. A single well-specified VPS can serve dozens of mailboxes at a flat infrastructure cost. Once you factor in the operational time required to maintain it, the calculation is more nuanced — but for technically capable teams, the economics can work decisively in favour of self-hosting.

That said, this guide is written honestly. VPS email is not the right answer for everyone. The setup is real work. The maintenance is ongoing. We'll return to that at the end.

Requirements and What You Need

Before provisioning anything, it's worth being specific about what a VPS email server actually requires. Underspecifying here is the most common reason that self-hosted email setups fail or perform poorly.

Minimum VPS specifications:

• RAM: 2 GB minimum. In practice, Postfix, Dovecot, and SpamAssassin running simultaneously will push close to this limit. If you add Rspamd with Redis, a full-text search index, or a webmail interface like Roundcube, 4 GB is a more comfortable floor. Plan for what you'll actually run, not just what can technically start.
• vCPUs: 2 minimum. Spam filtering is CPU-intensive, and IMAP connections require concurrent processing. A single vCPU will create visible latency during peak load.
• Storage: Depends on your mailbox volume and retention period, but 40 GB of SSD storage is a sensible starting point for a small deployment. Factor in mail queue growth during outages, log retention, and search indices.
• Network: A static IPv4 address is non-negotiable. Dynamic IPs are broadly blacklisted. Confirm your VPS provider assigns static IPs, and verify upfront whether outbound port 25 (SMTP) is unblocked — many consumer-grade VPS providers block it by default to prevent spam abuse.
• Clean IP reputation: The IP address assigned to your VPS has a history before you get it. Check it against the major blocklists — Spamhaus ZEN, Barracuda, and SORBS — before you configure a single DNS record. A dirty IP means your mail goes to spam from day one regardless of how well everything else is set up.
• Reverse DNS (rDNS): Your VPS provider must allow you to set a custom PTR record for your IP. The PTR record should resolve to your mail hostname (e.g., mail.yourdomain.com), and that hostname must forward-resolve back to the same IP. Receiving mail servers check this. Without it, your email will be rejected or heavily penalised.

Choosing the Right VPS

For a private email server, jurisdiction is not a minor consideration — it determines which legal frameworks govern your data. EU-based hosting places your infrastructure under GDPR and, depending on the country, additional data protection law. This matters if you're hosting email for any purpose where regulatory compliance is relevant.

Beyond jurisdiction, the underlying hardware architecture affects performance in ways that matter for mail servers. SMTP processing, spam scoring, and IMAP search all benefit from strong single-thread performance and high memory bandwidth. Modern EPYC-based VPS infrastructure provides both in abundance: AMD's server-grade EPYC processors deliver substantial per-core performance with multi-channel memory access, which translates directly to faster mail queue processing and more responsive IMAP connections.

For this guide's setup, we recommend the EPYC VPS range from Evolushost. They offer AMD EPYC-based virtual machines provisioned in EU data centres, with static IPs, rDNS control, and outbound port 25 available on request. The hardware specification is appropriate for a serious mail server deployment, not just a demonstration environment. The 2 GB and 4 GB tiers provide the right balance of RAM, vCPU, and storage for the stack described in this guide.

When evaluating any VPS provider for email hosting, check these criteria specifically:

• Can you set a custom PTR/rDNS record for your IP?
• Is outbound port 25 unblocked, or can it be enabled?
• Is the VPS located in a jurisdiction with strong data protection law?
• Are IP addresses static and dedicated (not shared with other tenants)?
• What is the provider's policy on IP reputation and abuse complaints?

Evolushost's EPYC VPS plans meet all of these criteria and are provisioned within the EU, making them a practical starting point for this guide.

Step 1 — Provision Your VPS: SSH, UFW, and Fail2ban

Once your VPS is provisioned, the first priority is hardening the base system before you install any mail software. A fresh Ubuntu 22.04 LTS installation exposed to the internet will see scanning and brute-force attempts within minutes.

SSH key authentication: Disable password authentication for SSH immediately. Add your public key to ~/.ssh/authorized_keys, then edit /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Restart the SSH service after saving: systemctl restart ssh. Do not close your existing session until you have confirmed key authentication works in a second terminal.

UFW firewall: Install and configure UFW to allow only the ports your mail stack requires:

apt install ufw

ufw default deny incoming
ufw default allow outgoing

# SSH
ufw allow 22/tcp

# SMTP (receiving mail from other servers)
ufw allow 25/tcp

# SMTPS (submission with TLS — for mail clients)
ufw allow 465/tcp

# SMTP submission (STARTTLS — for mail clients)
ufw allow 587/tcp

# IMAPS (encrypted IMAP for mail clients)
ufw allow 993/tcp

# HTTP/HTTPS (for Let's Encrypt certificate issuance)
ufw allow 80/tcp
ufw allow 443/tcp

ufw enable

Fail2ban: Install Fail2ban to automatically block IP addresses that make repeated failed authentication attempts. This is essential for a publicly accessible mail server — without it, your logs will fill with brute-force attempts and eventually a credential will be compromised.

apt install fail2ban

# Create a local override configuration
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edit /etc/fail2ban/jail.local to enable jails for SSH, Postfix, and Dovecot:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true

[postfix]
enabled = true

[dovecot]
enabled = true

Enable and start Fail2ban: systemctl enable --now fail2ban. Review fail2ban-client status periodically to confirm it is operating.

Step 2 — Install Postfix (MTA)

Postfix is the Mail Transfer Agent — the software that receives incoming messages from other mail servers via SMTP and routes outgoing messages from your mailboxes to their destinations. It is the core of your mail stack.

apt install postfix postfix-utils

During installation, select "Internet Site" and enter your fully qualified domain name (e.g., mail.yourdomain.com). After installation, the primary configuration file is /etc/postfix/main.cf. The critical settings to verify and configure:

# Your mail server's hostname — must match your rDNS PTR record
myhostname = mail.yourdomain.com

# Your domain
mydomain = yourdomain.com

# The domain used in outgoing mail's From addresses
myorigin = $mydomain

# Networks allowed to relay mail without authentication
# Keep this tight — localhost only unless you have specific requirements
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

# Where to deliver local mail
home_mailbox = Maildir/

# Disable the VRFY command (prevents user enumeration)
disable_vrfy_command = yes

# Require HELO from connecting servers
smtpd_helo_required = yes

The mynetworks setting is the most security-critical line in your Postfix configuration. If it is set too broadly, your server becomes an open relay and will be blacklisted within hours. Set it to localhost only, and require authenticated submission for everything else.

Restart Postfix after configuration changes: systemctl restart postfix. Test that port 25 is listening: ss -tlnp | grep :25.

Step 3 — Install Dovecot (IMAP/POP3)

Dovecot handles the IMAP interface — the protocol your email client uses to retrieve and synchronise messages. Postfix delivers mail to local mailboxes; Dovecot makes those mailboxes accessible to clients.

apt install dovecot-core dovecot-imapd dovecot-pop3d

Configure the mail storage location in /etc/dovecot/conf.d/10-mail.conf. Use Maildir format — each message is an individual file, which makes backups reliable and recovery from partial failures possible:

mail_location = maildir:~/Maildir

Configure authentication in /etc/dovecot/conf.d/10-auth.conf. Disable plain-text authentication over non-TLS connections:

disable_plaintext_auth = yes
auth_mechanisms = plain login

Postfix and Dovecot need to share an authentication mechanism so that Postfix can verify credentials for the submission port (587/465). In /etc/dovecot/conf.d/10-master.conf, expose the Dovecot auth socket to Postfix:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

Then tell Postfix to use Dovecot for SASL authentication by adding to main.cf:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous

Restart both services: systemctl restart dovecot postfix.

Step 4 — Configure SPF, DKIM, and DMARC Records

Without correctly configured SPF, DKIM, and DMARC, your outgoing mail will be silently delivered to spam — or rejected outright — by Gmail, Outlook, Yahoo, and most major providers. These are not optional enhancements; they are prerequisites for functional email delivery in 2025.

SPF (Sender Policy Framework) is a DNS TXT record that specifies which IP addresses are authorised to send mail for your domain. Add a TXT record to your domain's DNS:

yourdomain.com.  TXT  "v=spf1 ip4:YOUR.VPS.IP.ADDRESS -all"

The -all directive means hard fail — receiving servers should reject mail from your domain that arrives from any IP not listed. Use ~all (soft fail) temporarily while testing if you're not yet confident your server IP is the only sending source.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing message, allowing recipients to verify it was sent by your server and hasn't been modified in transit. Install OpenDKIM:

apt install opendkim opendkim-tools

Generate a 2048-bit key pair:

mkdir -p /etc/opendkim/keys/yourdomain.com
opendkim-genkey -b 2048 -d yourdomain.com -D /etc/opendkim/keys/yourdomain.com -s mail -v
chown -R opendkim:opendkim /etc/opendkim/keys/

This produces mail.private (keep this secret) and mail.txt (the DNS record to publish). Add the TXT record from mail.txt to your DNS under mail._domainkey.yourdomain.com. Configure Postfix to use OpenDKIM as a milter by adding to main.cf:

milter_protocol = 6
milter_default_action = accept
smtpd_milters = local:/opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. Start with a monitoring-only policy to receive reports before enforcing rejections:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1"

After reviewing reports for two to four weeks and confirming your legitimate mail is passing authentication, tighten the policy to p=quarantine and eventually p=reject.

Step 5 — Install SSL/TLS with Let's Encrypt

All connections to your mail server — SMTP submission, IMAP, and any webmail — must use TLS. Unencrypted connections expose credentials and message content to anyone with network access. Let's Encrypt provides free, automatically renewing certificates through Certbot.

apt install certbot

# Obtain a certificate for your mail hostname
# (Stop any service using port 80 first if necessary)
certbot certonly --standalone -d mail.yourdomain.com

Certificates are stored in /etc/letsencrypt/live/mail.yourdomain.com/. Configure Postfix to use them in main.cf:

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.yourdomain.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.yourdomain.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

smtp_tls_cert_file = $smtpd_tls_cert_file
smtp_tls_key_file  = $smtpd_tls_key_file
smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

Configure Dovecot to use the same certificate in /etc/dovecot/conf.d/10-ssl.conf:

ssl = required
ssl_cert = </etc/letsencrypt/live/mail.yourdomain.com/fullchain.pem
ssl_key  = </etc/letsencrypt/live/mail.yourdomain.com/privkey.pem
ssl_min_protocol = TLSv1.2

Let's Encrypt certificates expire every 90 days. Certbot installs a systemd timer for automatic renewal — verify it is active: systemctl status certbot.timer. Create a renewal hook to restart Postfix and Dovecot after renewal so they load the new certificate:

# /etc/letsencrypt/renewal-hooks/deploy/restart-mail.sh
#!/bin/bash
systemctl restart postfix dovecot

chmod +x /etc/letsencrypt/renewal-hooks/deploy/restart-mail.sh

Step 6 — Set Up Spam Filtering

Without spam filtering, your inbox is unusable within days of your server becoming publicly reachable. The choice in 2025 is effectively between SpamAssassin and Rspamd.

SpamAssassin is the established option — well documented, widely used, and simple to understand. It uses a rule-based scoring system where each characteristic of a message adds or subtracts from a score; messages above a threshold are marked as spam. It is single-threaded and can become a bottleneck under load.

apt install spamassassin spamc

# Enable the service
systemctl enable --now spamassassin

# Update rules
sa-update

Integrate SpamAssassin with Postfix via the spamass-milter package, which connects SpamAssassin as a milter interface Postfix can call for each incoming message.

Rspamd is the modern alternative — multi-threaded, substantially faster, with a built-in web interface for monitoring, Redis-backed Bayesian filtering, and integrated DKIM signing. If you are starting a new deployment in 2025, Rspamd is the better choice.

apt install rspamd redis-server

systemctl enable --now rspamd redis-server

Connect Rspamd to Postfix in main.cf:

smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
milter_protocol = 6
milter_default_action = accept

The Rspamd web interface runs on port 11334 by default. Bind it to localhost only and access it via an SSH tunnel: ssh -L 11334:localhost:11334 user@your.vps.ip. Do not expose the Rspamd web interface to the public internet.

Spam filtering accuracy improves substantially over time as you train it. Feed it examples of ham and spam using the Rspamd rspamc tool or SpamAssassin's sa-learn. Plan to actively train for the first few weeks of operation.

Step 7 — Hardening Tips

A default Postfix/Dovecot installation is functional but not hardened. These additional steps significantly reduce your attack surface.

Disable open relay: Verify your server is not an open relay — a server that forwards email from and to any address without authentication. Send a test through an open relay checker such as MXToolbox's relay test, or use Swaks:

swaks --to test@external-domain.com \
      --from forged@another-domain.com \
      --server mail.yourdomain.com

A properly configured server should reject this with a 554 relay access denied error. If it accepts the message, your mynetworks and smtpd_recipient_restrictions in Postfix need immediate review.

Restrict authentication attempts: Add rate limiting and restriction rules to Postfix's main.cf:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_invalid_hostname,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain

smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 30
anvil_rate_time_unit = 60s

Enforce TLS-only client connections: Ensure clients cannot submit mail without TLS. In /etc/postfix/master.cf, the submission port (587) should have smtpd_tls_security_level=encrypt:

submission inet n - y - - smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Hide software version banners: Attackers scan for specific software versions to exploit known vulnerabilities. Suppress version information from Postfix's SMTP banner:

smtpd_banner = $myhostname ESMTP

Set up logwatch or similar: Daily log summaries help you spot authentication failure patterns, unusual queue behaviour, or delivery errors before they become larger problems. apt install logwatch and configure it to email a daily summary to an address you monitor.

The Maintenance Burden

Getting the stack running is the satisfying part of this project. What most guides don't explain clearly enough is what the ongoing commitment looks like. This section is worth reading carefully before you provision your first VPS.

Security patches: Every component in your mail stack — the OS kernel, Postfix, Dovecot, Rspamd, OpenDKIM, and any webmail software — will have security vulnerabilities disclosed over time. Unpatched mail servers are actively scanned and targeted. You need a reliable process for applying updates promptly, testing that mail continues to function after updates, and monitoring for security advisories from each software project. This is a non-trivial ongoing time commitment, not a one-time event.

IP reputation monitoring: Your IP address can be added to a spam blocklist by any of the major blocklist operators based on a single compromised account, a misconfiguration that causes you to forward spam, or simply because a previous owner of the IP range had bad practices. Check your IP against Spamhaus ZEN, Barracuda, and Sorbs regularly. Getting delisted from some blocklists is free and fast; others charge fees or have weeks-long manual review processes.

Backups: A failed disk or corrupted filesystem on a mail server can mean permanent loss of every message ever received. Automated backups running to a separate location are mandatory — not optional. Test your restore procedure periodically. Backups you have never tested are not real backups.

Deliverability monitoring: Even if your IP is not blocklisted, deliverability can degrade. Gmail's Postmaster Tools, Microsoft SNDS (Smart Network Data Services), and Yahoo's Feedback Loop all provide signals about how your mail is being treated. Monitoring these is the only reliable way to know whether your legitimate mail is reaching recipients' inboxes.

Certificate renewals: Let's Encrypt certificates expire every 90 days. The renewal automation works — until it doesn't. A failed renewal that goes unnoticed for 90 days means every mail client connection starts showing TLS errors. Monitor certificate expiry explicitly, not just by trusting the renewal timer.

Queue management: When a downstream mail server is temporarily unavailable, Postfix queues messages and retries according to a backoff schedule. During extended outages, queues grow. If your disk fills, Postfix stops accepting mail entirely. Monitor disk usage and mail queue depth as real-time metrics, not afterthoughts.

Running a VPS email server means you are the on-call engineer for all of these issues, at all hours. Attacks don't wait for business hours. Certificate expirations don't respect holidays.

The Alternative: Managed Private Email

Everything described in this guide is something you can build and operate yourself on a well-chosen VPS — and for the right person with the right skills and time, that is a legitimate choice. But it's also worth being direct about what you're giving up by self-hosting.

The entire stack above — Postfix configuration, Dovecot, spam filtering, DKIM/SPF/DMARC, TLS certificate management, IP reputation monitoring, blacklist delisting, security patching, backups, and deliverability monitoring — is what enemail.de operates continuously on your behalf. Zero-knowledge end-to-end encryption means enemail cannot read your messages even if compelled — there is nothing to hand over but ciphertext. The infrastructure runs on dedicated EU servers. DKIM, SPF, DMARC, TLS, and spam filtering are managed by people who do this full time.

You get a clean sending reputation from day one. Your messages reach the inbox reliably. Patches are applied without action on your part. And if something fails at 3am, it's the enemail team's problem to fix, not yours.

If you need to run your own infrastructure for compliance, sovereignty, or specific technical requirements, use a proper VPS. Evolushost's EPYC VPS range gives you the hardware specification, EU jurisdiction, and network configuration your mail stack needs. But if what you actually want is private email that works — with none of the operational overhead — the managed path is worth considering seriously.

Conclusion: Control vs. Simplicity

The choice between running your own VPS email server and using a managed private email service is ultimately a choice about where you want to spend your time and attention.

Self-hosted VPS email gives you maximum control. Every configuration decision is yours. Every byte of data stays on infrastructure you manage directly. You can audit every layer of the stack. For sysadmins, security researchers, or organisations with specific compliance requirements, that control is genuinely valuable — and worth the ongoing operational commitment it demands. If that's you, start with a well-specified EPYC VPS from Evolushost and follow the steps in this guide carefully.

Managed private email gives you simplicity with genuine privacy. You don't manage patches, monitor blocklists, wrestle with DKIM configuration, or deal with certificate renewals. The privacy guarantees are real — zero-knowledge encryption means the provider cannot read your mail — and the operational burden is zero. If you want private email without the infrastructure work, enemail.de exists for exactly this purpose.

Both paths lead to email that is genuinely private. Which one is right depends on your skills, your time, and your reasons for wanting control in the first place.