Mailcow vs. Stalwart – und warum ich mich für Stalwart entschieden habe

„Betreib bloß keinen eigenen Mailserver.“ Diesen Satz hört man in jedem Forum, sobald jemand das Thema anspricht. Und ganz falsch ist er nicht: E-Mail ist eines der ältesten Protokolle im Netz, voller Altlasten, und die großen Anbieter sind misstrauisch gegenüber jedem, den sie nicht kennen.

Ich habe es trotzdem gemacht. Meine erste eigene Installation lief mit Mailcow, inzwischen habe ich mich für Stalwart entschieden. In diesem Beitrag vergleiche ich beide ehrlich – mit dem Stand von Oktober 2026 – und erkläre, warum meine Wahl so ausgefallen ist. Spoiler: Es gibt gute Gründe für beide.

Zwei Philosophien

Beide Projekte wollen dasselbe: einen vollständigen Mailserver, den man selbst betreibt. Der Weg dahin könnte aber kaum unterschiedlicher sein.

Mailcow ist ein Bausatz aus bewährten Einzelteilen. Postfix nimmt Mails an und verschickt sie, Dovecot verwaltet die Postfächer, Rspamd filtert Spam, ClamAV sucht nach Viren, SOGo liefert Webmail, Kalender und Kontakte. Dazu kommen MariaDB, Redis, Nginx, ein eigener DNS-Resolver und eine Admin-Oberfläche in PHP. Jedes dieser Teile läuft in einem eigenen Docker-Container, zusammengehalten von Docker Compose. Insgesamt sind es rund fünfzehn Container.

Stalwart geht den umgekehrten Weg: ein einziges Programm, geschrieben in Rust. SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV, WebDAV, Spamfilter, Zertifikatsverwaltung, Speicher und Volltextsuche – alles in einem Binary. Kein Zusammenspiel von Komponenten, die sich gegenseitig konfigurieren müssen.

Man könnte sagen: Mailcow ist eine gut eingespielte Band. Stalwart ist ein Solokünstler, der alle Instrumente selbst spielt.

Der Vergleich

Wo Mailcow glänzt

Es ist alles da. Nach der Installation hat man Webmail, Kalender, Kontakte, Virenscanner und Spamfilter. Mit SOGo gibt es sogar ActiveSync für Handys, die lieber Exchange sprechen.

Es ist erprobt. Postfix und Dovecot sind seit Jahrzehnten das Rückgrat unzähliger Mailserver. Jede Fehlermeldung hat schon jemand vor dir gegoogelt. Die Dokumentation ist umfangreich, die Community groß.

Es wird gepflegt. Neue Versionen erscheinen etwa monatlich, Sicherheitsupdates zügig. Das Update-Skript nimmt einem viel Arbeit ab. Und hinter dem Projekt steht ein Unternehmen aus Deutschland – für manche durchaus ein Argument.

Wo Mailcow wehtut

Hunger. Mindestens 6 GiB RAM sind offiziell gefordert, für eine Handvoll Nutzer werden 8 GiB empfohlen. Allein SOGo startet standardmäßig 20 Worker, und jeder davon kann gut 350 MiB belegen. ClamAV und die Volltextsuche sind ebenfalls nicht genügsam. Man kann sie abschalten – aber dann fehlt eben auch etwas.

Ehrliche Beichte: Meine erste Mailcow-Installation lief auf einem VPS mit 4 GB. Das ging – aber es war nie entspannt.

Viele bewegliche Teile. Fünfzehn Container heißt fünfzehn Stellen, an denen etwas klemmen kann. Wenn ein Update hakt, sucht man erst einmal, welcher Container schuld ist. Dazu kommt, dass Mailcow sich ungern auf etwas anderes als eine vollwertige VM setzen lässt: LXC-Container in Proxmox etwa werden ausdrücklich nicht unterstützt.

Viel Altlast unter der Haube. Das ist kein Vorwurf, sondern die Kehrseite von „erprobt“: Postfix, Dovecot und Rspamd haben jeweils ihre eigene Konfigurationssprache, ihre eigenen Logs und ihre eigenen Eigenheiten. Mailcow versteckt vieles davon geschickt. Aber wenn man doch einmal tiefer muss, muss man alles verstehen.

Wo Stalwart glänzt

Schlank. Rund 100 MB Arbeitsspeicher im Leerlauf. Ein Gigabyte reicht für einen kleinen Haushalt oder Verein. Für mich, der auf einem Proxmox-Host viele Dienste nebeneinander betreibt, ist das ein riesiger Unterschied.

Ein Teil, ein Log, eine Konfiguration. Kein Rätselraten, welche Komponente gerade schuld ist. Ein Dienst, eine Konfiguration, eine Weboberfläche für alles.

Modern. Stalwart spricht JMAP, den modernen Nachfolger von IMAP. JMAP arbeitet mit JSON über HTTP, ist effizienter und deutlich angenehmer für alle, die eigene Werkzeuge bauen wollen. Stalwart besteht die komplette offizielle JMAP-Testsuite. Dazu kommen Dinge wie OIDC-Login, eine eigene Kommandozeile und eine Verwaltung, die selbst über JMAP läuft.

Flexibler Speicher. Für eine einzelne Maschine reicht das eingebaute RocksDB. Wer größer denkt, kann PostgreSQL, S3-kompatiblen Speicher oder Cluster nutzen – ohne das Produkt zu wechseln.

Rust. Für einen Dienst, der Tag und Nacht ungefilterte Daten aus dem Internet annimmt, ist eine speichersichere Sprache ein echtes Sicherheitsargument. Ganze Fehlerklassen, die bei C-Programmen immer wieder zu Sicherheitslücken führen, gibt es hier schlicht nicht.

Saubere Migration. Für den Umzug von einem bestehenden Server gibt es einen Migrations-Proxy: Der neue Server übernimmt sofort den Mailempfang, und die Konten wandern einzeln herüber – mit Rückweg, falls etwas schiefgeht. Die Mail-Clients merken davon kaum etwas.

Wo Stalwart (noch) wehtut

Es ist 0.x. Aktuell ist die Versionsreihe 0.16. Die Entwickler arbeiten auf 1.0 hin und wollen dafür vor allem das Datenbankschema endgültig festzurren. Bis dahin können Updates noch Handarbeit verlangen. Ein Beispiel aus dem August: Wer Stalwart mit MySQL oder MariaDB betreibt, musste bei einem Update selbst ALTER TABLE-Befehle ausführen. Wer RocksDB nutzt, war nicht betroffen – trotzdem gilt: Vor jedem Update die Release Notes lesen.

Kein Webmail. Ein eigenes Webmail ist geplant, aber erst nach Version 1.0. Bis dahin braucht man etwas Zusätzliches, zum Beispiel Roundcube oder SnappyMail. Wer seinen Nutzern „einfach im Browser Mails lesen“ versprechen will, hat also eine Komponente mehr.

Kein eingebauter Virenscanner. Wer Anhänge scannen will, muss ClamAV oder Ähnliches selbst anbinden.

Open Core. Die Community-Edition steht unter AGPL-3.0 und kann alles, was man für einen privaten Server oder einen Verein braucht. Einige Funktionen gibt es aber nur in der kostenpflichtigen Enterprise-Edition, etwa Mandantenfähigkeit, Archivierung und Wiederherstellung gelöschter Mails oder das KI-gestützte Spam-Filtern. Die Entwickler versprechen, dass bestehende Open-Source-Funktionen nicht hinter eine Bezahlschranke wandern. Man sollte es trotzdem wissen.

Kleinere Community. Weniger Forenbeiträge, weniger Anleitungen, weniger „hatte ich auch schon“. Wer nicht weiterkommt, landet schneller im offiziellen Support-Forum oder auf GitHub.

Was für beide gleich ist

Kein Mailserver der Welt nimmt einem die eigentliche Arbeit ab: dafür zu sorgen, dass die großen Anbieter einem vertrauen.

• Port 25 ausgehend: Viele VPS-Anbieter sperren ihn standardmäßig. Vor der Installation prüfen, sonst wundert man sich lange.
• Reverse DNS (PTR): Die IP-Adresse muss auf den Hostnamen des Mailservers zurückzeigen. Und zwar für IPv4 und IPv6. Ich habe das selbst lernen müssen: Gmail hat meine Mails abgelehnt, bis der PTR-Eintrag für die konkrete IPv6-Adresse gesetzt war – nicht nur für das Netz drumherum.
• SPF, DKIM, DMARC: Ohne diese drei landet man im Spam oder wird gleich abgelehnt. Beide Systeme erzeugen die DKIM-Schlüssel und zeigen die nötigen DNS-Einträge an. Eintragen muss man sie selbst.
• MTA-STS und TLS-RPT: Optional, aber empfehlenswert. Beide Systeme unterstützen sie.
• Reputation braucht Zeit. Eine frische IP-Adresse hat keinen Ruf. Auch eine perfekte Konfiguration kann anfangs im Spamordner landen.

Meine Entscheidung

Ich habe mich für Stalwart entschieden. Die Gründe:

1. Ressourcen. In meinem kleinen Rechenzentrum laufen viele Dienste nebeneinander. Ein Mailserver, der sich mit einem Gigabyte zufriedengibt, statt sechs zu fordern, macht Platz für alles andere.
2. Übersicht. Ein Programm statt fünfzehn Container – das passt zu meiner Art, Dinge zu betreiben: Ich will verstehen, was läuft.
3. JMAP. Ich baue gern eigene Werkzeuge. Ein Mailserver, mit dem man sauber über JSON sprechen kann, ist dafür eine viel bessere Grundlage als IMAP.
4. Webmail brauche ich kaum. Ich lese Mails auf dem Handy und am Rechner. Für die seltenen Fälle reicht ein schlankes Webmail nebenher.
5. Ich mag es, früh dabei zu sein. Dass Stalwart noch vor 1.0 steht, ist für mich kein Ausschlusskriterium. Ich lese Release Notes, mache vor Updates einen Snapshot der VM und pinne die Version, statt blind die neueste zu ziehen.

Wer sollte was nehmen?

Nimm Mailcow, wenn …

• du eine Komplettlösung mit Webmail, Kalender und Virenscanner sofort und ohne Zusatzarbeit willst,
• du Nutzer betreust, die einfach nur funktionierende Mail wollen,
• du genug RAM übrig hast,
• dir Reife und eine große Community wichtiger sind als Schlankheit.

Nimm Stalwart, wenn …

• dein Server knapp bemessen ist oder viele andere Dienste trägt,
• du ein modernes, einheitliches System willst statt eines Komponenten-Zoos,
• dich JMAP interessiert oder du eigene Werkzeuge anbinden willst,
• du mit einer 0.x-Version und gelegentlicher Handarbeit bei Updates leben kannst.

Fazit

Mailcow ist der bewährte Familienkombi: geräumig, zuverlässig, aber durstig. Stalwart ist der leichte Elektroflitzer: modern, sparsam, schnell – aber die Ladeinfrastruktur wird gerade noch gebaut.

Beide bringen dich ans Ziel. Für die Frickelfabrik ist es der Flitzer geworden.

Wie die Installation Schritt für Schritt geht, steht im Tutorial: Stalwart installieren – vom leeren Server zur ersten Mail.

Stand: Oktober 2026. Beide Projekte entwickeln sich schnell, insbesondere Stalwart auf dem Weg zu Version 1.0. Zahlen zu Arbeitsspeicher und Funktionen stammen aus den offiziellen Dokumentationen und Release Notes.

Quellen: Mailcow – Systemvoraussetzungen · Mailcow Release 2026-07a · Stalwart – Der Weg zu 1.0 · Stalwart – Roadmap und Webmail · Stalwart – Community vs. Enterprise · Stalwart – Migrationsleitfaden · Stalwart v0.16.19 Release Notes