Blog

Mailcow selbst hosten: Das unterschätzte Projekt

7. Mai 2026 · 15 min Lesezeit
Auf Play klicken um den Artikel vorlesen zu lassen.
MailcowE-MailDKIMSPFDMARCSelf-HostingPostfix Mailcow E-Mail DKIM SPF DMARC Self-Hosting Postfix

"E-Mail selbst hosten? Das macht man nicht." Dieser Satz kursiert in IT-Kreisen mit einer Hartnäckigkeit, die dem tatsächlichen Stand der Dinge nicht mehr gerecht wird. Ja, E-Mail ist eines der komplexesten Protokoll-Ökosysteme des Internets. Aber Mailcow abstrahiert den Großteil dieser Komplexität weg — was bleibt, ist vor allem eine Herausforderung: Reputation.

Was an E-Mail wirklich komplex ist

Das E-Mail-Ökosystem besteht aus einer Vielzahl von Komponenten und Standards, die zusammenspielen müssen:

  • Postfix/Exim: Der MTA (Mail Transfer Agent) — empfängt und sendet E-Mails
  • Dovecot: Der IMAP/POP3-Server — stellt E-Mails für Clients bereit
  • Rspamd/SpamAssassin: Spam-Filterung
  • ClamAV: Virus-Scanning
  • SPF, DKIM, DMARC: Authentifizierungsstandards gegen Spoofing
  • TLS: Verschlüsselung in Transit
  • Reputation: Wie gut wird die IP und Domain von anderen Servern bewertet

All das manuell zu konfigurieren ist tatsächlich aufwendig. Mailcow übernimmt die gesamte technische Konfiguration — fertig vorkonfiguriert, in Docker verpackt, über eine Web-UI verwaltbar.

Was Mailcow ist

Mailcow ist eine dockerisierte Mail-Server-Suite, die alle benötigten Komponenten integriert: Postfix, Dovecot, Rspamd, ClamAV, SOGo Webmail, Nginx, MariaDB, Redis und mehr. Die Web-UI (mailcow-UI) ermöglicht die Verwaltung von Domains, Postfächern, Aliasen, DKIM-Schlüsseln und Spam-Filterregeln ohne Kommandozeile.

# Installation (Debian/Ubuntu, Docker vorausgesetzt)
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh  # Fragt nach Hostname, Zeitzone
docker compose pull
docker compose up -d

Nach etwa fünf Minuten ist die Web-UI unter https://mail.example.com erreichbar. Das ist der technische Teil — der einfache.

Voraussetzungen: Was wirklich nötig ist

Statische IP-Adresse: Absolut notwendig. Dynamische IPs sind in allen Spam-Blacklisten. Hetzner-Server haben statische IPs standardmäßig.

Reverse DNS (PTR-Record): Der vielleicht wichtigste Punkt. Andere Mailserver prüfen, ob die IP des absendenden Servers einen PTR-Record hat, der auf den Hostname zurückzeigt. Bei Hetzner über das Robot-Panel oder die Cloud-API konfigurierbar.

# PTR-Record prüfen
dig -x 203.0.113.1 PTR
# Sollte auflösen zu: mail.example.com

Port 25 offen: Viele Provider blockieren Port 25 (SMTP) für ausgehenden Traffic, um Spam-Versand zu verhindern. Hetzner blockt Port 25 standardmäßig — man muss ihn per Support-Ticket freischalten lassen. Das dauert typischerweise 1–2 Werktage.

Dedizierte IP: Optimal, aber nicht zwingend. Shared IPs (wie bei günstigen Hetzner-Instanzen) können durch den schlechten Ruf anderer Nutzer belastet sein.

SPF, DKIM, DMARC: Das Authentifizierungs-Trifecta

SPF (Sender Policy Framework): Ein DNS-TXT-Record, der definiert, welche IP-Adressen E-Mails für deine Domain senden dürfen. Empfänger prüfen diesen Record und können E-Mails von nicht autorisierten IPs ablehnen.

# DNS TXT-Record für SPF
example.com. IN TXT "v=spf1 mx -all"
# mx = der eigene MX-Server ist erlaubt
# -all = alles andere ablehnen (hard fail)

DKIM (DomainKeys Identified Mail): Fügt jeder ausgehenden E-Mail eine kryptographische Signatur hinzu. Mailcow generiert automatisch DKIM-Schlüssel für jede Domain und zeigt den öffentlichen Schlüssel für den DNS-Eintrag an:

# DNS TXT-Record für DKIM (von Mailcow generiert)
dkim._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DMARC (Domain-based Message Authentication, Reporting and Conformance): Kombiniert SPF und DKIM und definiert eine Policy: Was soll passieren, wenn eine E-Mail weder SPF noch DKIM besteht? Außerdem liefert DMARC Reporting — tägliche XML-Berichte darüber, wer in deinem Namen E-Mails verschickt.

# DNS TXT-Record für DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"
# p=reject: E-Mails die SPF und DKIM nicht bestehen, ablehnen
# rua: Reports an diese Adresse senden

Mailcow konfiguriert die technische Seite automatisch. Die DNS-Einträge muss man selbst setzen — die Web-UI zeigt genau, was wo eingetragen werden muss.

Das eigentliche Problem: Reputation

Hier liegt die echte Herausforderung. Eine neue IP — egal wie gut konfiguriert — hat keine Reputation. E-Mail-Provider wie Gmail, Outlook und Yahoo bewerten eingehende E-Mails nicht nur nach technischen Standards, sondern auch nach dem historischen Verhalten der absendenden IP.

Eine frische Hetzner-IP landet mit hoher Wahrscheinlichkeit im Spam-Ordner bei Gmail — nicht weil die Konfiguration falsch ist, sondern weil die IP unbekannt ist. Das nennt sich "Warm-Up": Die Reputation muss über Wochen aufgebaut werden.

Strategien für den Warm-Up:

  • Zunächst nur an bekannte Empfänger senden (Freunde, Familie, eigene Adressen)
  • Empfänger bitten, E-Mails aus dem Spam zu ziehen und als "nicht Spam" zu markieren
  • Auf Blacklists prüfen: MXToolbox Blacklist Check
  • Postmaster Tools von Google und Microsoft nutzen für Feedback

Mit Geduld (4–8 Wochen) landet man in der Regel aus dem Spam-Ordner heraus. Wer sofort kritische Geschäftskommunikation darüber abwickeln will, braucht entweder eine ältere IP mit Reputation oder einen externen SMTP-Relay-Dienst für den Start.

Maintenance: Was regelmäßig anfällt

# Mailcow updaten (regelmäßig!)
cd /opt/mailcow-dockerized
./update.sh

# Rspamd-Logs prüfen auf falsch-positive/negative
docker logs mailcowdockerized-rspamd-mailcow-1 --tail 50

# Plattenplatz überwachen — E-Mails wachsen
df -h /opt/mailcow-dockerized

Backups sind kritisch: Das Mailcow-Datenverzeichnis (mailcow-dockerized/volumes/) enthält alle E-Mails und die Datenbank. Regelmäßige Snapshots auf externen Speicher sind Pflicht.

Fazit

Mailcow macht E-Mail-Selbsthosting 2026 realistisch für technisch versierte Einzelpersonen und kleine Teams. Die technische Komplexität ist weitgehend abstrahiert. Was bleibt — Reputation, Blacklist-Monitoring, Wartung — ist überschaubar wenn man weiß, worauf man achten muss. Wer E-Mail-Souveränität will und bereit ist, ein paar Wochen Geduld für den Warm-Up aufzubringen, bekommt eine vollwertige, self-hosted E-Mail-Infrastruktur.

Fail2ban für Mailcow: Brute-Force-Schutz

Mailcow hat einen eingebauten Brute-Force-Schutz via Nginx und Netfilter, aber Fail2ban als zusätzliche Schicht ist sinnvoll — insbesondere für den SMTP-Port 25:

# /etc/fail2ban/jail.local
[postfix-sasl]
enabled  = true
port     = smtp,465,submission
filter   = postfix-sasl
logpath  = /opt/mailcow-dockerized/data/logs/postfix.log
maxretry = 5
bantime  = 3600

[dovecot]
enabled = true
port    = pop3,pop3s,imap,imaps,submission,465,sieve
filter  = dovecot
logpath = /opt/mailcow-dockerized/data/logs/dovecot.log
maxretry = 5

Rspamd: Spam-Filterung verstehen und trainieren

Rspamd ist das Herzstück der Spam-Filterung in Mailcow. Es bewertet jede E-Mail anhand von hunderten Regeln und gibt einen Score aus. Ab einem Schwellwert (Standard: 6) wird eine E-Mail als Spam markiert, ab einem höheren Wert (Standard: 15) direkt abgelehnt.

# Rspamd Web-UI öffnen
# https://mail.example.com/rspamd/
# (Login via mailcow Admin-Passwort)

# Manuelle Überprüfung via API
curl -s http://localhost:11334/stat | python3 -m json.tool

# Ham-Training (legitime E-Mail als nicht-Spam markieren)
# In der mailcow UI: E-Mail auswählen → "Als Ham markieren"

# Spam-Training via rspamc (Kommandozeile im Container)
docker exec -it mailcowdockerized-rspamd-mailcow-1   rspamc -h localhost:11334 learn_spam /pfad/zur/spam.eml

Ein wichtiger Tipp: Die Fuzzy-Datenbank von Rspamd enthält Community-basierte Spam-Signaturen. Diese werden automatisch synchronisiert und verbessern die Erkennungsrate erheblich — ohne eigenes Training.

TLS-Konfiguration in Mailcow optimieren

Mailcow generiert automatisch Let's-Encrypt-Zertifikate für den konfigurierten Hostnamen. Für mehrere Domains oder Wildcard-Zertifikate gibt es zusätzliche Konfigurationsmöglichkeiten:

# mailcow.conf anpassen
MAILCOW_HOSTNAME=mail.example.com
ADDITIONAL_SAN=autodiscover.example.com,imap.example.com

# Eigene Zertifikate einbinden (statt Let's Encrypt)
# /opt/mailcow-dockerized/data/assets/ssl/
# cert.pem und key.pem ersetzen

Mailcow konfiguriert automatisch STARTTLS für SMTP und erzwingt TLS für IMAP/POP3. Die TLS-Qualität lässt sich auf SSL Labs und über das MXToolbox Super Tool verifizieren.

Aliases, Catch-All und Subaddressing

Mailcow unterstützt verschiedene Alias-Typen die für Privatsphäre und Organisation nützlich sind:

# Subaddressing: user+tag@example.com geht an user@example.com
# Aktivierung in postfix-Konfiguration (in Mailcow standardmäßig aktiv)
# Nützlich für Newsletter-Tracking

# Catch-All: Alle E-Mails an @example.com
# In mailcow UI: Domain → Catch-All-Adresse konfigurieren

# Zeitbasierte Aliases (Sieve-Filter)
# /opt/mailcow-dockerized/data/conf/dovecot/extra.conf
# Sieve-Erweiterungen für automatische Sortierung

Monitoring: Wann läuft was schief?

Die wichtigsten Metriken für einen Mailserver:

  • Queue-Länge: Viele E-Mails in der Queue bedeuten Zustellprobleme
  • Spam-Rate: Plötzlich viel Spam kann auf Kompromittierung hinweisen
  • Bounce-Rate: Hohe Bounce-Rate schadet der Reputation
  • Blacklist-Status: Täglich prüfen
# Postfix Queue-Status
docker exec mailcowdockerized-postfix-mailcow-1 mailq

# Leer die Queue (bei Problemlösung)
docker exec mailcowdockerized-postfix-mailcow-1 postsuper -d ALL deferred

# Logs in Echtzeit
docker logs mailcowdockerized-postfix-mailcow-1 -f --tail 100

Backup-Strategie für Mailcow

# Offizielles Mailcow Backup-Skript
cd /opt/mailcow-dockerized
./helper-scripts/backup_and_restore.sh backup all

# Backup-Verzeichnis
ls -la /opt/mailcow-dockerized/backups/

# Automatisierung via Cron
0 3 * * * /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all

# Backups auf externe Storage Box
rsync -avz /opt/mailcow-dockerized/backups/   u123456@u123456.your-storagebox.de:/mailcow-backups/

Externe SMTP-Relays für den Warm-Up

Wer den Reputationsaufbau umgehen will oder kritische E-Mails sofort zuverlässig zustellen muss, kann Mailcow so konfigurieren, dass ausgehende E-Mails über einen etablierten SMTP-Relay-Dienst gesendet werden. Das ist der "Belt and Suspenders"-Ansatz:

# Mailcow: Ausgehende E-Mails über Relay senden
# In der UI: Configuration → Routing → Add General Relay Host
# Host: smtp.sendgrid.net (oder AWS SES, Mailgun etc.)
# Port: 587
# Username/Password: API-Schlüssel des Relay-Dienstes

# Oder direkt in Postfix-Konfiguration
# /opt/mailcow-dockerized/data/conf/postfix/extra.cf
relayhost = [smtp.sendgrid.net]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/opt/postfix/conf/sasl_passwd

Kostenoptionen: AWS SES bietet 62.000 E-Mails/Monat kostenlos wenn von EC2/Lightsail versendet. Mailgun hat ein begrenztes kostenloses Kontingent. Für Testzwecke oder niedrige Volumina ausreichend.

Greylisting: Effektiver Spam-Schutz ohne False Positives

Greylisting ist eine simple aber effektive Anti-Spam-Maßnahme: Der erste Zustellversuch einer E-Mail wird mit einem temporären Fehler abgelehnt. Legitime Mailserver versuchen es nach einigen Minuten erneut — Spam-Bots meistens nicht. Mailcow hat Greylisting über Rspamd eingebaut:

# Rspamd Greylisting konfigurieren
# /opt/mailcow-dockerized/data/conf/rspamd/local.d/greylist.conf
servers = "127.0.0.1:6379";  # Redis-Backend
timeout = 5min;               # Wie lange warten vor Retry
expire = 1d;                  # Wie lange Whitelist-Einträge gelten

Greylisting reduziert Spam typischerweise um 20–40% ohne False Positives — legitime Mailserver retrying sowieso. Der Nachteil: E-Mails von unbekannten Absendern kommen erst nach einigen Minuten an. Für Zeit-kritische Kommunikation kann das unpraktisch sein.

Dkim-Rotation und Schlüsselverwaltung

DKIM-Schlüssel sollten periodisch rotiert werden — jährlich ist Standard, bei erhöhtem Risiko öfter. Mailcow ermöglicht das über die UI:

# Mailcow CLI: DKIM-Schlüssel neu generieren
docker exec mailcowdockerized-postfix-mailcow-1   python3 /usr/local/bin/generate_dkim_domain.py example.com 2048

# Neuen öffentlichen Schlüssel aus UI kopieren und DNS aktualisieren
# Wichtig: Alten Schlüssel erst nach 48h DNS-Propagation entfernen!

# DKIM-Signierung testen
echo "Test" | mail -s "DKIM Test" test@mail-tester.com
# mail-tester.com zeigt DKIM-Status

Kostenübersicht: Was kostet ein eigener Mailserver wirklich?

Eine realistische Kostenkalkulation für einen Mailcow-Server:

  • Hetzner CX22: ~3,50 Euro/Monat (ausreichend für 1–5 Postfächer)
  • Domain: 10–15 Euro/Jahr
  • Backup (Storage Box 100GB): ~1,38 Euro/Monat
  • Gesamt: ~60–65 Euro/Jahr

Verglichen mit: Google Workspace Business Starter 6 Dollar/Nutzer/Monat, Microsoft 365 Business Basic 6 Euro/Nutzer/Monat. Bei einem Nutzer ist Mailcow günstiger ab dem zweiten Jahr. Bei fünf Nutzern signifikant günstiger — und ohne Datenschutz-Kompromisse gegenüber US-Anbietern.

E-Mail-Verschlüsselung: PGP und S/MIME in Mailcow

Mailcow unterstützt serverseitige PGP-Verschlüsselung via SOGo Webmail. Für maximale Sicherheit ist Ende-zu-Ende-Verschlüsselung (E2E) mit PGP oder S/MIME besser — der Server sieht dann nur den verschlüsselten Ciphertext, nicht den Klartext der E-Mail. Mailcow interfiert dabei nicht mit PGP/S/MIME im Client — Thunderbird, Outlook und Apple Mail unterstützen beides nativ.

# PGP-Schlüssel generieren (modernes Format)
gpg --full-generate-key
# Wahl: ECC (ed25519 + cv25519) — kleiner, schneller als RSA

# Öffentlichen Schlüssel an Keyserver hochladen
gpg --keyserver keys.openpgp.org --send-keys KEYID

# Thunderbird: OpenPGP direkt eingebaut
# Konto-Einstellungen → End-to-End-Verschlüsselung → OpenPGP-Schlüssel hinzufügen

SRS: Sender Rewriting Scheme bei Weiterleitungen

Ein häufiges Problem bei eigenen Mailservern: E-Mail-Weiterleitungen an externe Adressen (z.B. von user@example.com an user@gmail.com) scheitern an SPF. Der weitergeleitete Server sendet die E-Mail mit der Original-Absenderadresse, aber von seiner eigenen IP — die nicht im SPF-Record der Originaldomain steht.

Die Lösung: SRS (Sender Rewriting Scheme) schreibt den Envelope-Absender um, sodass der weitergeleitende Server als legitimierter Absender erscheint. Mailcow hat SRS über Postfix eingebaut, muss aber aktiviert werden:

# Mailcow: SRS aktivieren
# In mailcow.conf:
SRS_DOMAINNAME=example.com
SRS_EXCLUDE_DOMAINS=
SRS_ENABLED=1

# Docker neu starten
cd /opt/mailcow-dockerized
docker compose down && docker compose up -d

Migration von Google/Microsoft zu Mailcow

Wer von Google Workspace oder Office 365 zu Mailcow wechselt, muss historische E-Mails migrieren. Das Tool imapsync überträgt E-Mails direkt zwischen IMAP-Servern:

# imapsync: Migration von Gmail zu Mailcow
imapsync   --host1 imap.gmail.com --ssl1   --user1 nutzer@gmail.com --password1 "app-passwort"   --host2 mail.example.com --ssl2   --user2 nutzer@example.com --password2 "mailcow-passwort"   --automap  # Ordner automatisch zuordnen
  --exclude "\[Gmail\]"  # Gmail-spezifische Ordner ausschließen

Eine vollständige Migration von 10 GB E-Mail-Archiv dauert je nach Verbindungsgeschwindigkeit mehrere Stunden bis einen Tag. imapsync ist resumable — bei Unterbrechung setzt es fort ohne Duplikate zu erzeugen.

Fazit: Lohnt es sich?

E-Mail-Selbsthosting mit Mailcow lohnt sich für technisch versierte Nutzer, die Datensouveränität ernst nehmen und bereit sind, einen moderaten Initialaufwand zu investieren. Die technische Hürde ist dank Mailcow deutlich gesunken — die eigentliche Herausforderung ist die Reputationsentwicklung, und die löst sich mit Geduld.

Wer für sich oder sein kleines Team E-Mails verwaltet, bekommt mit Mailcow eine Lösung die in Funktionsumfang und Zuverlässigkeit mit kommerziellen Angeboten mithalten kann — zu einem Bruchteil der Kosten und ohne Abhängigkeit von US-amerikanischen Datensilos. SPF, DKIM, DMARC, Spam-Filterung, Webmail, Mobile-Sync (ActiveSync via SOGo) — alles dabei, alles selbst kontrolliert.

Die einzige Empfehlung: Nicht mit kritischer Geschäftskommunikation starten. Erst privat einrichten, vier bis sechs Wochen Reputation aufbauen, die Zustellraten beobachten, dann schrittweise migrieren. So wird aus dem "unterschätzten Projekt" ein zuverlässiger Teil der eigenen Infrastruktur.

E-Mail ist kritische Infrastruktur. Wer sie selbst betreibt, übernimmt Verantwortung — für Uptime, Backups, Sicherheit. Diese Verantwortung ist mit Mailcow überschaubar, aber nicht null. Wer bereit ist, diese Verantwortung zu tragen, bekommt dafür vollständige Datensouveränität und eine technische Plattform die sich mit jedem kommerziellen Angebot messen kann.

War dieser Beitrag hilfreich?


Alle Beiträge Gregor Krebs · 7. Mai 2026