Ein eigener Mailserver ist selten ein „Nice-to-have“: In vielen Organisationen hängen Identitäten, Passwort-Resets, Ticket-Systeme und Vertragskommunikation an zuverlässiger Zustellung. Gleichzeitig sind E-Mail-Setups anfällig für Fehlkonfigurationen, Blacklisting und zähe Debug-Sessions. Zwei etablierte Projekte liefern dafür pragmatische Komplett-Stacks: Mailcow und Mailu. Beide setzen auf Container, bündeln die üblichen Komponenten (MTA, IMAP, Webmail, Spam-/Virusfilter) und zielen auf reproduzierbaren Betrieb.
Der Mehrwert entsteht weniger durch „Features“, sondern durch klare Betriebsentscheidungen: Wie werden Updates gefahren? Wie werden DKIM/SPF/DMARC gepflegt? Wie werden Logs, Backups und TLS-Zertifikate gehandhabt? Der folgende Vergleich ordnet die Projekte für den produktiven Einsatz ein – mit Blick auf Open-Source-E-Mail-Server als Betriebskategorie, nicht als Bastelprojekt.
Welche Anforderungen entscheiden bei einem selbst gehosteten Mailserver?
Zustellbarkeit ist ein Betriebskriterium, kein Add-on
Wer Mails versendet, muss Reputation aufbauen und Fehlerquellen minimieren. Entscheidend sind korrekt gesetzte DNS-Einträge (A/AAAA, PTR/rDNS, MX) sowie Authentifizierungsmechanismen: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) und DMARC (Policy- und Reporting-Layer). Ohne diese Grundlagen sind Probleme vorprogrammiert – unabhängig davon, ob der Stack Mailcow oder Mailu heißt.
In der Praxis gilt: Ein stabiler Provider für den Serverstandort, konsistente IP-Adressen, funktionierendes rDNS und ein durchdachter „Outbound“-Pfad sind oft wichtiger als die Wahl der Weboberfläche.
Wartung, Notfallbetrieb und Dokumentation
Ein Mailserver ist ein dauerhaft exponierter Dienst. Regelmäßige Updates, zeitnahes Patchen und nachvollziehbare Konfiguration sind Pflicht. Bei containerisierten Stacks verschiebt sich das Risiko: weniger Paket-Chaos im Hostsystem, dafür Abhängigkeit von Image-Updates, Compose-Änderungen und Projekt-Releasezyklen.
Wer das Setup in einer Organisation betreibt, sollte zusätzlich festlegen: Wo liegen Secrets? Wie werden Admin-Zugänge geschützt? Wie sieht ein Restore-Test aus? Wer darf Domains anlegen oder Alias-Regeln ändern? Gerade diese Governance-Fragen sind im Alltag oft der Unterschied zwischen „läuft“ und „niemand traut sich ran“.
Mailcow und Mailu: Architektur und Betriebsmodell im Vergleich
Gemeinsamkeiten: Container-Stack mit klaren Bausteinen
Beide Projekte nutzen ein Compose-basiertes Setup, das typische Mail-Komponenten orchestriert. In beiden Fällen wird der Betrieb stark vereinfacht, weil die meisten Abhängigkeiten im Stack enthalten sind: SMTP (Versand/Annahme), IMAP (Mailbox-Zugriff), Webmail, Antispam/Antivirus, TLS-Zertifikatsmanagement und ein Admin-UI. Das reduziert den Aufwand gegenüber „klassischen“ Installationen, bei denen Postfix/Dovecot/Rspamd/Amavis/ClamAV & Co. einzeln gepflegt werden.
Unterschiede: Bedienphilosophie, Update-Pfade, Anpassbarkeit
Mailcow setzt stark auf ein integriertes, funktionsreiches Admin-Interface und liefert viele Features „out of the box“. Das ist attraktiv für Teams, die schnell produktiv sein wollen und Routineaufgaben (Mailboxen, Aliase, Quotas, Policies) zentral steuern möchten.
Mailu ist modularer gedacht und wird häufig als schlanker, gut komponierbarer Stack wahrgenommen. Anpassungen sind gut möglich, setzen aber eher voraus, dass das Team sich mit Compose-Parametern, Reverse-Proxies und DNS/TLS-Details wohlfühlt.
Für beide gilt: Der Kern ist weniger die Oberfläche, sondern wie gut der Stack zu den eigenen Betriebsprozessen passt. Wer etwa strenge Trennung von Rollen oder externe Authentifizierung plant, sollte vorab prüfen, wie das jeweilige Projekt das abbildet (und ob es dafür stabile, dokumentierte Wege gibt).
Lizenz, Offenheit und Lieferkette: worauf beim Einsatz zu achten ist
Lizenzen verstehen und in der Organisation sauber dokumentieren
Ein Mailserver-Stack ist ein Verbund mehrerer Komponenten mit unterschiedlichen Lizenzen. Für die Nutzung im eigenen Betrieb ist das meist unkritisch, solange keine Weiterverteilung als Produkt erfolgt. Dennoch lohnt sich ein Mindestmaß an Dokumentation: Welche Images/Komponenten werden eingesetzt, in welchen Versionen, und welche Lizenztexte gehören dazu? Dafür hat sich die Praxis etabliert, Artefakte und Abhängigkeiten in einer internen Übersicht festzuhalten.
Das Thema wird besonders relevant, wenn der Stack Teil eines Angebots wird (Managed Service, Appliance, Weitergabe an Kunden) oder wenn eigene Anpassungen verteilt werden. Dann spielen Copyleft-Pflichten, Attribution und Lizenzkompatibilität eine praktische Rolle. Für eine strukturierte Herangehensweise hilft der Blick auf Open-Source-Compliance im Alltag.
Container-Images sind Teil der Supply Chain
Der Sicherheits- und Wartungsaufwand endet nicht an der Grenze des Git-Repos. Container-Stacks ziehen Images, oft aus registrierten Quellen, und aktualisieren Komponenten in BĂĽndeln. Das vereinfacht Updates, kann aber auch bedeuten, dass viele Sub-Komponenten gleichzeitig wechseln. Wichtig ist daher ein kontrollierter Update-Prozess: Changelogs lesen, Wartungsfenster definieren, Konfigurationen versionieren und ein Rollback-Szenario parat haben.
Wer organisatorisch bereits mit SBOM (Software Bill of Materials) oder ähnlichen Praktiken arbeitet, kann diese Denkweise auf den Mailstack übertragen: Welche Bestandteile laufen produktiv, welche sind extern bezogen, wie schnell werden Sicherheitsupdates übernommen? Für den breiteren Kontext lohnt ein Abgleich mit Werkzeugen für die Software-Lieferkette.
Alltagsbetrieb: Sicherheit, Backups, Monitoring und Zustellung
Absicherung: Admin-Zugänge, TLS und minimale Angriffsfläche
Ein häufiger Fehler ist die Überschätzung von „Standard-Sicherheit“. Unabhängig vom Projekt sollten Admin-Oberflächen nicht unnötig offen im Internet stehen, starke Passwörter oder SSO (wenn sauber integriert) genutzt werden, und Zugriffe auf Management-Endpunkte per VPN oder IP-Restriktion begrenzt sein. TLS-Zertifikate sollten automatisch erneuert werden; entscheidend ist, dass Renewal-Fehler sichtbar werden (Monitoring/Alerting).
Auch wichtig: konsequente Trennung von Mail- und Web-Workloads. Webmail, Admin-UI und Autodiscover-Endpunkte sind typische Ziele automatisierter Scans. Je weniger Angriffsfläche, desto weniger Incident-Last.
Backup/Restore: nicht nur Maildir kopieren
Backups müssen sowohl Nutzerdaten (Mailboxen) als auch Konfigurationen, Schlüsselmaterial (z.B. DKIM-Keys), Datenbanken (falls genutzt) und Zertifikate umfassen. Ein brauchbarer Ansatz ist ein Backup-Plan, der mindestens drei Fragen beantwortet: Was wird gesichert? Wie schnell ist ein Restore möglich? Wurde ein Restore-Test durchgeführt?
Gerade bei containerisierten Stacks sind Pfade und Volumes klar definiert – das hilft. Dennoch sollte ein Wiederanlauf nach einem Host- oder Storage-Ausfall geübt sein. Für die generelle Strategie kann die Einordnung aus Backup-Ansätzen mit BorgBackup und Restic als Denkmodell dienen (auch wenn die Tools nicht zwingend Teil des Mail-Stacks sind).
Beobachtbarkeit: Logs, Warteschlangen und Blacklist-Symptome
Im Mailbetrieb sind „symptomatische“ Metriken oft aussagekräftiger als CPU/RAM: SMTP-Queue-Länge, Ratelimits, Anzahl der Deferred-Mails, Fehlercodes beim Zustellen, Rspamd-/Spamassassin-Entscheidungen, TLS-Handshake-Probleme und Authentifizierungsfehler. Wer frühzeitig sieht, dass Mails deferred werden oder Retries steigen, kann reagieren, bevor Nutzer den Ausfall melden.
Zusätzlich sollten DMARC-Reports ausgewertet werden, um Spoofing und Fehlkonfigurationen zu erkennen. Das ist weniger ein Feature des Stacks als ein Betriebsprozess rund um DNS und Identität.
Mailcow oder Mailu: Entscheidung nach Betriebsrealität statt Feature-Liste
Wenn ein integriertes Admin-UI Priorität hat
Teams ohne tiefes Mailserver-Know-how profitieren häufig von einer Oberfläche, die die üblichen Aufgaben abbildet und Fehlbedienung reduziert. Mailcow ist in diesem Szenario oft der naheliegende Kandidat, weil viele Verwaltungsschritte direkt im UI stattfinden und der Stack als „alles dabei“-Paket gedacht ist. Das spart Zeit, sofern das Team mit den vorgesehenen Wegen arbeitet und nicht gegen das Modell ankonfiguriert.
Wenn Modularität und kontrollierte Integration wichtiger sind
Mailu passt gut, wenn ohnehin ein Reverse-Proxy-Setup, zentrale Secrets-Verwaltung oder ein standardisiertes Compose-Ökosystem existiert. In solchen Umgebungen ist die klare Trennbarkeit von Komponenten praktisch: Änderungen können gezielter erfolgen, und die Integration in bestehende Betriebsstandards (Logging, Monitoring, Netzwerksegmente) fällt oft leichter.
Eine kompakte GegenĂĽberstellung fĂĽr typische Organisationen
| Kriterium | Mailcow | Mailu |
|---|---|---|
| Einrichtung | stark geführt, viele Defaults | flexibel, teils mehr Vorwissen nötig |
| Administration | zentrales UI, viele Funktionen integriert | eher modular, Integration nach Bedarf |
| Updates | gebündelte Stack-Updates, gut planbar mit Routine | ebenfalls Stack-Updates, häufig gut in Compose-Prozesse integrierbar |
| Passend fĂĽr | kleine IT-Teams, die schnell produktiv sein wollen | Teams mit bestehender Container-/Proxy-Standardisierung |
Praktische Schritte vor dem Go-live in 60 Minuten Planung
Konkrete To-dos, die später viel Ärger sparen
- DNS sauber vorbereiten: MX, SPF, DKIM, DMARC; PTR/rDNS beim Provider prĂĽfen und fixieren.
- Testdomain nutzen und Zustellung verifizieren (eingehend/ausgehend), bevor produktive Postfächer migrieren.
- Update- und Wartungsfenster definieren; Konfigurationen versionieren (z.B. in einem privaten Git-Repo).
- Backup-Plan festlegen: Volumes, Datenbank, SchlĂĽssel, Zertifikate; Restore einmal durchspielen.
- Admin-Zugänge absichern: Management nicht unnötig öffentlich, starke Authentifizierung, Zugriffsregeln dokumentieren.
- Monitoring auf Mail-spezifische Signale ausrichten: Queue, Deferred, Bounce-Codes, TLS-Fehler, Auth-Fails.
Community, Wartung und Nachhaltigkeit realistisch bewerten
Release-Rhythmus, Issues und Support-Kanäle zählen
Für den Betrieb ist weniger wichtig, ob ein Projekt „viele Stars“ hat, sondern ob Probleme nachvollziehbar bearbeitet werden: Werden Sicherheitsupdates zügig integriert? Gibt es klare Upgrade-Hinweise? Sind Breaking Changes dokumentiert? Wie reagieren Maintainer auf reproduzierbare Bugreports? Genau hier zeigt sich, ob ein Stack langfristig tragfähig ist.
Ein sinnvoller Ansatz ist, vor der Entscheidung einige typische Issues zu prĂĽfen: Zertifikatsprobleme, IMAP-Performance, Spamfilter-Tuning, Migrationen, Major-Upgrades. Wer in der eigenen Organisation bereits Regeln fĂĽr Projektbewertung etabliert hat, kann diese Kriterien ĂĽbertragen; hilfreich ist der Blick auf Nachhaltigkeitskriterien fĂĽr Open Source im Unternehmen.
Beitrag statt Fork: kleine Verbesserungen wirken oft schneller
Wenn Anpassungen nötig werden, ist ein dauerhafter Fork selten die beste erste Wahl. Häufig reichen saubere Bugreports, reproduzierbare Tests oder kleine Dokumentations-Patches. So bleibt der Betrieb näher am Upstream, und der Update-Pfad bleibt beherrschbar. Ein Fork lohnt sich eher, wenn langfristig eigene Anforderungen gepflegt werden müssen, die nicht in das Projekt passen.
Ob Mailcow oder Mailu besser passt, entscheidet am Ende nicht die Funktionsliste, sondern der Betrieb: Update-Disziplin, DNS-Qualität, Monitoring und der Wille, Mail als kritischen Dienst zu behandeln. Dann sind beide Stacks praxistaugliche Wege zu einer unabhängigen, nachvollziehbaren E-Mail-Plattform auf Basis von Freier Software.
Quellen
- Mailcow: Projekt- und Dokumentationsseiten (Upstream)
- Mailu: Projekt- und Dokumentationsseiten (Upstream)
- SPDX: Lizenzkennungen und Kurzbezeichner
- OSI Open Source Definition: Kriterien fĂĽr Open-Source-Lizenzen
