MTA-STS-Richtlinienprüfer

Ruft den _mta-sts-TXT-Eintrag und die mta-sts.txt-Richtliniendatei einer Domain ab, um zu prüfen, ob die verpflichtende TLS-Verschlüsselung beim Mailtransport (MTA-STS) korrekt konfiguriert ist.

Tipps

  • MTA-STS wird vom sendenden Server geprüft, nicht vom empfangenden. Sobald Sie es veröffentlichen, verlangen fremde Server bei E-Mails an Ihre Domain zwingend TLS.
  • Führen Sie MTA-STS zunächst einige Wochen bis einen Monat im Modus testing ein, bevor Sie zu enforce wechseln, damit unerwartete Zustellablehnungen nicht überraschen.
  • max_age wird üblicherweise zwischen 604800 Sekunden (7 Tage) und 31557600 Sekunden (1 Jahr) gesetzt. Ein zu kurzer Wert erzwingt häufigeres erneutes Abrufen der Richtliniendatei.
  • Im mx-Feld ist ein Platzhalter (*.example.com) möglich, doch der SAN (Subject Alternative Name) des TLS-Zertifikats muss zu diesem Platzhalter passen.
  • Nur den DNS-Eintrag oder nur die Richtliniendatei zu veröffentlichen bewirkt nichts — MTA-STS greift erst, wenn beide gleichzeitig vorhanden sind.

Häufige Fragen

Nicht zwangsläufig — die meisten Domains verwenden noch kein MTA-STS. Wer den Schutz gegen STARTTLS-Stripping-Angriffe verstärken möchte, sollte die Einführung aber in Erwägung ziehen.

SPF, DKIM und DMARC authentifizieren den Absender, um Spoofing zu verhindern. MTA-STS hat damit nichts zu tun — es erzwingt TLS-Verschlüsselung auf dem Transportweg selbst und schützt damit vor einer anderen Bedrohungsart.

Nicht auf der eigenen Domain, sondern unter /.well-known/mta-sts.txt auf einer Subdomain mit dem Präfix „mta-sts.“ (z. B. mta-sts.example.com), bereitgestellt mit einem gültigen TLS-Zertifikat.

Das wird nicht empfohlen. Betreiben Sie den Modus testing einige Wochen bis einen Monat, überwachen Sie die Zustellung mit TLS-RPT und wechseln Sie erst zu enforce, wenn Sie sicher sind, dass nichts unerwartet abgelehnt wird.

Dieses Tool prüft nur die Syntax und die Pflichtfelder von TXT-Eintrag und Richtliniendatei. Es validiert weder das TLS-Zertifikat noch führt es einen echten TLS-Handshake mit den gelisteten MX-Hosts durch. Für eine strengere Prüfung kombinieren Sie es mit einem spezialisierten Tool wie checktls.com.
ツールくん

Übrigens – Warum STARTTLS nicht ausreichte und wie MTA-STS entstand

Jahrzehntelang beruhte die Transportverschlüsselung bei SMTP auf STARTTLS (standardisiert 1999), das eine Verbindung im Klartext öffnet und erst danach auf TLS umstellt. 2014 bestätigten Sicherheitsforscher reale „STARTTLS-Stripping“-Angriffe: Da die STARTTLS-Aushandlung selbst noch vor Beginn der Verschlüsselung stattfindet, konnte ein Angreifer auf dem Übertragungsweg die Serverantwort so manipulieren, dass die STARTTLS-Unterstützung verborgen blieb — die Gegenseite fiel dann auf Klartext zurück.

Die Ursache war, dass STARTTLS bewusst so entworfen wurde, bei fehlender TLS-Unterstützung der Gegenseite auf Klartext zurückzufallen — eine Kompatibilitätsfunktion, die Angreifer ausnutzen konnten, indem sie einfach vortäuschten, TLS werde nicht unterstützt. Um 2015 zeigten eigene Messungen von Google, dass STARTTLS-Stripping in bestimmten Ländern und bei bestimmten Providern in großem Umfang stattfand.

MTA-STS (RFC 8461, veröffentlicht 2018) war die Antwort der Branche darauf, gemeinsam entwickelt von Google, Microsoft, Yahoo und weiteren. Eine Domain erklärt ihre MTA-STS-Unterstützung über einen DNS-TXT-Eintrag und veröffentlicht dann eine per HTTPS abgerufene Richtliniendatei mit den erlaubten MX-Hosts und TLS-Anforderungen. Nach dem Abruf wird die Richtlinie für die Dauer von max_age zwischengespeichert, sodass ein späterer Downgrade-Versuch erkannt und abgelehnt statt stillschweigend akzeptiert werden kann.

MTA-STS wird häufig mit TLS-RPT (TLS Reporting, RFC 8460) kombiniert, das Domaininhabern Berichte zukommen lässt, wenn ein sendender Server keine TLS-Verbindung aufbauen kann. MTA-STS übernimmt die Durchsetzung, TLS-RPT die Beobachtbarkeit — beides zusammen einzusetzen gilt heute als bewährte Praxis.