The real problem
Anyone who relies on email as a primary professional tool — and a lawyer does so every day — knows that the choice of email system is not a matter of taste. It is a matter of operational reliability.
For several years I used Proton Mail as the primary provider for my professional domains. Proton is a serious service, with a solid end-to-end encryption architecture and a Swiss jurisdiction that offers significant data protection guarantees. The quality of the product is not in question.
The problem was different, and more concrete. Over time, I encountered three operational issues that, taken together, made the solution increasingly unsustainable for my professional use.
The first concerned the scope of settings management. Proton Mail offers an interface designed for simplicity, which is a strength for general users but a limitation for those who need advanced customisation of account configuration, filter management, and multi-domain workflow organisation.
The second was a technical issue I encountered in my usage: duplicate emails that recurred, creating disorder in correspondence management.
The third, the most sensitive for a professional: in certain circumstances, messages landing in spam at the recipient’s end. This is not a problem exclusive to Proton — it can happen with any provider sharing IP pools among many users — but when your professional email is classified as junk by the recipient’s server, the damage is not merely technical: it is reputational.
These three elements, combined, made it clear that the choice was not between one provider and another, but between dependence on a provider and direct control of the infrastructure. The point is not ideological: it is operational. When your professional communication depends entirely on a third-party service, you accept its architectural choices, its limitations, its IP reputation shared with thousands of other users. This is acceptable as long as it works. When it stops working reliably, the only alternative that offers maximum control is self-hosting.
This choice, moreover, is consistent with a position I have expressed in academic contexts: digital sovereignty is not an abstract concept, but a practice built from the infrastructure on which one’s data and communications operate.
The architectural choice: why Mailcow
Before settling on Mailcow, I evaluated several alternatives. The email solutions landscape is broad, and each option presents a different balance between control, complexity, and sustainability.
Tuta and Posteo offer good privacy guarantees but share the same structural limitation as Proton: control of the infrastructure remains with the provider. Migadu is an interesting service that allows using custom domains with simplified management, but does not provide full server control.
At the other extreme, full self-hosting — manually installing and configuring Postfix, Dovecot, SpamAssassin, OpenDKIM and all necessary components — guarantees maximum control but demands a very high initial and ongoing maintenance investment. Years ago I managed configurations of this kind, and experience taught me that the complexity of maintaining a handcrafted mail server is often underestimated.
Mailcow represents the equilibrium point: a fully dockerized solution that integrates all necessary components within a single containerised architecture — Postfix for sending, Dovecot for receiving and IMAP storage, Rspamd for spam filtering, SOGo as webmail, ClamAV for antivirus, MariaDB, Redis, Nginx, ACME for Let’s Encrypt certificates, Unbound as DNS resolver, Netfilter for fail2ban protection, and a Watchdog for basic monitoring.
The advantage of containerisation is not aesthetic: it is operational. Updates happen with a single command, components are isolated, backup is structured, and rollback in case of problems is immediate. It is the difference between managing a system and fighting a system.
The solution is developed by the German company Servercow and released as open source. The community is active on both the official forum and Telegram, and the documentation is complete and up to date.
The migration: what actually happened
The migration was, in my experience, free of significant problems. I say this honestly, because many articles on self-hosted email tend to dramatise the process. In my case, the quality of Mailcow’s documentation made the entire path straightforward.
DNS preparation
DNS record configuration is the step that requires the most attention and that, if done incorrectly, compromises everything else. The essential records are:
| Record | Function | What to verify |
|---|---|---|
| A | Associates the FQDN domain with the server IP | Must point to the correct server IP |
| MX | Indicates the server that handles mail for the domain | Priority 10, pointing to the FQDN |
| SPF (TXT) | Declares which servers are authorised to send email for the domain | Include the server IP, use ~all or -all |
| DKIM (TXT) | Cryptographic signature of outgoing emails | Automatically generated by Mailcow |
| DMARC (TXT) | Authentication policy combining SPF and DKIM | At least v=DMARC1; p=quarantine |
| PTR (Reverse DNS) | Associates the server IP with the domain | Must be requested from the server provider |
| CNAME | autodiscover/autoconfig for automatic client configuration | Pointing to the FQDN |
The most common mistake is not technical but one of timing: modifying DNS records and expecting them to work immediately. DNS propagation takes time — from a few minutes to 48 hours depending on the provider and the configured TTL. The recommendation is to prepare all DNS records at least 24–48 hours before the actual cut-over, ideally with low TTL values.
Installation and configuration
Mailcow installation follows the procedure documented in the official repository. The generate_config.sh script handles initial configuration, including the SSL certificate request via Let’s Encrypt. Mailbox migration via IMAP was direct: clients are reconfigured with the new server parameters, and mailbox contents synchronise accordingly.
What the documentation cannot cover is the verification time. Before the definitive cut-over — the moment the MX record stops pointing to the old provider and starts pointing to the new server — a testing period is necessary to verify sending, receiving, authentication, spam filtering, and correct record resolution. Skipping this phase means discovering problems when emails from clients or colleagues start bouncing. In my case, I maintained a coexistence period during which both systems were active, gradually moving domains to Mailcow only after verifying that everything worked correctly.
Another aspect that demands attention is multi-domain management. Mailcow supports it natively, but each additional domain requires its own complete DNS configuration (SPF, DKIM, DMARC), and an error on a single record for a single domain can compromise that domain’s deliverability without affecting the others — which makes diagnosis less straightforward.
Deliverability
Deliverability is the point where anyone migrating to self-hosting must be most attentive. A new IP, without history, starts with a neutral reputation — which does not mean good. It means unknown, and for many receiving servers “unknown” equals “suspicious.”
In my case, the combination of correctly configured DNS records (SPF, DKIM, DMARC, PTR), a clean-reputation IP, and gradual sending volumes generated no particular problems. It is good practice to verify your server’s score with tools such as mail-tester.com and to monitor the main blacklists during the first days.
Mailcow today: why the 2022 guide is no longer enough
On this blog I published in 2022 a guide to installing Mailcow on Ubuntu 20.04. That guide, while functional at the time, is now outdated in several respects.
Docker Compose v1 — on which that guide was based — has been deprecated and replaced by Docker Compose v2, integrated directly into the Docker CLI. The docker-compose commands become docker compose (without hyphen): an apparently cosmetic change that renders the 2022 instructions inapplicable on a current installation.
Rspamd, already present in 2022, has matured as a spam filtering solution with updated rules and deep integration within the Mailcow ecosystem. The administration interface has been improved in usability and functionality. Let’s Encrypt certificate management is more robust. The Watchdog offers more granular monitoring.
This is not a matter of preferring the new over the old: a 2022 technical guide applied in 2026 produces avoidable errors and frustration. This article replaces that guide.
MailMate in the professional workflow
The choice of email client is the other half of the architecture. Having a server under your own control loses part of its value if the client interfacing with it is limited in functionality.
MailMate is an email client for macOS developed by Benny Kjær Nielsen, a Danish computer scientist with a PhD in algorithms and optimisation. It is pure IMAP — it does not support POP3, which in 2026 is not a limitation but a correct design choice.
MailMate has become my primary tool, and at this point I consider it essential in my daily work. This is not a rhetorical statement: the functionality it offers has no equivalent in any other client I have tested over the years.
Multi-identity management. Anyone managing multiple professional domains — law firm, blog, projects — needs distinct signatures, separate SMTP settings, and fluid switching between identities. MailMate handles all of this natively, with account- and domain-specific signatures, including the ability to create signatures in Markdown and HTML.
Markdown composition. For those who write structured text daily — and a lawyer does — composing email in Markdown is a real productivity gain. No accidental formatting, no compatibility issues: the text is clean, the structure is explicit, the result is predictable.
Advanced search. MailMate’s search function is among the most powerful available in any email client. The abbreviated syntax allows queries like f alice t bob (from Alice to Bob) or f !alice t (bob marc) (excluding Alice, searching among Bob and Marc). For anyone receiving dozens of emails per day who needs to retrieve a specific exchange, this is a work tool, not a convenience.
Smart Mailboxes. Virtual mailboxes based on dynamic conditions, with a depth of combinable criteria that other clients cannot match. For anyone handling high volumes of correspondence, they transform the inbox from an undifferentiated stream into organised information.
Security and privacy. MailMate blocks all external references in HTML emails by default — tracking pixels, web beacons, remote images — and natively supports OpenPGP (via GPG Suite) and S/MIME. Distortion Mode renders screen content illegible in shared environments: a feature that seems marginal until you work on a train or in an open space.
An aspect worth mentioning
One element that distinguishes MailMate from most commercial software is the availability of its developer, Benny Kjær Nielsen. This is not a technical point, but a professional one: when a problem arises — and with any software it does — having a developer who responds, investigates, and resolves is a value that goes beyond features. Over years of use, Benny has always responded with competence and speed, including very recently. It is the kind of support that deserves recognition.
Security, privacy and maintenance: no shortcuts
Managing a self-hosted mail server is not magic. It is ongoing responsibility.
This must be stated clearly, because many articles on self-hosting stop at installation and imply that the work ends there. It does not.
Encryption. Mailcow encrypts emails stored on the server (lz4 compression + encryption). The key pair is located in the crypt-vol-1 volume. This protects data at rest — a security level that many providers do not offer by default.
Backup. A mail server without a backup strategy is a disaster waiting to happen. In my case I use restic with autorestic for automated, encrypted backups to remote storage, with monitoring via health checks. The backup must include Docker volumes, Mailcow configuration, and — separately — a periodic mailbox export.
Updates. Mailcow releases regular updates. The operation reduces to a few commands (git pull, docker compose pull, docker compose up -d), but must be performed regularly and verified. An unpatched server is a vulnerable server.
Monitoring. The integrated Watchdog provides basic monitoring. It is advisable to supplement it with external checks — monitoring server reachability, SSL certificate status, and blacklist presence.
IP reputation. Reputation is not built once and then forgotten. It must be monitored over time: periodically verifying your score on mail-tester.com, checking the main blacklists, and responding promptly to any reports.
Actual time required. After the initial configuration and stabilisation phase, routine maintenance requires a contained but constant commitment: monthly updates, log review, service status checks, backup monitoring. It is not a full-time job, but neither is it a system that manages itself.
Who should consider this and who should not
Self-hosted email is not the right solution for everyone. It is the right solution for those who meet three conditions simultaneously.
The first is having a genuine need for control: over configuration, deliverability, and infrastructure confidentiality. If a provider such as Proton Mail, Tuta, or Migadu meets your needs without compromise, self-hosting adds complexity without proportional benefit.
The second is having adequate technical competence: not necessarily that of a professional sysadmin, but sufficient to manage a Linux server, Docker, DNS records, and basic diagnostics. The learning curve exists, and should not be underestimated.
The third is having the willingness to manage complexity over time: not just for the initial installation, but for routine maintenance, updates, monitoring, and incident management.
Those who do not meet all three conditions will likely find more value in intermediate solutions — privacy-conscious providers with simplified domain management — than in a self-hosted infrastructure.
Conclusions
Managing one’s own email infrastructure is an act of professional coherence for anyone working in data protection and privacy. It is not a technical detail: it is an architectural choice that reflects the same rigour applied to regulatory analysis and professional advice.
The infrastructure on which our professional communications travel is not neutral. It is part of the method.
The combination of Mailcow as server and MailMate as client represents, in my experience, the most solid equilibrium between control, functionality, and operational sustainability. It is not the only possible solution, but it is the one that, after testing many, has proven most consistent with my professional needs.