MTA-STS einrichten für Mailcow (selbst gehostet)

MTA-STS für Mailcow: seit 2025-09 in der UI konfigurierbar — mailcow hostet die Policy zentral, du setzt nur TXT und CNAME.

Stand: Juli 2026

Zusammenfassung: Nach dieser Anleitung erzwingt deine Domain verschlüsselte Zustellung für eingehende Mails an deinen Mailcow-Server. Seit mailcow 2025-09 klickst du die Policy in der UI zusammen — mailcow hostet die Policy-Datei selbst.

⚠️ Empfangsrisiko: Eine fehlerhafte MTA-STS-Policy im enforce-Modus kann dazu führen, dass andere Server keine Mails mehr an deine Domain zustellen — und max_age hält den Fehler tagelang im Cache. Beginne immer mit mode: testing und werte TLS-RPT-Berichte aus, bevor du erzwingst.

Voraussetzungen

Was ist MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) sagt anderen Mailservern: „Liefere Mail an meine Domain nur über eine gültige, verschlüsselte TLS-Verbindung." Das verhindert Downgrade- und Man-in-the-Middle-Angriffe auf dem Transportweg.

Die Ausgangslage bei Mailcow — angenehm einfach

Hier ist Selfhosting im Vorteil: Anders als bei Google Workspace und Microsoft 365, wo du die Policy-Datei selbst per HTTPS hosten musst, hostet mailcow die Policy-Datei zentral. Du konfigurierst alles in der UI, setzt zwei DNS-Records — fertig.

Diese Integration entstand im Rahmen der BSI-Initiative „E-Mail-Sicherheitsjahr 2025". Technisch wichtig: mailcow legt keine .well-known/mta-sts.txt-Datei mehr an, sondern generiert die Policy dynamisch. Wer früher manuell eine Datei hinterlegt hatte, muss auf die UI-Konfiguration umstellen.

Schritt-für-Schritt-Anleitung

1. MTA-STS in der mailcow-UI aktivieren

Melde dich als Administrator an und geh zu E-Mail → Configuration, dann in den Domains-Tab. Editiere die Domain (Edit) — du siehst nun einen MTA-STS-Tab. Die Optionen:

Setze den Haken bei Active und klicke Save changes. Starte mit testing, wechsle nach Auswertung der TLS-RPT-Berichte auf enforce.

2. DNS-Records anlegen

Zwei Einträge bei deinem DNS-Anbieter:

TXT auf _mta-sts.beispiel.de:

v=STSv1; id=2025071012

Die id (Format YYYYMMDDHH) muss bei jeder Policy-Änderung hochgezählt werden — mailcows Doku-Beispiel ist v=STSv1; id=2024090101. Praktisch: mailcow erzeugt bei UI-Änderungen automatisch eine neue id; den aktuellen Wert zeigt der DNS-Check-Button in der UI.

CNAME auf mta-sts.beispiel.de, der auf deinen mailcow-FQDN zeigt:

mta-sts.beispiel.de.    CNAME    mail.beispiel.de.

Der CNAME ist Pflicht — nur so kann ein gültiges Zertifikat erzeugt werden und empfangende Server die Policy abrufen.

3. Prüfen

Nutze den DNS-Check in der mailcow-UI (blauer Button), um zu bestätigen, dass TXT und CNAME korrekt gesetzt und propagiert sind. Zusätzlich prüft der kostenlose Kuveris-Scanner die Policy von außen.

Ergebnis prüfen

Prüfe deine Konfiguration mit dem kostenlosen Kuveris-Scanner — er ruft den _mta-sts-Record und die Policy ab und zeigt sie zusammen mit TLS-RPT und deiner TLS-Lage.

Häufige Fehler

Alte manuelle .well-known-Datei. Nach dem Update auf 2025-09 sind manuell hinterlegte mta-sts.txt-Dateien nicht mehr erreichbar — die Policy kommt jetzt aus der UI-Konfiguration.

CNAME vergessen. Ohne den mta-sts-CNAME auf den FQDN gibt es kein Zertifikat für die Policy-URL — MTA-STS greift nicht.

id nicht hochgezählt. Bei manuellen Änderungen die id erhöhen (mailcow macht das bei UI-Änderungen selbst).

Sofort enforce. Erst testing, TLS-RPT-Berichte prüfen, dann enforce.

Weiterführende Links

Verwandter Befund: Was bedeutet dieses Ergebnis?