MTA-STS und TLS-RPT zuerst im Testmodus veröffentlichen

SPF, DKIM und DMARC verhindern, dass andere Ihren Namen fälschen (Sie können Ihren DMARC-Eintrag prüfen). Keines der Verfahren verhindert jedoch, dass ein sendender Server Mails im Klartext an Sie zustellt. Mit MTA-STS veröffentlichen Sie eine Policy, die besagt, dass Ihre Mailserver authentifiziertes TLS unterstützen, und TLS-RPT meldet Ihnen, wenn Absender dies nicht erreichen konnten. Beides lässt sich mit zwei DNS-Einträgen und einer Textdatei ausrollen, und Sie können in einem Modus beginnen, der für einen schonenden Einstieg gedacht ist.

Was STARTTLS offenlässt

Die Verschlüsselung zwischen Mailservern nutzt die STARTTLS-Erweiterung und ist opportunistisch. RFC 8461 beschreibt die Schwachstelle: Ein Angreifer, der die Antwort "250 STARTTLS" aus der SMTP-Sitzung entfernen oder durch das Überschreiben des aufgelösten MX-Eintrags umleiten kann, kann ein Downgrade erzwingen oder die Sitzung abfangen.

DANE ist die andere Lösung und wird in RFC 7672 definiert, setzt aber DNSSEC voraus. MTA-STS stützt sich stattdessen auf Zertifizierungsstellen und kommt ohne DNSSEC aus, „auf Kosten des Risikos böswilliger Downgrades“, wie es der RFC selbst formuliert. Wenn Sie bereits DANE betreiben, gibt es keinen Konflikt: Absender, die MTA-STS implementieren, dürfen es nicht über eine fehlgeschlagene DANE-Validierung stellen.

Die NCSC-Empfehlungen zur E-Mail-Sicherheit besagen, dass Ihr Dienst in der Lage sein sollte, E-Mails per TLS zu senden und zu empfangen, und dass Sie alle Ihre Domains schützen sollten, auch solche bei Cloud-Anbietern wie Google G Suite und Microsoft O365.

Schritt eins: die Policy im Testmodus

MTA-STS besteht aus zwei Teilen. Ein TXT-Eintrag unter _mta-sts.example.com kündigt an, dass eine Policy existiert und welche Version sie hat:

_mta-sts.example.com. IN TXT "v=STSv1; id=20250101000000Z;"

Die id besteht aus Buchstaben und Ziffern, umfasst höchstens 32 Zeichen und muss diese Version der Policy eindeutig kennzeichnen. Eine Reihenfolge ist nicht impliziert, ein Zeitstempel ist also eher Gewohnheit als Pflicht. Veröffentlichen Sie genau einen solchen Eintrag: Absender verwerfen Einträge, die nicht mit v=STSv1; beginnen, und wenn danach nicht genau einer übrig ist, gehen sie davon aus, dass Sie keine Policy haben.

Die Policy selbst wird per HTTPS von einer festen Adresse abgerufen, die sich ergibt, indem man mta-sts vor Ihre Domain setzt:

https://mta-sts.example.com/.well-known/mta-sts.txt

Liefern Sie sie als text/plain aus, denn Absender sind angewiesen, den Medientyp zu prüfen. Die Datei sieht so aus:

version: STSv1
mode: testing
mx: mail.example.com
mx: *.example.net
max_age: 604800

Jede mx:-Zeile ist ein eigener Eintrag, entweder ein vollständiger Hostname oder ein Wildcard-Suffix wie *.example.net. Führen Sie jeden Host aus Ihren aktiven MX-Einträgen auf, auch den eines Cloud-Anbieters.

Die drei Modi sind enforce, testing und none. Der RFC beschreibt testing als optionalen Modus, der einen schonenden Rollout ermöglicht, bei dem Policy-Fehler erkannt werden. Deshalb beginnt man dort.

Der Wert max_age wird in Sekunden angegeben, höchstens 31557600, und 604800 (eine Woche) ist das Beispiel des RFC. Für den Produktivbetrieb erwartet der RFC typischerweise Werte im Bereich von Wochen oder mehr. Mein Rat: Halten Sie den Wert während des Testens bei höchstens einer Woche, damit eine korrigierte Policy die Absender schnell erreicht, und erhöhen Sie ihn, sobald enforce stabil läuft.

Schritt zwei: TLS-RPT aktivieren

Die Erkennung funktioniert nur, wenn Absender Ihnen mitteilen, was sie beobachtet haben. Dazu veröffentlichen Sie einen TXT-Eintrag unter _smtp._tls.example.com:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:tlsrpt@example.com"

Die rua kann auch ein https-URI sein, an den Absender den Report per POST senden, und eine kommagetrennte Liste ist zulässig. Wie beim MTA-STS-Eintrag muss genau ein TXT-Eintrag mit v=TLSRPTv1; beginnen, sonst gehen Absender davon aus, dass Sie TLS-RPT nicht umsetzen.

Wenn Sie sich für mailto entscheiden, verwenden Sie ein dediziertes Postfach. Absender liefern diese Reports auch dann aus, wenn TLS fehlschlägt, ein Report kann also unverschlüsselt eintreffen. Per E-Mail gesendete Reports müssen eine gültige DKIM-Signatur der meldenden Domain tragen, und laut RFC müssen Empfänger Reports ohne Signatur ignorieren. Verwerfen Sie unsignierte Reports, statt auf sie zu reagieren.

Prüfen, was Absender sehen

Fragen Sie beide Einträge ab und rufen Sie die Policy-Datei von außerhalb Ihres Netzwerks ab:

dig TXT _mta-sts.example.com
dig TXT _smtp._tls.example.com
curl -si https://mta-sts.example.com/.well-known/mta-sts.txt

Die dig-Ausgabe sollte je einen Eintrag zeigen, mit dem Präfix v= an erster Stelle. Die curl-Ausgabe sollte 200, Content-Type: text/plain und den Policy-Inhalt zeigen. Prüfen Sie daher, ob mode und jede mx:-Zeile Ihren Vorgaben entsprechen. Beheben Sie jeden von curl gemeldeten Zertifikatsfehler, bevor Sie den TXT-Eintrag veröffentlichen.

Reports lesen

Reports sind JSON-Dateien, die einen Zeitraum abdecken und eine Zustellübersicht mit Erfolgs- und Fehlerzahlen enthalten. Der RFC gliedert Fehler in Verhandlungsfehler (negotiation), Policy-Fehler, allgemeine Fehler und vorübergehende Fehler (transient). Reports können komprimiert eintreffen (der RFC definiert application/tlsrpt+gzip), entpacken Sie sie also zuerst:

gzip -dc report.json.gz | jq .

Die Feldnamen sind in Abschnitt 4.4 von RFC 8460 definiert. Lesen Sie zuerst die Summenzahlen, dann die Fehlereinträge.

Ein Report mit hoher Erfolgsquote und ohne Fehler ist das, was Sie sehen möchten. Der RFC merkt an, dass ein Report als Heartbeat dienen kann, der zeigt, dass TLS wie erwartet ausgehandelt wird, und eine stetige Reihe fehlerfreier Reports ist Ihr Nachweis für den nächsten Schritt. Fehler, die einen Ihrer eigenen MX-Hosts nennen, deuten auf ein Zertifikat oder ein mx-Muster hin, das Sie korrigieren müssen. Ein einzelner Absender mit defektem Stack ist dagegen dessen Problem.

Ein Anstieg der STARTTLS-Fehler, den Sie keiner Änderung zuordnen können, gehört zu den Verantwortlichen für Incidents oder, falls Sie niemanden haben, zu unserem Incident-Response-Team.

Umstellung auf enforce

Warten Sie, bis die Reports über Ihre üblichen Mailmuster hinweg sauber sind, einschließlich seltener Absender wie monatlicher Rechnungssysteme. Ändern Sie dann mode: testing in mode: enforce und ändern Sie die id im TXT-Eintrag, denn Absender vergleichen sie mit ihrer zwischengespeicherten Kopie, um zu erkennen, dass sich etwas geändert hat.

Absender dürfen eine Policy bis zu max_age ab dem letzten Abruf zwischenspeichern, ein Fehler kann also länger nachwirken. Auch das Löschen des TXT-Eintrags entfernt eine zwischengespeicherte Policy nicht, wie der RFC betont. RFC 8461 Abschnitt 8.3 behandelt das Entfernen, und Sie sollten ihn lesen, bevor Sie ihn brauchen.

Der Einstieg

1. Listen Sie Ihre aktiven MX-Hosts auf, auch die eines Cloud-Anbieters, und stellen Sie sicher, dass jeder ein gültiges, zum Namen passendes Zertifikat vorweist.
2. Richten Sie den Host mta-sts über HTTPS ein und liefern Sie die Policy-Datei als text/plain mit mode: testing aus.
3. Veröffentlichen Sie den einen _mta-sts-TXT-Eintrag mit einer neuen id und führen Sie dann die oben genannten Prüfungen mit dig und curl durch.
4. Veröffentlichen Sie den _smtp._tls-TXT-Eintrag mit Verweis auf ein dediziertes Postfach oder einen HTTPS-Endpunkt und prüfen Sie Ihr Gesamtsetup mit unserem E-Mail-Security-Checker.
5. Werten Sie die Reports mindestens über einen vollständigen Geschäftszyklus aus, einschließlich der Läufe zum Monatsende (für die meisten Organisationen sind das ein Monat). Beheben Sie jeden Fehler in Ihrem Verantwortungsbereich, stellen Sie dann auf enforce um und ändern Sie die id.