Mailcow: Eigener Mailserver für Mittelständler

Wer sich von Microsoft Exchange oder M365 emanzipieren will und gleichzeitig die Datenhoheit über E-Mail-Verkehr behalten möchte, landet schnell bei der Frage: “Wie betreibt man heutzutage einen eigenen Mailserver, ohne in der Postfix-/Dovecot-/SpamAssassin-/ClamAV-/SOGo-/MariaDB-/Redis-Konfigurationshölle zu versinken?” Die Antwort heißt für viele DATAZONE-Kunden: Mailcow:dockerized. Es kombiniert die ausgereiften Open-Source-Komponenten in einem Compose-Stack, der sich in 30 Minuten aufsetzen lässt — und das Resultat ist seit vielen Jahren in produktiven KMU-Umgebungen bewährt. Dieser Artikel ordnet ein, wann Mailcow die richtige Wahl ist, was drin steckt, was es nicht ist — und worauf bei der Inbetriebnahme zu achten ist.

Was ist Mailcow?

Mailcow ist ein deutsches Open-Source-Projekt unter Federführung von Servercow/Servercon. Es bündelt einen kompletten Mailserver-Stack als Docker-Compose-Setup. Lizenz: GPLv3, kommerzieller Support optional bei Servercow.

Im Stack enthalten:

Komponente	Aufgabe
Postfix	SMTP-Server (Inbound + Outbound)
Dovecot	IMAP/POP3-Server, Mail-Storage, Sieve-Filterregeln
SOGo	Webmail + CalDAV (Kalender) + CardDAV (Kontakte) + ActiveSync-Frontend
Rspamd	Spam-Erkennung, DKIM-Signierung, DNS-Bibliotheken
ClamAV	Antivirus-Scanning
MariaDB + Redis	Datenbank/Cache für Konfiguration und Locks
Nginx	Reverse-Proxy, TLS-Terminierung
Watchdog	Self-Health-Checks und Auto-Recovery
Solr	Volltextsuche im IMAP-Postfach
Unbound	Eigener DNS-Resolver für DNSBL-Lookups
PHP-FPM	Backend für das Admin-UI

Die wichtigste Designentscheidung: ein Docker-Compose-File beschreibt das gesamte Setup. Updates ziehen alle Container gemeinsam — keine Versions-Drift zwischen Postfix und Dovecot, keine Inkompatibilität nach Update.

Was Mailcow ohne weiteres kann

Funktional liefert Mailcow alles, was ein klassischer Exchange-Server ebenfalls bietet — mit Ausnahme einiger Exchange-spezifischer Konzepte (siehe Limits-Abschnitt):

• Unbegrenzt viele Domains auf einer Instanz, jede mit eigener DKIM-Signierung
• Mehrere Mailboxen pro Domain, mit Aliasen, Catch-All und Forwardern
• ActiveSync über das integrierte SOGo (für iOS/Android, Outlook-Mobile)
• Webmail SOGo mit Drag&Drop, Kalender-Sharing, Aufgaben und mehreren Sprachen
• CalDAV/CardDAV für native Mail-Clients (Thunderbird, Apple Mail, eM Client)
• Rspamd-Trainings-UI für gemeinsames Spam-Training durch alle Nutzer
• Sieve-Filter über die Webmail oder direkt
• Two-Factor-Authentication für Web-UI-Zugriff
• Quarantäne mit Release-Funktion — Empfänger entscheidet, ob er einzelne Mails aus dem Spam holt
• Inbox-Whitelisting pro Nutzer ohne Admin-Eingriff
• Backup über eingebautes Tool (Snapshot-Konsistent über mailcow.conf)
• Detailliertes Logging über docker-compose-Logs und Mailcow-eigenes UI

Setup auf Proxmox in der Praxis

Wir installieren Mailcow typischerweise in einer eigenen Debian-VM auf Proxmox, nicht in einer LXC — wegen Docker-Best-Practice (Docker in LXC ist möglich, aber nicht sauber für Production).

Hardware-Empfehlung für 25–100 Postfächer:

• 4 vCPU
• 8 GB RAM (16 GB komfortabler)
• 60 GB OS-Disk
• Separate Daten-Disk auf TrueNAS-Storage via NFS oder iSCSI (je nach Setup) — wegen Snapshot-Granularität und Wachstum
• Eine eigene öffentliche IPv4-Adresse mit PTR-Record

Schritte:

# Auf der frischen Debian-12-VM
apt update && apt -y install curl git ca-certificates

# Docker offizielles Repo
curl -fsSL https://get.docker.com | sh

# Mailcow holen
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized

# Konfiguration generieren
./generate_config.sh
# Hostname: mail.kundedomain.de
# Timezone: Europe/Berlin

# Starten
docker compose pull
docker compose up -d

Nach wenigen Minuten ist https://mail.kundedomain.de/admin erreichbar — Default-User admin, Passwort moohoo (sofort ändern!). Erste TLS-Zertifikate holt Mailcow automatisch über Let’s Encrypt (sofern Port 80 von außen erreichbar ist).

DNS-Vorbereitung: Pflicht-Records

Ohne korrekte DNS-Records ist jeder Mailserver wertlos — Mails landen in den Spam-Ordnern. Für jede gehostete Domain:

Record	Wert	Zweck
A	mail.domain.tld → IPv4	Server-Adresse
AAAA	mail.domain.tld → IPv6 (wenn vorhanden)	IPv6-Server-Adresse
MX	domain.tld → mail.domain.tld (Prio 10)	Mail-Routing
SPF (TXT)	v=spf1 mx ~all	Sender-Validierung
DKIM (TXT)	Aus Mailcow-UI exportieren	Signatur-Validierung
DMARC (TXT)	v=DMARC1; p=quarantine; rua=mailto:dmarc@domain.tld	Policy für SPF/DKIM-Fehler
PTR (Reverse DNS)	IPv4 → mail.domain.tld	Reverse-Lookup beim Empfänger

Der PTR-Record wird beim ISP / Hosting-Provider gesetzt, nicht in der eigenen DNS-Zone. Ohne PTR landet jede gesendete Mail bei Microsoft-Servern automatisch im Spam-Ordner.

Details zu SPF, DKIM, DMARC haben wir im Artikel E-Mail-Sicherheit: SPF, DKIM und DMARC ausführlich beschrieben — der Artikel ist Pflichtlektüre vor jedem Mailserver-Setup.

Backup-Strategie

Mailcow bringt ein eigenes helper-scripts/backup_and_restore.sh mit, das alle relevanten Volumes konsistent sichert. Pragmatischer Ansatz in einer DATAZONE-Standardumgebung:

1. Stündliche ZFS-Snapshots der Mailcow-Daten-Disk (auf TrueNAS)
2. Tägliches Mailcow-Backup-Skript via Cron mit Aufbewahrung 30 Tage
3. Wöchentliche Offsite-Replikation zu einem zweiten TrueNAS oder Cloud-Backup
4. Restore-Test alle 6 Monate — sonst weiß keiner, ob das Backup funktioniert

Was Mailcow nicht ist

Realistische Erwartungshaltung — drei Punkte, in denen Mailcow Exchange/M365 nicht ersetzt:

1. Outlook-MAPI-Integration

Outlook auf Windows spricht idealerweise MAPI/RPC (Exchange) oder IMAP. Mailcow liefert IMAP — funktioniert, aber Outlook-Funktionen wie Server-seitige Such-Indizierung, Server-seitige Regeln und “öffentliche Ordner” sind eingeschränkt. ActiveSync deckt mobiles Outlook gut ab; Desktop-Outlook ist OK, aber nicht so nahtlos wie mit Exchange.

2. Globale Adresslisten / GAL

Exchange synchronisiert die globale Adressliste über die gesamte Organisation. SOGo bietet pro Domain eine Sammeladresse, aber keine vollwertige GAL über Auto-Discover. Workaround: LDAP-Anbindung an einen separaten Verzeichnisdienst.

3. Public Folders

Exchange-Public-Folders haben keinen direkten Mailcow-Gegenpart. Im SOGo-Umfeld werden geteilte Ressourcen als geteilte Kalender, geteilte Adressbücher oder geteilte Mailboxen abgebildet — anders strukturiert, oft schlanker, aber Migrationspfad ist nicht 1:1.

Wann sich Mailcow lohnt

Profil	Mailcow geeignet?
10 Mitarbeiter, klassisches Handwerk, keine IT-Affinität	Nein — M365 ist hier strukturell besser
25–150 Mitarbeiter, eigener IT-Mensch, Compliance-Bedarf	Ja — sweet spot
Steuerberater/Anwalt mit hohem Datenhoheit-Bewusstsein	Ja, sehr
250+ Mitarbeiter mit Active Directory dominanter Strategie	Nein meistens — Exchange SE oder M365 passen besser
Hosting-Anbieter mit vielen Endkunden	Ja — Mailcow skaliert pro Domain gut
Reines Backup-Mailsystem als Fallback für M365	Ja — als parallele Disaster-Recovery-Schiene

Hochverfügbarkeit

Mailcow ist standardmäßig kein Hochverfügbarkeits-Stack. Für hohe Verfügbarkeit gibt es zwei Wege:

• Skripting-basiertes HA via mailcow-stretch-mode (zwei Mailcow-Instanzen, eine aktiv, eine passiv, Replikation manuell oder über rsync). Aufwand mittel, Funktionalität solide.
• Hot-Standby per VM-Replikation (z.B. PVE-VM-Replikation auf zweiten Node). Im Versagensfall manueller Schwenk per DNS-Change. Aufwand niedrig, Failover-Zeit Minuten.

Für die meisten KMU genügt die zweite Variante; echtes Active/Active-HA braucht echten Mailserver-Betrieb mit dedizierten Admins.

Updates und Wartung

./update.sh aus dem Mailcow-Repo zieht alle Container-Images neu, prüft Konfiguration, startet neu. Wir empfehlen:

• Monatliches Update-Fenster (planbar)
• Sicherheits-Updates der Mailcow-Distribution-Images werden vom Projekt selbst gerollt
• Vor jedem Update Snapshot der VM auf Proxmox-Ebene — rollback in 30 Sekunden möglich
• Logs nach Update prüfen: docker compose logs --tail=100

DATAZONE-Empfehlung

Mailcow ist 2026 der ausgereifteste Self-Hosted-Mailserver-Stack der Open-Source-Welt. Wir setzen ihn bei Kunden ein, bei denen drei Bedingungen zusammenkommen: 25–150 Mitarbeiter, klares Bedürfnis nach Datenhoheit oder DSGVO-Sensitivität, und ein IT-Verantwortlicher (intern oder per Dienstleister), der einen Docker-Stack pflegen kann oder will.

Wo Mailcow nicht das richtige Werkzeug ist, sagen wir das offen — meist sind das die ganz kleinen Setups (zu viel Aufwand für 5 Postfächer) oder die ganz großen mit voller M365-Integration. Dazwischen ist Mailcow oft schlicht die wirtschaftlich und technisch beste Option.

Verwandte Artikel:

• Microsoft Exchange ablösen: ROI für KMU
• Support-Ende für Microsoft Exchange 2019
• E-Mail-Sicherheit: SPF, DKIM und DMARC
• Nginx Reverse Proxy: Dienste sicher veröffentlichen
• Linux-Server-Hardening

Quellen

• Mailcow:dockerized auf GitHub
• Mailcow-Dokumentation
• Rspamd-Projekt
• SOGo-Projekt
• Servercow (kommerzieller Support)