Die Antwort hängt nicht an einer Feature-Liste. Sie hängt an einer Architekturentscheidung, die ein Preisschild trägt.

Was bauen wir?

Nichts – wir entscheiden. Am Ende dieses Artikels weißt du, welchen der beiden Mailserver du aufsetzt und warum der andere für deinen Fall der falsche wäre.

Die Ausgangslage in Zahlen, nachgemessen statt geschätzt:

Der Satz, auf den alles hinausläuft, steht in der dritten Zeile. Beide lassen sich hinter den gemeinsamen Traefik stellen – das ist kein Unterscheidungsmerkmal, auch wenn man das oft liest. Was sie unterscheidet, ist der Preis dafür: Stalwart ist ein Container neben allem anderen und begnügt sich im Leerlauf mit 46 MiB. Mailcow sind achtzehn, und sein Minimum von 6 GB RAM musst du neben allem haben, was auf der Maschine sonst noch läuft.

Das ist keine Empfehlung gegen Mailcow. Es ist die Rechnung, die du vor der Entscheidung aufmachen solltest – denn meistens endet sie bei einem zweiten Server für 14 bis 27 Euro im Monat.

Voraussetzungen

Für diesen Artikel brauchst du nur eines: eine Domain, deren DNS du selbst steuerst. Einen laufenden Server setzen wir ausdrücklich nicht voraus – wer hier liest, entscheidet noch.

Zwei Dinge gelten für beide Lösungen gleichermaßen und taugen deshalb nicht zur Unterscheidung, kosten dich aber in jedem Fall Zeit:

• Zustellbarkeit. Ob deine Mails ankommen oder im Spam landen, entscheiden PTR, SPF, DKIM und DMARC – nicht die Software. Das ist Thema des Rezepts zur E-Mail-Zustellbarkeit und der eigentliche Grund, warum ein eigener Mailserver Arbeit macht.
• Ausgehendes SMTP. Bei netcup sperrt die Default-Policy „netcup Mail block" die Ports 25, 465 und 587 nach außen. Die nimmst du dem Server im SCP selbst ab, ganz ohne Support-Ticket, siehe netcup-Firewall einrichten.

Schritt für Schritt

Jeder der folgenden Schritte ist eine Entscheidungsdimension. Wenn eine davon für dich den Ausschlag gibt, kannst du den Rest überspringen – die Tabelle in Schritt 6 fasst alles zusammen.

Schritt 1: Die Architektur – ein Container oder achtzehn

Stalwart ist ein einziger, in Rust geschriebener Prozess. In diesem einen Binary stecken SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV, WebDAV, Sieve, ein Spam- und Phishing-Filter und der Datenspeicher (RocksDB). Das Image ist entsprechend klein:

docker pull stalwartlabs/stalwart:v0.16.25
docker image ls stalwartlabs/stalwart

REPOSITORY              TAG        SIZE
stalwartlabs/stalwart   v0.16.25   407MB

Im Leerlauf – frisch gestartet, ohne Postfächer – belegte der Container bei uns 46 MiB RAM bei 0 % CPU. Nimm diesen Wert als Untergrenze, nicht als Betriebswert: Mit echten Postfächern wachsen der RocksDB-Cache und die Trainingsdaten des Spam-Klassifizierers, und der Volltext-Index kommt dazu. Die Größenordnung stimmt trotzdem, und sie ist der Grund, warum Stalwart auf einem Server mitläuft, der schon etwas anderes tut.

Mailcow ist das Gegenteil, und zwar bewusst. Der Stack besteht aus 18 Diensten, die der docker-compose.yml des Projekts entnommen sind:

unbound        mysql          redis          clamd
rspamd         php-fpm        sogo           dovecot
postfix        postfix-tlspol memcached      nginx
acme           netfilter      watchdog       dockerapi
olefy          ofelia

Diese Liste ist kein Wildwuchs, sondern die Rechnung für den Funktionsumfang. sogo ist die Webmail samt Kalender, clamd und olefy sind Virenscanner und Makro-Prüfer, unbound ein eigener DNS-Resolver, watchdog und ofelia übernehmen Überwachung und Cronjobs. Jedes dieser Teile ist ein ausgereiftes Spezialwerkzeug, und Postfix und Dovecot gehören zu den am besten abgehangenen Serverprogrammen überhaupt.

Der Unterschied ist nicht Qualität, sondern Anzahl der beweglichen Teile, für die du geradestehst. Bei Stalwart ist es eines.

Schritt 2: Was es kostet, neben einen Reverse Proxy zu ziehen

Hier hält sich eine Behauptung, die wir selbst lange mitgetragen haben: Mailcow könne nicht hinter einem gemeinsamen Traefik laufen, weil sein eigener nginx die Ports 80 und 443 belegt. Das stimmt nur für die Standardkonfiguration. Mailcow dokumentiert den Weg dahinter ausdrücklich – man bindet seinen nginx auf einen lokalen Port um und nimmt ihm das Zertifikat ab:

HTTP_BIND=127.0.0.1
HTTP_PORT=8080
HTTPS_BIND=127.0.0.1
HTTPS_PORT=8443
SKIP_LETS_ENCRYPT=y
AUTODISCOVER_SAN=n

Beide können also hinter denselben Proxy. Der Unterschied ist, was dich das kostet.

Bei Mailcow sind es die sechs Schalter oben, drei Traefik-Router (Oberfläche, autoconfig, autodiscover) – und ein Detail, das man kennen muss: Postfix und Dovecot lesen ihr Zertifikat nur beim Start. Der Dumper muss sie deshalb nach jeder Verlängerung neu starten:

certdumper:
  image: ghcr.io/kereis/traefik-certs-dumper:1.8.28
  command: --restart-containers mailcowdockerized-postfix-mailcow-1,mailcowdockerized-dovecot-mailcow-1
  environment:
    DOMAIN: mail.DEINE_DOMAIN   # schreibt cert.pem/key.pem flach, wie Mailcow sie erwartet
  volumes:
    - /opt/traefik/:/traefik:ro
    - /var/run/docker.sock:/var/run/docker.sock:ro
    - ./data/assets/ssl:/output:rw

Zwei Stellen weichen bewusst von mailcows eigener Vorlage ab. Die Containernamen dort (mailcow_postfix-mailcow_1) stammen aus dem alten Compose v1; ein aktuelles Docker benennt die Container mailcowdockerized-…-1, und mit den alten Namen findet der Dumper nichts zum Neustarten. Und den Docker-Socket braucht er, um überhaupt neu starten zu dürfen.

Dazu kommt, dass mailcow diese Seite selbst als „community supported" kennzeichnet – sie trägt einen Warnkasten. Das ist kein Ausschlusskriterium, aber ein Unterschied zu einem Pfad, den der Hersteller trägt.

Zwei Dinge bleiben unabhängig davon:

1. Die Mail-Ports 25, 465, 587, 143, 993, 110, 995 und 4190 liegen weiter direkt am Host – bei beiden Lösungen gleichermaßen.
2. Auf Hosts mit IPv6 legt generate_config.sh eine /etc/docker/daemon.json an und startet Docker sofort neu. Auf einem geteilten Server reißt dieser Neustart alles andere mit. Das passiert einmal beim Aufsetzen, aber es passiert.

Und dann ist da der Punkt, der in der Praxis meistens entscheidet und nichts mit Ports zu tun hat: 6 GB RAM als Minimum, mit ClamAV eher 8. Die musst du neben allem haben, was auf der Maschine schon läuft. Ein VPS 1000 mit 8 GB ist damit faktisch voll. Deshalb landet man bei Mailcow am Ende doch oft bei einem zweiten Server – nicht weil es nicht anders ginge, sondern weil der Speicher nicht reicht.

Stalwart dagegen zieht mit 46 MiB im Leerlauf nebenher ein. Einen Haken scheint es zu geben: Stalwart holt sein Let’s-Encrypt-Zertifikat standardmäßig per TLS-ALPN-01 über Port 443, und den hat dein Proxy längst. Dafür gibt es eine saubere Lösung, und sie steht so in Stalwarts eigener Dokumentation: Stalwart holt gar kein Zertifikat mehr, sondern bekommt das von Traefik.

Dazwischen steht ein winziger Container, der Zertifikat und Schlüssel aus Traefiks acme.json in ein gemeinsames Volume schreibt:

services:
  traefik-certs-dumper:
    image: ghcr.io/kereis/traefik-certs-dumper:1.8.28
    restart: always
    command: --restart-containers stalwart
    environment:
      OVERRIDE_UID: 2000      # Stalwart laeuft im Container als uid 2000
      OVERRIDE_GID: 2000
    volumes:
      - /opt/traefik/:/traefik:ro      # dort liegt acme.json aus dem Traefik-Rezept
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - certs:/output

Der Dumper sucht acme.json direkt unter /traefik. Eingebunden wird deshalb das Verzeichnis, in dem Traefiks acme.json liegt – im Traefik-Rezept ist das /opt/traefik/. Zeigt der Pfad daneben, legt Docker stillschweigend ein leeres Verzeichnis an, der Dumper meldet im Log nur /traefik/acme.json is not a file. Retrying..., und Stalwart bekommt nie ein Zertifikat.

Die beiden OVERRIDE-Zeilen sind kein Beiwerk: Der Dumper legt key.pem mit Rechten 0640 ab, und Stalwart läuft im Container als uid 2000. Ohne die Übergabe des Besitzers kommt es an seinen eigenen Schlüssel nicht heran.

Stalwart bindet dasselbe Volume nur lesend ein (certs:/data/certs:ro), braucht für den Neustart den festen Namen container_name: stalwart, hängt mit den üblichen Traefik-Labels an der Weboberfläche und veröffentlicht die Mail-Ports direkt am Container. Im Einrichtungs-Assistenten schaltest du „Automatically Obtain TLS Certificate" ab – sonst versucht Stalwart weiter, sich selbst eines zu holen. Danach zeigst du in der Konsole unter Settings → TLS → Certificates auf die beiden Dateien – in der Oberfläche heißen die Typen Text value read from file und Secret read from file:

{
  "certificate": { "@type": "File", "filePath": "/data/certs/mail.DEINE_DOMAIN/cert.pem" },
  "privateKey":  { "@type": "File", "filePath": "/data/certs/mail.DEINE_DOMAIN/key.pem" }
}

Stalwart zeigt das Zertifikat danach sofort in der Liste an, ausgeliefert wird es aber erst nach einem Neustart (docker compose restart stalwart). Bis dahin bekommt ein Mailprogramm weiter das selbstsignierte Platzhalter-Zertifikat CN=rcgen self signed cert.

Aus demselben Grund steht im Dumper --restart-containers stalwart: Stalwart liest die Dateien nur beim Start. Erneuert Traefik das Zertifikat, schreibt der Dumper die neuen Dateien und startet Stalwart neu – das dauert wenige Sekunden. Ohne die Zeile liefe Stalwart nach der ersten Verlängerung mit dem alten Zertifikat weiter, bis es 90 Tage später abläuft. Der Docker-Socket ist dabei auch mit :ro ein Vollzugriff auf Docker – der Dumper gehört damit in dieselbe Vertrauensklasse wie Traefik, das den Socket ebenfalls hat. Die Aktion Reload → TLS certificates in der Konsole wäre die Alternative, antwortete in der Community-Edition bei uns aber mit API error 403.

Das ist eleganter als die DNS-01-Challenge, die man hier zuerst vermutet: Du brauchst keine API-Zugangsdaten bei deinem DNS-Anbieter, und auf dem Host bleibt ein einziger ACME-Client – der, den du ohnehin betreibst.

Wir haben das auf dem Test-VPS nachgebaut, neben dem dort dauerhaft laufenden Traefik, und eine Verlängerung simuliert: Traefik schreibt acme.json, der Dumper zieht nach und startet Stalwart neu. Stalwart liefert anschließend auf seinen eigenen Mail-Ports das Zertifikat aus, das es nie selbst beantragt hat – hier der Handshake auf dem IMAPS-Port:

subject=CN=mail.DEINE_DOMAIN
issuer=C=US, O=Let's Encrypt, CN=YR2
Verify return code: 0 (ok)

Wird es Stalwart und hast du noch gar keinen Server, reicht eine Nummer kleiner; die Tarife stehen in der netcup-Übersicht, und was dein konkretes Setup braucht, schätzt der Server-Rechner.

Schritt 3: Aufwand beim Aufsetzen und im Betrieb

Die Zahlen aus den beiden Rezepten sprechen für sich: Stalwart ist in rund 60 Minuten und sieben Schritten fertig und als Fortgeschritten eingestuft, Mailcow braucht etwa 90 Minuten, acht Schritte und gilt als Profi-Thema.

Interessanter ist, was danach kommt. Ein Update sieht bei Stalwart so aus:

cd /opt/stalwart
docker compose pull && docker compose up -d

Bei Mailcow so:

cd /opt/mailcow-dockerized
sudo ./update.sh

Das Skript zieht die Compose-Datei nach, aktualisiert alle Images und startet den Stack neu. Es nimmt dir Arbeit ab – und es ändert in einem Durchgang 18 Dienste auf einmal.

Die Rhythmen unterscheiden sich deutlich, und beide verlangen Aufmerksamkeit. Stalwart hat zwischen dem 12. Juli und dem 5. Oktober dreizehn Releases veröffentlicht, also ungefähr wöchentlich; du entscheidest bei jedem, ob du ihn mitnimmst, und bleibst dafür auf einem festen Versions-Tag. Mailcow kam im selben Jahr auf dreizehn Veröffentlichungen zwischen Januar und Anfang Oktober, also grob monatlich, hat aber gar keine Versionsnummer im klassischen Sinn: Es ist ein Rolling Release mit Monats-Tags, und update.sh holt immer den aktuellen Stand.

Keiner der beiden ist ein „einmal aufsetzen und vergessen". Stalwart lässt dir mehr Kontrolle darüber, wann etwas passiert; Mailcow nimmt dir die Einzelentscheidungen ab.

Schritt 4: Funktionsumfang – was Mailcow hat und Stalwart nicht

Hier hält sich ein Missverständnis hartnäckig, und es lohnt sich, es zuerst aus dem Weg zu räumen: Stalwart kann Kalender und Kontakte. CalDAV, CardDAV und WebDAV sind vollständig an Bord, und zwar in der kostenlosen Community-Edition. „Ich will Termine und Adressbuch auf demselben Server" ist also keine Entscheidungsfrage mehr.

Der echte Unterschied ist der Browser.

Mailcow liefert mit SOGo eine fertige Weboberfläche für Mail, Kalender und Kontakte. Du meldest dich auf einem beliebigen Rechner an und bist drin. Stalwarts Weboberfläche ist etwas anderes: eine Administrationskonsole plus ein kleines Selbstbedienungsportal, in dem Nutzer ihr Passwort, ihre App-Passwörter und die Zwei-Faktor-Anmeldung verwalten. Ein Webmailer ist nicht dabei.

Praktisch heißt das: Mit Stalwart braucht jeder Nutzer ein Mailprogramm – Thunderbird, die Mail-App auf iOS und macOS, DAVx5 auf Android für Kalender und Kontakte. Für dich allein oder im Haushalt ist das völlig in Ordnung, weil diese Programme ohnehin eingerichtet sind. Sobald aber jemand von einem fremden Rechner an seine Post muss, fehlt dir etwas. Du kannst eine Webmail wie Roundcube daneben stellen – dann ist es eben Container Nummer zwei.

Der zweite Unterschied: Mailcow bringt mit ClamAV einen Virenscanner mit, Stalwart nicht. Stalwarts eingebauter Filter deckt Spam und Phishing ab; einen Virenscanner kannst du über Milter oder MTA-Hooks anbinden, musst ihn aber selbst betreiben.

Schritt 5: Angriffsfläche, Lizenz und Updates

Das Sicherheitsargument für Stalwart wird oft zu groß erzählt. Rust bringt Speichersicherheit mit, und Stalwart hat ein veröffentlichtes Security-Audit vorzuweisen. Daraus folgt aber nicht, dass Postfix und Dovecot unsicher wären – sie gehören zu den am gründlichsten geprüften Programmen im Internet überhaupt.

Das tragfähige Argument ist nüchterner: Es geht um die Länge der Update-Kette. Achtzehn Dienste bedeuten achtzehn Projekte mit eigenen Sicherheitsmeldungen, die jemand aufeinander abstimmen muss. Dass mailcow genau das zuverlässig tut, ist der eigentliche Wert des Projekts – aber es ist eine Abhängigkeit, die du eingehst.

Bei den Lizenzen dreht sich das Bild, und das wird selten erwähnt. Mailcow steht komplett unter GPL-3.0 – alles, was es kann, kannst du kostenlos nutzen. Stalwart ist doppelt lizenziert: die Community-Edition unter AGPL-3.0, daneben eine kommerzielle Enterprise-Lizenz. Beide Editionen teilen sich dieselbe Codebasis und, wie der Hersteller selbst schreibt, dieselben Protokolle und Kernfunktionen. Was die Enterprise-Edition zusätzlich bietet, ist Betriebswerkzeug für große Installationen: Mandantenfähigkeit, eigenes Branding, Archivierung und Wiederherstellung gelöschter Postfächer, ein KI-gestützter Spam-Klassifizierer, Read Replicas.

Für einen Haushalt oder die eigene Firmendomain ist davon nichts relevant. Eine Falle steckt trotzdem darin: Die große Feature-Liste auf GitHub markiert nicht, welcher Punkt zu welcher Edition gehört. Wenn du dich auf eine bestimmte Funktion verlässt, sieh vorher in der Editionsübersicht nach, statt der README zu vertrauen.

Schritt 6: Die Entscheidungstabelle

Und wenn dich beim Lesen beschlichen hat, dass du eigentlich keines von beidem pflegen willst: Ein seriöser Mail-Hoster ist eine vollkommen legitime Antwort auf diese Frage. Zustellbarkeit und Reputation sind Dauerarbeit, und die bleibt bei dir – unabhängig davon, welche Software du wählst.

Wenn es nicht funktioniert

Die ersten beiden Punkte betreffen jede selbst betriebene Lösung und kosten die meiste Zeit, wenn man sie nicht kennt.

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

Der Pflegeaufwand unterscheidet sich weniger, als die Containerzahl vermuten lässt – nur verteilt er sich anders.

Updates nimmst du bei Stalwart einzeln und bewusst mit, indem du den Versions-Tag hochziehst; plane dafür etwa einmal im Monat einen Blick in die Release-Notes ein, auch wenn wöchentlich etwas erscheint. Bei Mailcow läuft update.sh monatlich und erledigt alles auf einmal; lies die angezeigten Hinweise, dort stehen bei größeren Sprüngen gelegentlich manuelle Schritte.

Backups sind bei Stalwart schlicht: zwei Volumes, stalwart_config und stalwart_data, und für einen konsistenten Stand stoppst du den Container kurz. Mailcow bringt ein eigenes backup_and_restore.sh mit, das die vielen Volumes und die Datenbank zusammenfasst. In beiden Fällen gehört das Ergebnis weg vom Server, am saubersten verschlüsselt mit restic.

Besonders wichtig sind in beiden Fällen die DKIM-Schlüssel: Gehen sie verloren, brechen nach einer Wiederherstellung deine Signaturen, bis du die DNS-Records neu setzt. Und ein Backup, das du nie zurückgespielt hast, ist nur ein Hoffnungswert – teste die Wiederherstellung einmal auf einem Testsystem.

Reputation behältst du unabhängig von der Software im Blick: Prüfe gelegentlich, ob deine Server-IP auf einer Blockliste gelandet ist. Ein kompromittiertes Postfach, das Spam verschickt, ruiniert die Reputation deiner ganzen Domain schnell – und das ist die einzige Aufgabe, die dir keiner der beiden Mailserver abnimmt.