MTA-STS für Mailcow einrichten

Mailcow hat seit Release 2025-09 Built-in-MTA-STS — keine separate nginx-Konfiguration mehr nötig. Die Policy wird dynamisch per PHP generiert, der CNAME mta-sts zeigt auf den Mailcow-FQDN, der postfix-tlspol-mailcow-Container validiert Outbound.

MTA-STS-Status prüfen Plattform entdecken

Mailcow · MTA-STS Built-in

Von Wolf-Agents Security Team · Aktualisiert: 13. Mai 2026

MTA-STS bei Mailcow (Built-in seit Release 2025-09)

Mailcow hat seit dem September-2025-Release Built-in-MTA-STS — kein separater nginx-vhost, keine eigene Policy-Datei, kein zusätzliches Hosting nötig. Die Policy wird dynamisch per PHP-Code aus der Mailcow-Datenbank generiert, der Mailcow-eigene nginx liefert sie unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt aus. Das Feature wurde im Rahmen des „Email Security Year 2025“-Programms des BSI eingeführt. Drei Modi sind im Admin-UI wählbar: none (deaktiviert, nur Monitoring), testing (aktiv, Verletzungen werden geloggt aber nicht blockiert) und enforce (aktiv, nicht-konforme Sender werden abgelehnt).

Zusätzlich liefert das 2025-09-Release den postfix-tlspol-mailcow-Container — ein leichtgewichtiger MTA-STS- und DANE/TLSA-Resolver für Outbound. Wenn Mailcow eine Mail an eine Empfänger-Domain mit MTA-STS-Enforce sendet, validiert der Container die Policy des Empfängers und erzwingt TLS — DANE wird bevorzugt. Das ersetzt die manuelle Konfiguration von postfix-mta-sts-resolver (Snawoot) auf Vanilla-Postfix-Setups.

Der Wolf-Agents Email Security Scanner vergleicht Policy-MX und DNS-MX zeichengenau: Er erkennt den Mailcow-typischen Drift zwischen einer alten manuellen mta-sts-Subdomain-Konfiguration (z.B. nginx-vhost aus Vor-2025-09-Zeit) und der neuen Built-in-Auslieferung, warnt vor fehlendem SSL-Zertifikat für die mta-sts-Subdomain (Mailcows ACME-Container kümmert sich automatisch, aber nur wenn der CNAME korrekt zeigt), deckt Wildcard-CNAME-Anti-Patterns auf und meldet Mode-Inkonsistenzen zwischen id im TXT-Record und dynamischer Policy. CT-Log-Monitoring via Certstream-Integration alarmiert bei unautorisierten Zertifikats-Ausstellungen für Ihre MX-Hostnamen.

Hardening-Pfad: Nach MTA-STS folgt SMTP-TLS für Mailcow — Cipher-Härtung in der Postfix-extra.cf. Falls DMARC für Mailcow noch nicht aktiviert ist, starten Sie mit der DMARC-Anleitung für Mailcow. Bedrohungs-Cluster: Built-in-MTA-STS schließt den STRIPTLS-Angriffsweg gegen Ihre eingehende Mailcow-Mail — ein Man-in-the-Middle kann das STARTTLS-Kommando nicht mehr entfernen, um die Mail im Klartext mitzulesen (Schutz gegen Spoofing-Vektoren). Heimlich mitgelesene Reply-Chains liefern Angreifern zudem die Reconnaissance-Basis für gezielten Business Email Compromise.

Für NIS2-pflichtige Unternehmen mit Mailcow-Infrastruktur gilt: Art. 21 Abs. 2 lit. h fordert Konzepte und Verfahren für den Einsatz von Kryptografie — Built-in-MTA-STS-Enforce liefert den kryptografisch nachweisbaren TLS-Erzwingungs-Status für eingehende Mail. BSI TR-03108 Abschnitt 4.3 empfiehlt MTA-STS explizit; DSGVO Art. 32 fordert Verschlüsselung personenbezogener Daten bei der Übertragung. NIS2 Art. 23 (24h-Frühwarnung bei STRIPTLS-Vorfall mit Klartext-Mitlesen) lässt sich durch TLS-RPT- und Mailcow-Policy-Logs (postfix-tlspol-mailcow-Container) forensisch belegen.

Ausführliche MTA-STS & TLS-RPT Anleitung

Mailcow Built-in-MTA-STS-Architektur (Release 2025-09)

Drei-Lanes-Architektur-Diagramm für Mailcow Release 2025-09: Inbound-Lane (Sender-MTA → DNS → HTTPS → nginx-mailcow → PHP-Endpoint → Policy), Outbound-Lane (postfix-mailcow → postfix-tlspol-mailcow → DNS → Policy-Validierung → STARTTLS-Erzwingung), ACME-Lane (acme-mailcow → Lets Encrypt Challenge → automatische Cert-Erneuerung). Vorher/Nachher-Vergleich: vor 2025-09 manueller nginx-vhost + Snawoot-Resolver, nach 2025-09 Built-in.

1 Schritt 1 von 5

Mailcow auf 2025-09 oder neuer aktualisieren

Das Built-in-MTA-STS-Feature setzt das September-2025-Release von Mailcow voraus. Prüfen Sie Ihre Version mit git -C /opt/mailcow-dockerized log -1 --format="%cd" und aktualisieren Sie bei Bedarf — die offizielle Doku verlangt explizit „mailcow version 2025-09 or newer“.

# Aktuelle Version prüfen
cd /opt/mailcow-dockerized
git log -1 --format="%cd %h" --date=short

# Vor Update: crypt-Volume sichern (DKIM-Keys etc.)
docker run --rm -v mailcowdockerized_crypt-vol-1:/data alpine \
  tar czf - /data > ~/crypt-backup-$(date +%Y%m%d).tar.gz

# Update durchführen
./update.sh --check    # Trockenlauf
./update.sh            # Update ausführen

# Nach Update — postfix-tlspol-mailcow-Container prüfen
docker compose ps postfix-tlspol-mailcow

2 Schritt 2 von 5

DNS-Records anlegen

Zwei DNS-Records sind nötig: ein TXT für _mta-sts mit Policy-ID und ein CNAME für mta-sts, der auf Ihren Mailcow-FQDN zeigt. Die laut docs.mailcow.email „CNAME-Pflicht“ ist Voraussetzung für die automatische SSL-Zertifikatsausstellung durch den Mailcow-ACME-Container und die Policy-Auslieferung. Optional: TLS-RPT-Record für Aggregate-Reports.

# 1) _mta-sts TXT-Record
_mta-sts.ihre-domain.de.  IN  TXT  "v=STSv1; id=20260513T1430"

# 2) CNAME für Policy-Subdomain (zeigt auf Mailcow-FQDN!)
mta-sts.ihre-domain.de.   IN  CNAME  mail.ihre-domain.de.

# 3) TLS-RPT TXT-Record (optional, aber empfohlen)
_smtp._tls.ihre-domain.de.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"

# Verifikation nach Setzen
dig _mta-sts.ihre-domain.de TXT +short
dig mta-sts.ihre-domain.de CNAME +short  # mail.ihre-domain.de.

3 Schritt 3 von 5

MTA-STS-Modus in Mailcow setzen

Im Mailcow Admin-UI wählen Sie pro Domain den MTA-STS-Modus aus. Beginnen Sie mit testing — Verletzungen werden in den Mailcow-Logs sichtbar, aber Mails werden nicht blockiert. Nach 2-4 Wochen ohne Fehler im Log auf enforce wechseln.

Aktivierung im Mailcow Admin-UI

Login unter https://mail.ihre-domain.de/admin
Navigieren Sie zu E-Mail Configuration → Domains (in älteren Mailcow-UI-Versionen Configuration → Mail Setup → Domains)
Klicken Sie auf das Edit-Symbol neben der Domain
Wechseln Sie im Edit-Dialog zum Reiter MTA-STS
MTA-STS Mode: Wählen Sie testing für die initiale Beobachtungsphase
Speichern — Mailcow generiert sofort die dynamische Policy unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt
Mit curl https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt prüfen — erwartete Ausgabe enthält version: STSv1 / mode: testing / mx: mail.ihre-domain.de / max_age: 86400

id-Update nach Mode-Wechsel

Beim Wechsel von testing auf enforce die id im _mta-sts-TXT-Record erhöhen (z.B. 20260527T1500), damit sendende Server die neue Policy sofort abrufen — sonst cached Policy bis zu max_age Sekunden.

MTA-STS für Alias-Domains (PR #6972, Information-Gain)

Seit dem Merge des PR #6972 am 15. Dezember 2025 erben Alias-Domains die MTA-STS-Policy automatisch von ihrer Ziel-Domain. Vor diesem PR mussten Alias-Domains entweder eine eigene MTA-STS-Policy hosten oder konnten nicht mit MTA-STS-Enforce versehen werden. Drei Komponenten arbeiten zusammen: mta-sts.php normalisiert Domains via IDN und leitet Anfragen zur Ziel-Domain weiter, acme.sh fordert automatisch Zertifikate für mta-sts.<alias-domain> an und dns_diagnostics.php zeigt die nötigen DNS-Einträge in der Mailcow-UI an. Wolf-Agents prüft die Konsistenz zwischen Alias-Domain-DNS-Records und Ziel-Domain-Policy automatisch.

4 Schritt 4 von 5

Outbound MTA-STS via postfix-tlspol-mailcow

Der mit Release 2025-09 mitgelieferte postfix-tlspol-mailcow-Container übernimmt automatisch die MTA-STS- und DANE/TLSA-Validierung beim Mail-Versand — kein zusätzliches Setup nötig. Wenn Mailcow eine Mail an eine Empfängerdomain mit MTA-STS-Enforce sendet, prüft der Container die Empfänger-Policy und erzwingt TLS gegen die in der Empfänger-Policy gelisteten MX-Hosts. DANE wird gegenüber MTA-STS bevorzugt.

# Container-Status prüfen
docker compose ps postfix-tlspol-mailcow
# Erwartet: State=Up, Ports=127.0.0.1:8642->8642/tcp

# Container-Logs auf MTA-STS-Validierungen
docker compose logs --tail=100 postfix-tlspol-mailcow | grep -i "mta-sts\|policy"

# Test-Mail an eine Domain mit aktivem MTA-STS senden
echo "Test" | docker compose exec postfix-mailcow \
  sendmail -f test@ihre-domain.de test@gmail.com

# Postfix-Logs auf TLS-Erzwingung prüfen
docker compose logs --tail=200 postfix-mailcow | grep -E "TLS|policy"

DANE als Komplement zu MTA-STS (Information-Gain Welle 2)

Der postfix-tlspol-mailcow-Container prüft DANE/TLSA-Records vor MTA-STS-Policies — DANE/RFC 7672 ist die kryptografisch stärkere Variante, weil sie auf DNSSEC-signierten TLSA-Records basiert statt auf HTTPS-Ressourcen-Vertrauen. Für strikten DANE-Modus in der data/conf/postfix/extra.cf: smtp_tls_security_level = dane (oder dane-only für RFC-7672-Konformität ohne Fallback) und smtp_dns_support_level = dnssec. Voraussetzung: DNSSEC-signierte Zone Ihrer Domain UND eines DANE-fähigen DNS-Resolvers (z.B. der mitgelieferte unbound-mailcow-Container). Quelle: blog.lindenberg.one/Rfc7672MailcowPostfix (abgerufen 2026-05-13). Microsoft Exchange Online unterstützt SMTP-DANE für Outbound seit März 2022 und Inbound seit Juli 2024 — DANE wird damit auch in Enterprise-Empfänger-Setups zunehmend produktiv geprüft.

5 Schritt 5 von 5

MTA-STS-Konfiguration verifizieren

Prüfen Sie alle drei Ebenen: DNS-Records, HTTPS-Erreichbarkeit der dynamischen Policy und Outbound-Validierung. Der Wolf-Agents Email Security Scanner validiert den MX-Abgleich automatisch — die mx-Einträge in der dynamischen Policy müssen exakt mit Ihren DNS-MX-Records übereinstimmen.

# DNS-Records
dig _mta-sts.ihre-domain.de TXT +short
dig mta-sts.ihre-domain.de CNAME +short
dig _smtp._tls.ihre-domain.de TXT +short

# Dynamische Policy abrufen
curl -s https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt
# Erwartet:
# version: STSv1
# mode: testing  (oder enforce)
# mx: mail.ihre-domain.de
# max_age: 86400

# SSL-Zertifikat der mta-sts-Subdomain prüfen
echo | openssl s_client -connect mta-sts.ihre-domain.de:443 \
  -servername mta-sts.ihre-domain.de 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

# MX-Match prüfen
dig MX ihre-domain.de +short
# Muss exakt das mx-Feld der Policy treffen

# Windows (PowerShell)
Invoke-WebRequest -Uri "https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt" | \
  Select-Object -ExpandProperty Content

Häufige Fehler bei Mailcow MTA-STS

Diese drei Fehler treten beim Mailcow-Built-in-MTA-STS besonders häufig auf — alle drei verhindern, dass die Policy korrekt von Empfängern abgerufen wird.

Mailcow-Version vor 2025-09 — Feature nicht verfügbar

Problem: Die Mailcow-Installation läuft mit Pre-2025-09-Release. Der MTA-STS-Reiter im Admin-UI ist entweder nicht vorhanden oder zeigt nur den Hinweis „Feature requires Mailcow 2025-09+“. Anleitungen in der offiziellen docs.mailcow.email setzen explizit die neue Version voraus.

Lösung: Mailcow updaten (siehe Schritt 1). Falls Update aus operativen Gründen nicht möglich: alternative Lösung über separaten nginx-vhost — siehe MTA-STS für Postfix, deren Vorgehen analog auf Mailcow-Vor-2025-09 funktioniert.

CNAME zeigt nicht auf Mailcow-FQDN

Problem: Der CNAME mta-sts.ihre-domain.de wurde nicht angelegt oder zeigt auf einen externen Hoster (z.B. Cloudflare Pages, wie früher empfohlen). Der ACME-Container kann kein Let's-Encrypt-Zertifikat für die Subdomain ausstellen — https://mta-sts.ihre-domain.de/ liefert ein SSL-Zertifikat-Fehler, MTA-STS-konforme Sender lehnen die Policy als ungültig ab.

Lösung: CNAME im DNS auf den Mailcow-FQDN setzen: mta-sts.ihre-domain.de. IN CNAME mail.ihre-domain.de. Nach 24h prüft Mailcows ACME-Container automatisch die Auflösung und stellt das Zertifikat aus. Mit docker compose logs acme-mailcow | tail -50 den Status verfolgen.

Direct-Sprung von none auf enforce ohne testing-Phase

Problem: Der MTA-STS-Modus wird sofort auf enforce gesetzt, ohne eine Beobachtungsphase mit testing. Wenn TLS-Konfigurations-Probleme auf den eingehenden MX-Hosts existieren (z.B. abgelaufenes Zertifikat, falsche Cipher-Suite), werden ALLE eingehenden Mails blockiert — Datenverlust, weil sendende Server nach Hard-Fail nicht mehr retry-en.

Lösung: Strikt 2-4 Wochen mode: testing beobachten. Mailcow-Logs auf mta-sts-policy-violations prüfen — falls TLS-RPT konfiguriert, kommen externe Reports automatisch. Erst bei null Verletzungen auf enforce wechseln und die id erhöhen.

NIS2, BSI TR-03108 und DSGVO Art. 32: MTA-STS bei Mailcow

NIS2 Art. 21 Abs. 2 lit. h fordert den Einsatz von Kryptografie und Verschlüsselung — MTA-STS im Enforce-Modus erfüllt diese Anforderung technisch nachweisbar. BSI TR-03108 Abschnitt 4.3 empfiehlt MTA-STS explizit als Schutz gegen STRIPTLS-Angriffe; das Built-in-Feature wurde im Rahmen des „Email Security Year 2025“-Programms des BSI in Mailcow integriert. DSGVO Art. 32 verlangt Verschlüsselung als technische Maßnahme; TLS-RPT-Reports (XML-Format) dokumentieren TLS-Erzwingungs-Erfolg pro Tag und dienen als DSGVO-TOM-Nachweis. Bei Mailcow-Self-Hosting liegt die volle Verantwortung bei Ihnen — der postfix-tlspol-mailcow-Container handhabt Outbound-MTA-STS automatisch. NIS2 Art. 23 (24h-Frühwarnung, 72h-Vorfallsmeldung) wird durch TLS-RPT-Reports forensisch belegbar. Wolf-Agents CT-Log-Monitoring via Certstream-Integration alarmiert bei unautorisierten Zertifikats-Ausstellungen für Ihren Mailcow-FQDN und für die _mta-sts.*/mta-sts.*-Subdomains. Der Wolf-Agents Email Security Scanner bewertet MTA-STS mit bis zu 15 Punkten (10 MTA-STS + 5 TLS-RPT) der 165-Punkte-Analyse.

MTA-STS-Anleitung auch für:

Microsoft 365 Google Workspace IONOS Strato All-Inkl Hetzner Netcup Postfix Exim Cloudflare DNS Generisch

Wie steht Ihre Domain bei MTA-STS?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.

E-Mail Security Check starten