Step 0 — Get the Right Hardware
The first and most consequential decision is where your email server runs. Many guides suggest a cheap VPS — a virtual machine on someone else's hardware. For a personal project, that might be fine. For a genuine privacy use case, it is the wrong foundation.
Running an email server on a shared VPS means your traffic, your queues, and potentially your cryptographic operations share physical hardware with unknown neighbours. A dedicated server — bare metal — removes that attack surface entirely. You are the sole tenant of the physical machine. No hypervisor sits between your software and the CPU.
The minimum requirements for a production email server: a static IPv4 address with a clean reputation, reliable uptime (99.9% minimum — downtime means lost mail), sufficient RAM for spam filtering and indexing (8 GB is a realistic floor), and fast storage for message queues and mailbox indices.
For EU-based email infrastructure, instantly available dedicated servers from Evolushost are worth serious consideration. They offer bare-metal Ryzen hardware with immediate provisioning in Frankfurt, Berlin, and Vienna — all within the EU, all under Austrian and German jurisdiction. For anyone building email infrastructure with GDPR compliance in mind, the location matters as much as the hardware spec.
Whatever provider you choose, verify the IP reputation before you start configuring anything. Use tools like MXToolbox to check whether the IP has appeared on any blacklists. An IP with a dirty history will haunt your deliverability regardless of how well you configure everything else.
Step 1 — Choose Your OS and MTA
Ubuntu 22.04 LTS is the practical choice for a self-hosted email server in 2025. It has long-term support through 2027, broad community documentation, and well-maintained packages for every component you'll need. Debian 12 is an equally solid alternative if you prefer it.
Your Mail Transfer Agent (MTA) — the software that actually sends and receives email — is Postfix. It is the industry standard for a reason: it is battle-tested, actively maintained, has excellent documentation, and is configured by text files that version-control cleanly. Alternatives like Exim exist, but unless you have a specific reason to use them, Postfix is the answer.
Install Postfix and walk through the initial configuration carefully. The most important settings are myhostname (must match your rDNS), mydomain, mynetworks (keep this tight — only localhost and your own IPs), and inet_interfaces. A misconfigured mynetworks turns your server into an open relay and will get your IP blacklisted within hours.
Step 2 — Install Dovecot for IMAP
Postfix handles mail transfer — getting messages to and from other servers. Dovecot handles mail access — letting your email clients retrieve messages via IMAP or POP3. They work together: Postfix delivers mail to local mailboxes, Dovecot serves those mailboxes to your clients.
Install dovecot-core and dovecot-imapd. The key configuration files are in /etc/dovecot/conf.d/. You'll need to define your mail location, set up authentication (Dovecot and Postfix need to share authentication so Postfix can verify senders), and configure your SSL certificate path.
For mailbox storage, Maildir format is preferable to mbox. Each message is a separate file, which makes backups and recovery significantly cleaner. Configure this in 10-mail.conf with mail_location = maildir:~/Maildir.
Step 3 — Configure SPF, DKIM and DMARC
This is where many self-hosted email setups fall apart. Without correctly configured SPF, DKIM, and DMARC records, your outgoing mail will be rejected or silently delivered to spam by Gmail, Outlook, and most major providers. This is not optional.
SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses are authorised to send email for your domain. A minimal SPF record looks like: v=spf1 ip4:YOUR_SERVER_IP -all. The -all directive tells receiving servers to reject mail claiming to be from your domain but arriving from unlisted IPs.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. Install opendkim and opendkim-tools, generate a 2048-bit RSA key pair, publish the public key as a DNS TXT record, and configure Postfix to sign outgoing mail via the OpenDKIM milter interface.
DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together with a policy. Start with a monitoring-only policy (p=none) so you can receive reports on what mail is being sent under your domain before you enforce stricter rules.
Step 4 — Add TLS/SSL
TLS is mandatory. Any modern mail server that doesn't support encrypted connections will be penalised by receiving servers and will rightly alarm any security-conscious recipient. Certbot with Let's Encrypt makes this essentially free and automated.
Run Certbot to obtain a certificate for your mail hostname. Configure Postfix to use it for both incoming connections (smtpd_tls_cert_file, smtpd_tls_key_file) and outgoing connections (smtp_tls_security_level = may as a minimum, encrypt if you want to enforce it). Configure Dovecot similarly. Set up a cron job or use Certbot's systemd timer to renew certificates automatically — Let's Encrypt certificates expire every 90 days.
Step 5 — Spam Filtering
Without spam filtering, your inbox will be unusable within days. The two main options are SpamAssassin and Rspamd.
SpamAssassin is the older, more widely documented option. It uses a rule-based scoring system and is straightforward to configure, but it is single-threaded and can become a bottleneck on busy servers. Rspamd is the modern replacement: multi-threaded, significantly faster, with a built-in web interface, Redis-backed statistics, and DKIM signing support built in. If you're starting fresh in 2025, Rspamd is the better choice.
Both integrate with Postfix via the milter interface. Training is essential — spam filtering accuracy improves dramatically when you feed it examples of ham and spam from your actual mail flow. Plan to spend time tuning this before your inbox behaves reliably.
Step 6 — Encryption at Rest
TLS protects mail in transit. Encryption at rest protects stored mail on the server from being read if someone gains access to the storage layer. Dovecot supports per-mailbox encryption through its mail-crypt plugin.
The mail-crypt plugin encrypts mailbox contents using per-user keys. You can use a global key (simpler to manage, less granular) or per-user keypairs generated at account creation. Per-user keys are the better privacy model but require careful key management — if a user loses their key and you have no recovery mechanism, their mail is gone permanently. Design your key management strategy before you store a single message.
The Ongoing Maintenance Burden
Getting your email server running is the easy part. Keeping it running is a different matter entirely.
You will need to monitor deliverability continuously — checking whether your IP has appeared on any of the major blacklists (Spamhaus, SORBS, Barracuda, and others). You will need to apply security patches to your OS and mail software promptly — a vulnerable Postfix or Dovecot installation is a serious risk. You will need to monitor disk usage, since a full mail queue or mailbox directory causes immediate outages. You will need to set up alerting for queue backlogs, failed TLS connections, and authentication failures that might indicate a brute-force attempt.
Incident response deserves its own written plan. What do you do if your server is compromised? If your IP is listed on Spamhaus DROP? If a user account is hijacked and starts sending spam? These scenarios happen, and responding to them under pressure without a plan in place is stressful and slow. Running an email server is, in practical terms, a 24/7 operational responsibility.
The Honest Alternative
Everything described in this guide is something enemail has already built, operates continuously, and maintains on your behalf. Zero-knowledge encryption means your email content is encrypted before it ever reaches our servers — we cannot read it, and neither can anyone with access to the server. We run on dedicated EU infrastructure, apply patches promptly, monitor blacklists, handle deliverability issues, and operate DKIM, SPF, and DMARC correctly across all domains.
Self-hosting gives you maximum control. It also gives you maximum responsibility. If that trade-off is right for you, this guide gives you a starting point. If you want the privacy of self-hosting without the operational overhead, enemail was built for exactly that.