Layer 1 — Hardware
Every privacy claim a service makes ultimately rests on the physical infrastructure it runs on. Start with the wrong foundation and every subsequent security measure is compensating for a structural weakness.
The choice between shared cloud infrastructure and dedicated bare metal is the most consequential infrastructure decision in private email. Shared cloud — virtual machines running on a hypervisor on hardware shared with other tenants — introduces attack surface that no amount of application-level security can fully eliminate. Side-channel vulnerabilities like Spectre and Meltdown demonstrated that hardware-level isolation between virtual machines is not guaranteed. A cloud provider with physical access to the underlying hardware can snapshot a running VM's memory, capturing encryption keys and plaintext data.
Bare metal changes the threat model: no hypervisor, no co-tenants, no cloud provider intermediary with physical access to your environment. The physical machine belongs exclusively to its operator. For anyone building private email infrastructure — whether for a service or for their own use — this is the baseline, not a premium option.
For developers and teams who want to build their own privacy stack from scratch, instantly provisionable dedicated servers from Evolushost provide bare-metal Ryzen hardware in Frankfurt, Berlin, and Vienna with immediate availability. No waiting for manual provisioning, no shared hypervisor, and all of it under EU jurisdiction from a company with no US parent.
Layer 2 — Operating System and Hardening
A freshly provisioned server is not a secure server. The operating system as shipped is configured for broad compatibility, not minimal attack surface. Hardening is the process of closing the gap between "runs everything" and "runs only what this server needs."
Start with a minimal OS installation — no graphical desktop, no unnecessary services, no default packages beyond what you explicitly need. Ubuntu 22.04 LTS or Debian 12 are sensible choices for a mail server in 2025, both offering long support windows and well-maintained packages.
Key hardening steps: disable password authentication for SSH entirely and use key-based authentication only. Configure a strict firewall — only the ports your mail server actually uses (25, 465, 587, 993) should be open, and only from appropriate sources. Install and configure fail2ban to block repeated authentication failures. Consider an intrusion detection system like AIDE or Wazuh to alert on unexpected file changes. Apply OS and package security patches promptly — kernel vulnerabilities are a real attack vector, and the window between a patch being released and exploitation beginning is narrowing.
Log everything relevant, but log to a remote syslog server if possible. Local logs are useful; logs on a separate system that an attacker cannot reach after compromising the mail server are considerably more useful for forensics and incident response.
Layer 3 — The Mail Stack
The MTA (Mail Transfer Agent) and IMAP server are the core of a mail service. The dominant combination is Postfix for SMTP handling and Dovecot for IMAP/POP3. Both are well-documented, actively maintained, and have proven track records in production environments at scale.
Alternatives worth knowing: OpenSMTPD from the OpenBSD project is a significantly simpler MTA with a cleaner configuration model — a good choice for operators who prioritise auditability and minimal complexity over feature breadth. Haraka is a Node.js-based MTA that suits teams with JavaScript expertise who want to write custom processing pipelines in a familiar language. For most use cases, Postfix and Dovecot remain the default for good reasons.
Beyond the core stack, a production mail server needs: spam filtering (Rspamd is the current standard, faster and more capable than the older SpamAssassin), virus scanning if your threat model requires it, rate limiting to prevent abuse if you are operating a service for multiple users, and a web interface if any of your users are not technical enough to configure a mail client directly.
Configuration management matters here. Mail server configuration spread across multiple files, undocumented, modified by hand over months, is a maintenance and security liability. Use Ansible, Chef, or even simple shell scripts to keep your configuration in version control and reproducible.
Layer 4 — Encryption
Encryption for email operates at two levels — in transit and at rest — and they solve different problems.
TLS in transit is non-negotiable in 2025. All SMTP, IMAP, and submission connections must be encrypted. STARTTLS on port 587 for submission, implicit TLS on port 465 and 993 for submission and IMAP respectively. Let's Encrypt provides certificates free of charge, and with proper automation (Certbot with systemd timers), renewal is hands-off. MTA-STS is worth implementing — it publishes a DNS policy telling senders that your server supports TLS and should not fall back to plaintext.
Encryption at rest is where implementations vary significantly, and where the distinction between ordinary encryption and zero-knowledge encryption matters most. Standard at-rest encryption — disk-level full disk encryption — protects against physical theft of hardware but does not protect against a provider or attacker who has administrative access to the running server. The server can still read your mail because it decrypts storage as part of normal operation.
Zero-knowledge encryption means the server never has access to decrypted content. Encryption and decryption happen client-side. The server stores and transmits ciphertext. This requires keys to never exist in plaintext on the server. Implementing this correctly is technically demanding and incompatible with some standard email features — server-side search, for instance, cannot operate on ciphertext without additional techniques like searchable encryption. The privacy gain is substantial: even an administrative access to the server yields only ciphertext that is useless without the user's private key.
Layer 5 — Metadata Minimisation
Email content is only part of what a mail server knows. Metadata — who you communicate with, when, how frequently, from which IP addresses — can be as revealing as message content, and it is often easier to collect and analyse at scale.
Logging policy is the first decision. What do you log, for how long, and who can access those logs? A mail server log that records every connection with timestamps and IP addresses is a rich dataset even if message content is encrypted. Define a minimum necessary logging policy and enforce it technically, not just as a policy document.
On outbound email, consider which headers you strip before delivery. The Received header chain can expose your users' IP addresses if they connected via a mail client directly. Stripping these on outbound mail before relay is a meaningful metadata protection. Similarly, the X-Mailer and similar headers can reveal client software versions — strip them if there is no operational reason to include them.
IP address handling in your web interface, if you have one, is also a metadata consideration. Do you log login IPs? For how long? Under what circumstances do you share that data? Having clear, short data retention policies and enforcing them automatically is significantly more trustworthy than discretionary deletion.
Layer 6 — Legal Jurisdiction
The laws that govern your infrastructure are determined by three things: where the company operating the service is incorporated, where the hardware physically sits, and where the data centre operator is incorporated. All three matter.
Austria and Germany are strong choices. Both are GDPR-native EU member states with active data protection authorities and strong constitutional traditions of privacy as a fundamental right. Neither has a broad surveillance legislation framework comparable to the UK's Investigatory Powers Act or the US's FISA. Legal requests targeting data in Austria or Germany must go through the Austrian or German courts and must meet proportionality requirements.
The US CLOUD Act is a specific and serious risk for infrastructure with any US corporate connection. A company incorporated in the US, headquartered in the US, or majority-controlled by US investors may be subject to CLOUD Act demands regardless of where the hardware sits. This is not a theoretical risk — it has been exercised. A European company with no US investor exposure is simply not subject to it.
When evaluating providers, look at the full corporate structure. A European brand name built on a US-owned data centre company still has US jurisdictional exposure. The only way to fully exit US legal reach is a corporate structure with no US persons or entities in the chain of ownership or control.
Layer 7 — Operational Security
The final layer is the one that is most often underestimated by technically capable teams: the operational security of the humans who administer the infrastructure.
Define precisely who has administrative access to the mail servers. Every person with root access is a potential attack vector — through credential compromise, social engineering, or insider threat. Minimise the number of people with full access. Use hardware security keys for administrative authentication. Implement privilege separation where possible — a person who can manage DNS does not need root on the mail server.
Audit logs of administrative actions should be immutable and stored separately from the systems being administered. If someone with root access modifies the system, that action should be logged in a place they cannot reach to alter the record.
Key rotation is an operational discipline, not a one-time task. DKIM keys should be rotated regularly. TLS certificates are automated, but the systems that perform that automation should themselves be reviewed. Encryption keys used at rest should have a defined rotation schedule. Document the rotation procedures and test them — a rotation process that has never been exercised is a process that may fail at the worst moment.
Incident response planning is the final piece. Write down what you do if the mail server is compromised. Who is notified, in what order? What data is preserved for forensics? What is the communication plan for affected users? A written plan, reviewed by everyone who might need to execute it, is worth considerably more than improvised response under pressure.
What enemail Does at Each Layer
At the hardware layer: dedicated bare-metal servers, no hypervisor, no shared tenancy. At the OS layer: hardened Linux, key-based SSH only, strict firewall, automated patch management. At the mail stack layer: Postfix and Dovecot, Rspamd for spam filtering, full SPF/DKIM/DMARC compliance. At the encryption layer: TLS in transit, zero-knowledge encryption of message content with keys that never exist on our servers in plaintext. At the metadata layer: minimal logging, outbound header stripping, short retention periods enforced automatically. At the jurisdiction layer: Austrian company, EU hardware only, no US corporate connection. At the operational layer: restricted administrative access, hardware security keys, immutable audit logs, documented incident response procedures.
Each of these is a deliberate decision, not a default. Private email infrastructure is built layer by layer, and every layer matters.