Was ist der Unterschied zwischen mode enforce, testing und none?

enforce = Sender müssen TLS mit gültigem Zertifikat nutzen, sonst keine Zustellung. testing = Verstöße werden nur per TLS-RPT gemeldet, zugestellt wird trotzdem. none = Policy deaktiviert, Signal an Sender, sie zu vergessen.

Wie richte ich MTA-STS ein?

Die mta-sts-Subdomain mit gültigem HTTPS-Zertifikat aufsetzen und die Datei unter /.well-known/mta-sts.txt bereitstellen (version, mode, mx, max_age). Dann den TXT-Record _mta-sts mit v=STSv1 und einem id-Wert setzen. Mit mode: testing plus TLS-RPT beginnen, nach fehlerfreier Beobachtung auf enforce wechseln.

Meine mta-sts.txt ist nicht erreichbar, woran liegt das?

Häufig: die Subdomain hat kein eigenes Zertifikat, es wird auf HTTP oder auf die Hauptdomain weitergeleitet, der Pfad stimmt nicht exakt, oder der Content-Type ist nicht text/plain. RFC 8461 verlangt HTTPS ohne Redirects unter genau diesem Pfad.

Wozu dient der mx-Abgleich?

Jeder MX-Host der Domain muss zu mindestens einem mx:-Muster der Policy passen. Passt ein MX zu keinem Muster, schlägt bei enforce die Zustellung dorthin fehl.

Brauche ich MTA-STS, wenn ich schon DANE habe?

Nicht zwingend, beide erzwingen TLS. DANE setzt DNSSEC voraus, MTA-STS die Web-PKI. Wer beides veröffentlicht, erreicht sowohl Sender mit DNSSEC-Validierung als auch solche ohne. Ein Widerspruch entsteht dabei nicht.

Was bringt der TLS-RPT-Record?

Über _smtp._tls veröffentlicht die Domain eine rua-Adresse, an die sendende Server tägliche Berichte über erfolgreiche und fehlgeschlagene TLS-Zustellungen schicken. Ohne ihn merkt man MTA-STS- oder STARTTLS-Probleme erst, wenn Mail ausbleibt.

MTA-STS und TLS-RPT Check

MTA-STS-Record und HTTPS-Policy prüfen, MX-Abgleich, Zertifikat, TLS-RPT.

MTA-STS sorgt dafür, dass sendende Mailserver eine Domain nur über TLS mit gültigem Zertifikat erreichen und sich nicht per Man-in-the-Middle auf eine unverschlüsselte Verbindung herabstufen lassen. SMTP kennt Transportverschlüsselung nur als Option (STARTTLS); MTA-STS macht sie für eine Domain verbindlich und schließt die Downgrade-Lücke. TLS-RPT ist der dazugehörige Berichtskanal, über den sendende Server melden, wenn eine TLS-Zustellung fehlschlägt.

Was dieses Werkzeug prüft

MTA-STS besteht aus zwei Teilen. Dieses Werkzeug holt den TXT-Record unter _mta-sts.<domain> (Version und id) und die Policy-Datei unter https://mta-sts.<domain>/.well-known/mta-sts.txt. Es prüft die Syntax der Policy (version, mode, max_age, mx), gleicht jedes mx:-Muster gegen die tatsächlichen MX-Records der Domain ab und zeigt Aussteller und Restlaufzeit des Zertifikats der mta-sts-Subdomain. Der HTTPS-Abruf läuft über einen SSRF-Schutz, nur https, ohne Weiterleitungen. Zusätzlich wird der TLS-RPT-Record unter _smtp._tls.<domain> gelesen und die rua-Ziele geprüft.

Das Ergebnis lesen

Grün heißt: TXT-Record und Policy vorhanden und syntaktisch sauber, mode: enforce, ein vertrauenswürdiges Zertifikat und jeder MX von einem mx:-Muster gedeckt. mode: testing ist eine Warnung: sinnvoll für die Einführung, aber ohne Schutzwirkung. Ein Fehler steht für eine nicht erreichbare oder ungültige Policy bei vorhandenem TXT-Record, für ein abgelaufenes oder nicht vertrauenswürdiges Zertifikat der mta-sts-Subdomain oder für einen MX, den kein Muster deckt. Fehlt TLS-RPT, ist das nur ein Hinweis.

Grundlagen

MTA-STS ist in RFC 8461 definiert, TLS-RPT in RFC 8460. RFC 8461 verlangt für die Policy HTTPS mit einem gültigen, öffentlich vertrauenswürdigen Zertifikat für mta-sts.<domain> und verbietet das Folgen von HTTP-Weiterleitungen. Eine Policy-Änderung wird über einen neuen id-Wert im TXT-Record signalisiert, sonst nutzen Sender die gecachte Fassung bis max_age abläuft. MTA-STS und DANE (RFC 7672) verfolgen dasselbe Ziel über unterschiedliche Vertrauensanker (Web-PKI gegen DNSSEC) und schließen sich nicht aus.

Typische Fehlerbilder und wie man sie behebt

TXT-Record da, Policy nicht erreichbar. Die mta-sts-Subdomain braucht einen erreichbaren HTTPS-Endpunkt mit gültigem Zertifikat und der Datei unter dem exakten Pfad /.well-known/mta-sts.txt, ausgeliefert als text/plain. Kein HTTP, keine Weiterleitung auf die Hauptdomain.
Dauerhaft mode: testing. Testing meldet nur, erzwingt nichts. Sobald die TLS-RPT-Berichte keine Fehlversuche mehr zeigen, auf enforce stellen und dabei den id-Wert im TXT-Record ändern.
MX nicht von einem mx:-Muster gedeckt. Bei enforce lehnen konforme Sender die Zustellung an diesen Host ab. Die Policy so ergänzen, dass jeder aktuelle MX-Hostname passt, Wildcards wie *.example.net sind erlaubt.
Policy geändert, Sender nutzen die alte. Der id im TXT-Record muss sich bei jeder Policy-Änderung ändern, sonst greift der Cache bis max_age (oft eine Woche oder mehr).
Zertifikat der mta-sts-Subdomain abgelaufen. Damit wird die Policy für Sender ungültig und der Schutz fällt aus. Das Zertifikat in die automatische Erneuerung aufnehmen wie jedes andere.

Ausführlicher Hintergrund im Blogartikel MTA-STS (Strict Transport Security) auf frankysweb.de.

Häufige Fragen

Was ist der Unterschied zwischen mode enforce, testing und none?: enforce = Sender müssen TLS mit gültigem Zertifikat nutzen, sonst keine Zustellung. testing = Verstöße werden nur per TLS-RPT gemeldet, zugestellt wird trotzdem. none = Policy deaktiviert, Signal an Sender, sie zu vergessen.
Wie richte ich MTA-STS ein?: Die mta-sts-Subdomain mit gültigem HTTPS-Zertifikat aufsetzen und die Datei unter /.well-known/mta-sts.txt bereitstellen (version, mode, mx, max_age). Dann den TXT-Record _mta-sts mit v=STSv1 und einem id-Wert setzen. Mit mode: testing plus TLS-RPT beginnen, nach fehlerfreier Beobachtung auf enforce wechseln.
Meine mta-sts.txt ist nicht erreichbar, woran liegt das?: Häufig: die Subdomain hat kein eigenes Zertifikat, es wird auf HTTP oder auf die Hauptdomain weitergeleitet, der Pfad stimmt nicht exakt, oder der Content-Type ist nicht text/plain. RFC 8461 verlangt HTTPS ohne Redirects unter genau diesem Pfad.
Wozu dient der mx-Abgleich?: Jeder MX-Host der Domain muss zu mindestens einem mx:-Muster der Policy passen. Passt ein MX zu keinem Muster, schlägt bei enforce die Zustellung dorthin fehl.
Brauche ich MTA-STS, wenn ich schon DANE habe?: Nicht zwingend, beide erzwingen TLS. DANE setzt DNSSEC voraus, MTA-STS die Web-PKI. Wer beides veröffentlicht, erreicht sowohl Sender mit DNSSEC-Validierung als auch solche ohne. Ein Widerspruch entsteht dabei nicht.
Was bringt der TLS-RPT-Record?: Über _smtp._tls veröffentlicht die Domain eine rua-Adresse, an die sendende Server tägliche Berichte über erfolgreiche und fehlgeschlagene TLS-Zustellungen schicken. Ohne ihn merkt man MTA-STS- oder STARTTLS-Probleme erst, wenn Mail ausbleibt.