Mailcow, Stalwart or Mailu: self-hosted mail servers compared

Email in house instead of at a hyperscaler? WZ-IT sets up mail servers such as Mailcow, clarifies deliverability in advance and provides managed hosting and ongoing operations. Discuss your setup

The self-hosted mail server is the emblem of sovereign IT and at the same time the service where self-hosting most often goes wrong. Not because of the software, but because email depends on something you cannot install: reputation.

This article assesses the three common open-source solutions and starts with the question that comes first: is running your own mail server the right answer at all?

All figures from the repositories, as of 4 September 2026.

Table of contents

• The question first: self-host or not
• The three at a glance
• Two architectures, not three
• Mailcow
• Stalwart
• Mailu
• Which one for which situation
• Deliverability: the real hurdle
• What actually takes work in a move
• How we approach this at WZ-IT
• Further guides

The question first: self-host or not

Email has the highest operational demand per user of any common service. The reason is not the technology but that its function depends on other people's judgement: whether your messages arrive is decided by foreign systems based on your reputation.

That reputation builds over months and is lost in days, for instance through a compromised mailbox sending advertising.

Self-hosting is right when data must not leave the premises, when a named person owns the service, and when effort for monitoring and updates is budgeted.

Self-hosting is wrong when nobody is responsible, when the server is meant to run on the side, or when the only reason is cost saving. A European provider under contract is then both more sovereign and more reliable than a poorly maintained server of your own.

That is not reticence about self-hosting. It is the precondition for it working.

The three at a glance

Figures from the public repositories, as of 4 September 2026.

A note on Stalwart's licence: the project is dual-licensed under AGPL-3.0 and the Stalwart Enterprise License v2. Part of its functionality therefore falls under the commercial licence. Anyone needing a particular feature should check which side it sits on before deciding. Mailcow and Mailu have no such split.

Two architectures, not three

The essential difference runs not between three products but between two approaches.

Mailcow and Mailu bundle well-known individual components. Postfix for sending, Dovecot for mailboxes, Rspamd for spam filtering, plus webmail and administration, all in containers. The advantage: every component has been proven for decades, and documented knowledge exists for every problem. The disadvantage: many moving parts.

Stalwart is a single application. SMTP, IMAP, JMAP, CalDAV and CardDAV in one binary written in Rust. The advantage: considerably lower resource needs and a fraction of the moving parts. The disadvantage: a young project in a place where maturity counts particularly, and no access to the decades of accumulated knowledge around Postfix and Dovecot.

Mailcow

Mailcow is the most mature option for companies and the most common choice in the range of 25 to 150 mailboxes. Under GPL-3.0, operated as a Docker stack.

Ships SOGo for webmail, calendars, contacts and task management, plus an admin interface for maintaining mailboxes, forwarding and filters without the command line.

Resource needs follow accordingly: around 6 GB of RAM plus swap is stated as the requirement.

The precondition is someone able and willing to maintain a Docker stack. Where that person exists, Mailcow is the obvious choice.

Stalwart

The youngest of the three and the one with the most interesting approach. A single Rust application speaking all protocols itself, with considerably lower resource needs than a container stack.

Strength: few moving parts, modern protocol support including JMAP, calendars and contacts without an additional system.

Limits: no built-in webmail, so Roundcube or SOGo has to be placed alongside. And the dual licence, which reserves part of the functionality for the commercial edition.

For technically led environments with limited resources it is a serious alternative. For a company expecting a finished solution, Mailcow is closer to the need.

Mailu

Mailcow's lightweight relative, under MIT. Also a stack of Postfix, Dovecot and Rspamd, but leaner and simpler to set up.

Strength: lower resource needs than Mailcow with a similar approach, well suited to running under Kubernetes.

Limit: a smaller feature set for administration and collaboration. For companies needing calendars and shared mailboxes it suffices less often than Mailcow.

Which one for which situation

Deliverability: the real hurdle

This is where moves fail, not on the software choice. Four points that must be in place before the first production send:

SPF, DKIM and DMARC. Without correct DNS records, a new sender is treated with suspicion or rejected by large providers. These records belong set and verified before the first message goes out.

The IP range. Not every IP address is suitable. Some ranges are broadly distrusted by providers because a lot of spam originated there. That belongs checked before choosing a server, not after.

The reverse DNS record. The PTR record has to match the sender name. A missing or wrong record is one of the most common reasons for rejection.

Warming up. A new sender suddenly dispatching hundreds of messages looks like a spam operation. Volume is increased over days rather than switched over on moving day.

These four points are independent of the software choice and account for the larger part of the preparation.

What actually takes work in a move

Messages transfer reliably, through IMAP synchronisation with tools such as imapsync. That is the easy part.

Calendars, contacts and distribution lists transfer poorly. Depending on the source they export with varying success, and out-of-office settings plus filter rules generally do not transfer at all.

The switch needs a window of parallel operation. Both systems receive for a while until the DNS change has propagated. Switching hard loses messages.

Retention is its own topic. Business email is subject to commercial and tax retention periods in Germany. A mail server does not satisfy that by itself; it requires audit-proof archiving alongside the mailbox. That question belongs settled before the move, not after.

How we approach this at WZ-IT

We ask first who owns the service. Where no answer comes, we advise against self-hosting, regardless of mailbox count. Email forgives neglect less than any other service.

Where we do operate, we check deliverability before selecting software: IP range, reverse DNS, existing domain reputation. That check decides the outcome more often than the choice between Mailcow and Stalwart.

In most cases we use Mailcow, because calendars and webmail come with it and the stack is proven at typical company scale. We use Stalwart where resources are tight and the team is technically led.

And a move includes settling archiving with us before the first mailbox is transferred.

Further guides

• Managed open source - setup and operation of open-source applications
• Managed operations - monitoring, backup and incident response
• Compliance in operations - retention and evidence requirements
• Nextcloud - files and collaboration alongside email

Unclear whether your own mail server fits you? We check deliverability, ownership and retention before any software is selected. Book a call

Sources

• Mailcow on GitHub
• Stalwart on GitHub
• Mailu on GitHub
• Mailcow: documentation
• Stalwart: documentation
• imapsync: project site