Von testing zu enforce: schrittweise MTA-STS-Bereitstellungsstrategie

Q: Wie kann man nach der Aktivierung von enforce zum Testing-Modus zurückkehren?

Ändern Sie die Richtliniendatei zurück auf mode: testing und erhöhen Sie die id im DNS-TXT-Eintrag. Sendende Server, die die Enforce-Richtlinie gecacht haben, wenden diese bis zum Ablauf des vorherigen max_age weiter an (maximal 7 Tage).

Von CaptainDNS
Veröffentlicht am 10. März 2026

Diagramm der schrittweisen MTA-STS-Bereitstellung vom Testing-Modus zum Enforce-Modus

TL;DR

MTA-STS im Testing-Modus sammelt TLS-RPT-Berichte, ohne die E-Mail-Zustellung zu blockieren: ideal zur Erkennung von Konfigurationsproblemen
Der Enforce-Modus lehnt jede unverschlüsselte SMTP-Verbindung zu Ihren MX-Servern ab und blockiert Downgrade-Angriffe
Der Übergang von testing zu enforce erfolgt in vier Schritten: initiale Bereitstellung, TLS-RPT-Konfiguration, Berichtsanalyse (1 bis 2 Wochen), dann Aktivierung von enforce
Hosten Sie Ihre MTA-STS-Richtlinie kostenlos mit CaptainDNS: zwei DNS-Einträge genügen

Eine MTA-STS-Richtlinie im Enforce-Modus zu veröffentlichen, ohne vorher zu testen, ist wie eine Firewall zu aktivieren, ohne den legitimen Datenverkehr zu kennen. Mögliches Ergebnis: blockierte E-Mails, Partner, die Ihnen nicht mehr schreiben können, und keinerlei Einblick in die Ursache. Laut dem Google Transparency Report wird über 90 % des eingehenden Gmail-Verkehrs bereits per TLS übertragen, doch ohne MTA-STS gibt es keine Garantie, dass diese Verschlüsselung erzwungen statt nur opportunistisch ist.

RFC 8461 sieht genau dieses Szenario vor. Er definiert zwei Betriebsmodi: testing (beobachten ohne zu blockieren) und enforce (unverschlüsselte Verbindungen blockieren). Die richtige Strategie besteht darin, zuerst im Testing-Modus bereitzustellen, die TLS-RPT-Berichte ein bis zwei Wochen zu überwachen, Anomalien zu beheben und dann in den Enforce-Modus zu wechseln.

Dieser Leitfaden beschreibt jeden Schritt dieses Übergangs. Er richtet sich an Systemadministratoren, DevOps-Teams und E-Mail-Sicherheitsverantwortliche, die eine oder mehrere E-Mail-Domains verwalten.

Die MTA-STS-Modi verstehen: testing vs enforce

MTA-STS (RFC 8461) erzwingt TLS-Verschlüsselung für eingehende E-Mails durch eine per HTTPS veröffentlichte Richtlinie mit drei Parametern: die autorisierten MX-Server, die Cache-Dauer (max_age) und der Modus (testing oder enforce).

Testing-Modus: überwachen ohne zu blockieren

Der MTA-STS-Testing-Modus ermöglicht es sendenden Servern (Gmail, Outlook, Yahoo), Ihre Richtlinie zu prüfen, ohne die Zustellung bei einem TLS-Fehler zu blockieren. Anomalien werden per TLS-RPT-Bericht (RFC 8460) an die von Ihnen konfigurierte Adresse gemeldet.

version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400

Dieser Modus ermöglicht die Erkennung von drei Problemtypen, bevor sie die Zustellung beeinträchtigen:

Ungültiges TLS-Zertifikat: abgelaufenes Zertifikat, falscher Domainname oder unvollständige Vertrauenskette
Nicht gelisteter MX: ein MX-Server empfängt E-Mails, erscheint aber nicht in der Richtlinie
TLS-Aushandlungsfehler: der MX-Server unterstützt kein STARTTLS oder lehnt die verschlüsselte Verbindung ab

Enforce-Modus: TLS-Verschlüsselung erzwingen

Der MTA-STS-Enforce-Modus verpflichtet sendende Server, die Zustellung abzulehnen, wenn die TLS-Verbindung fehlschlägt oder der MX-Server nicht in der Richtlinie aufgeführt ist.

version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800

Dieser Modus bietet echten Schutz gegen SMTP-Downgrade-Angriffe. Ein Angreifer, der versucht, STARTTLS zu entfernen oder auf einen gefälschten MX-Server umzuleiten, kann die E-Mails nicht abfangen: der sendende Server wird die Zustellung verweigern.

Diagramm der schrittweisen MTA-STS-Bereitstellung: testing dann enforce

Schritt 1: MTA-STS im Testing-Modus bereitstellen

Die initiale Bereitstellung erfordert zwei DNS-Elemente und eine HTTPS-Richtliniendatei.

DNS-TXT-Eintrag

Veröffentlichen Sie einen TXT-Eintrag unter _mta-sts.captaindns.com:

_mta-sts.captaindns.com.  IN  TXT  "v=STSv1; id=20260310T000000"

Das Feld id ist eine Versionskennung. Erhöhen Sie sie bei jeder Richtlinienänderung, damit sendende Server die neue Version herunterladen.

HTTPS-Richtliniendatei

Die Datei muss unter https://mta-sts.captaindns.com/.well-known/mta-sts.txt erreichbar sein. Mit CaptainDNS genügen zwei CNAME-Einträge: kein Webserver zu verwalten, kein Zertifikat zu erneuern.

Beginnen Sie mit einem kurzen max_age (86.400 Sekunden = 1 Tag), um bei Problemen schnell korrigieren zu können:

version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400

Überprüfung

Nutzen Sie den MTA-STS-Prüfer, um zu bestätigen, dass Ihr DNS-Eintrag und Ihre Richtlinie korrekt veröffentlicht sind.

Schritt 2: TLS-RPT für den Berichtsempfang konfigurieren

Ohne TLS-RPT ist der Testing-Modus nutzlos. Sendende Server erkennen zwar Probleme, haben aber keine Möglichkeit, diese zu melden.

DNS-TLS-RPT-Eintrag

Veröffentlichen Sie einen TXT-Eintrag unter _smtp._tls.captaindns.com:

_smtp._tls.captaindns.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

TLS-RPT-Berichte (RFC 8460) werden täglich im JSON-Format versendet. Jeder Bericht enthält:

Die Absender- und Empfängerdomain
Den angewandten Richtlinientyp (MTA-STS oder DANE)
Die Anzahl erfolgreicher und fehlgeschlagener Sitzungen
Details zu Fehlern: Fehlertyp, vorgelegtes Zertifikat, Ergebniscode

Mit CaptainDNS konfigurieren

Der TLS-RPT-Generator erstellt den passenden DNS-Eintrag für Ihre Domain. Sie können die Berichte an eine E-Mail-Adresse oder einen HTTPS-Endpunkt weiterleiten.

Schritt 3: Berichte analysieren und Probleme beheben

Warten Sie 1 bis 2 Wochen im Testing-Modus, bevor Sie zu enforce wechseln. Dieser Zeitraum ermöglicht es, genügend TLS-RPT-Berichte zu sammeln, um wiederkehrende Probleme zu identifizieren.

Berichte interpretieren

Fehlertyp	Wahrscheinliche Ursache	Behebung
`certificate-expired`	TLS-Zertifikat des MX-Servers abgelaufen	Zertifikat erneuern
`certificate-host-mismatch`	CN/SAN des Zertifikats stimmt nicht mit dem MX-Namen überein	Zertifikat oder Richtlinie korrigieren
`starttls-not-supported`	MX-Server unterstützt kein STARTTLS	STARTTLS auf dem Server aktivieren
`sts-policy-fetch-error`	HTTPS-Richtlinie nicht erreichbar	DNS-CNAME und HTTPS-Server prüfen
`sts-webpki-invalid`	HTTPS-Zertifikat der Richtlinie ungültig	Webserver-Zertifikat erneuern
`validation-failure`	MX nicht in der Richtlinie aufgeführt	Fehlenden MX zur Richtlinie hinzufügen

Kriterien für den Wechsel zu enforce

Bevor Sie den Enforce-Modus aktivieren, prüfen Sie diese drei Bedingungen:

Null wiederkehrende TLS-Fehler in den Berichten der letzten 7 Tage
Alle Ihre MX-Server sind in der Richtlinie aufgeführt
Gültige TLS-Zertifikate auf jedem MX-Server (nicht abgelaufen, korrekte CN/SAN)

Falls Fehler bestehen bleiben, beheben Sie diese zuerst. Ein vorzeitiger Wechsel zu enforce blockiert E-Mails von Servern, die auf diese Fehler stoßen.

Checkliste der Prüfungen vor dem Wechsel in den Enforce-Modus

Schritt 4: In den Enforce-Modus wechseln

Der Übergang erfordert zwei Änderungen: die Richtliniendatei und den DNS-Eintrag.

Richtlinie ändern

Ändern Sie mode: testing in mode: enforce und erhöhen Sie max_age auf 604.800 Sekunden (7 Tage):

version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800

Ein max_age von 7 Tagen bietet einen guten Kompromiss: lang genug, damit sendende Server die Richtlinie cachen (TOFU-Schutz), kurz genug, um bei Bedarf zum Testing-Modus zurückkehren zu können.

DNS-Kennung aktualisieren

Erhöhen Sie die id im TXT-Eintrag, um die Aktualisierung zu erzwingen:

_mta-sts.captaindns.com.  IN  TXT  "v=STSv1; id=20260310T120000"

Rollback-Strategie

Falls nach dem Wechsel zu enforce Probleme auftreten:

Wechseln Sie sofort zurück zu mode: testing
Erhöhen Sie die DNS-id
Warten Sie auf den Ablauf des vorherigen max_age (maximal 7 Tage)
Analysieren Sie die neuen TLS-RPT-Berichte
Beheben Sie die Probleme, bevor Sie den Wechsel zu enforce erneut versuchen

Häufige Fehler und Lösungen

Fehler	Konsequenz	Lösung
Zu enforce wechseln ohne TLS-RPT	Keine Sichtbarkeit bei Blockierungen	TLS-RPT immer vor enforce konfigurieren
`max_age` zu lang im Testing-Modus	Langsame Korrektur bei Problemen	86.400 s (1 Tag) im Testing-Modus verwenden
`max_age` zu kurz im Enforce-Modus	Reduzierter TOFU-Schutz	604.800 s (7 Tage) im Enforce-Modus verwenden
MX-Server in der Richtlinie vergessen	E-Mails werden im Enforce-Modus abgelehnt	Alle MX mit `dig MX captaindns.com` auflisten
`id` nicht erhöht	Sendende Server verwenden die alte Richtlinie	`id` nach jeder Änderung aktualisieren
Abgelaufenes TLS-Zertifikat	Validierungsfehler im Enforce-Modus	Erneuerung automatisieren (Let's Encrypt)

Empfohlener Aktionsplan

Aktuelle Konfiguration prüfen: Starten Sie eine Analyse mit dem MTA-STS-Prüfer
Im Testing-Modus bereitstellen: Veröffentlichen Sie Ihre Richtlinie mit mode: testing und max_age: 86400
TLS-RPT aktivieren: Konfigurieren Sie den _smtp._tls-Eintrag für den täglichen Berichtsempfang
1 bis 2 Wochen überwachen: Analysieren Sie jeden Bericht, beheben Sie TLS-Fehler
Zu enforce wechseln: Ändern Sie mode: enforce, erhöhen Sie max_age auf 604.800 s, aktualisieren Sie die id

Sichern Sie den Transport Ihrer E-Mails jetzt ab: Hosten Sie Ihre MTA-STS-Richtlinie kostenlos mit CaptainDNS. Zwei DNS-Einträge, kein Webserver, aktiver Schutz in 5 Minuten.

FAQ

Was ist der Unterschied zwischen dem Testing- und dem Enforce-Modus von MTA-STS?

Im Testing-Modus prüfen sendende Server Ihre MTA-STS-Richtlinie, stellen E-Mails aber auch bei einem TLS-Fehler zu. Sie senden einen TLS-RPT-Bericht, um das Problem zu melden. Im Enforce-Modus verweigern die Server die Zustellung, wenn TLS fehlschlägt oder der MX-Server nicht in der Richtlinie aufgeführt ist.

Wie lange sollte man im Testing-Modus bleiben, bevor man zu enforce wechselt?

Mindestens 1 bis 2 Wochen. Dieser Zeitraum ermöglicht es, genügend TLS-RPT-Berichte von den wichtigsten Absendern (Gmail, Outlook, Yahoo) zu sammeln. Wenn die Berichte über 7 aufeinanderfolgende Tage null TLS-Fehler zeigen, können Sie zu enforce wechseln.

Was passiert, wenn man direkt zu enforce wechselt, ohne die Testing-Phase?

E-Mails von Servern, die ein TLS-Problem mit Ihren MX-Servern haben, werden abgelehnt. Ohne vorherige TLS-RPT-Berichte haben Sie keinen Einblick in diese Ablehnungen. Partner oder Kunden könnten Ihnen keine E-Mails mehr senden, ohne dass Sie es bemerken.

Welchen max_age-Wert sollte man im Testing- und im Enforce-Modus verwenden?

Im Testing-Modus verwenden Sie 86.400 Sekunden (1 Tag). Diese kurze Dauer ermöglicht eine schnelle Korrektur der Richtlinie bei erkannten Problemen. Im Enforce-Modus wechseln Sie zu 604.800 Sekunden (7 Tage), um die TOFU-Schwachstelle zu reduzieren: sendende Server cachen die Richtlinie länger.

Wie kann man nach der Aktivierung von enforce zum Testing-Modus zurückkehren?

Ändern Sie die Richtliniendatei zurück auf mode: testing und erhöhen Sie die id im DNS-TXT-Eintrag. Sendende Server, die die Enforce-Richtlinie gecacht haben, wenden diese bis zum Ablauf des vorherigen max_age weiter an (maximal 7 Tage).

Ist TLS-RPT für MTA-STS obligatorisch?

Nein, TLS-RPT ist technisch nicht erforderlich, damit MTA-STS funktioniert. Aber ohne TLS-RPT haben Sie keinen Einblick in TLS-Fehler. In der Praxis ist MTA-STS ohne TLS-RPT wie ein Blindflug. Beide Protokolle sind für den gemeinsamen Einsatz konzipiert.

Respektieren Gmail und Outlook den Testing-Modus von MTA-STS?

Ja. Gmail, Outlook und Yahoo prüfen MTA-STS-Richtlinien im Testing-Modus und senden TLS-RPT-Berichte an die konfigurierte Adresse. Im Testing-Modus stellen sie E-Mails auch bei TLS-Fehlern normal zu, melden das Problem aber im täglichen Bericht.

Deployment-Checkliste herunterladen

Assistenten können die Checkliste über die JSON- oder CSV-Exporte unten wiederverwenden.

Glossar

MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Per HTTPS veröffentlichte Richtlinie, die TLS-Verschlüsselung für den E-Mail-Empfang einer Domain erzwingt.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mechanismus für tägliche Berichte, der fehlgeschlagene TLS-Aushandlungen zwischen E-Mail-Servern meldet.
TOFU: Trust On First Use. Sicherheitsmodell, bei dem die erste Verbindung nicht verifiziert wird, nachfolgende Verbindungen aber anhand der gecachten Daten validiert werden.
max_age: Dauer (in Sekunden), während der ein sendender Server die MTA-STS-Richtlinie im Cache behält. Bestimmt die Aktualisierungsfrequenz.
STARTTLS: SMTP-Erweiterung (RFC 3207), die nach dem Aufbau einer Klartextverbindung auf Port 25 eine TLS-Verbindung aushandelt.
SMTP-Downgrade: Netzwerkangriff, der die STARTTLS-Aushandlung entfernt, um E-Mails im Klartext abzufangen.