MTA-STS und TLS Reporting: Mehr Sicherheit für den Mailtransport

Beim Versand von E-Mails ist Verschlüsselung heute selbstverständlich – trotzdem ist sie nicht automatisch erzwungen. SMTP startet traditionell mit einer opportunistischen TLS-Verbindung: Unterstützt der empfangende Server TLS, wird die Verbindung verschlüsselt. Gibt es dabei aber ein Zertifikatsproblem oder wird STARTTLS manipuliert, kann eine Nachricht im ungünstigsten Fall verspätet oder über eine weniger geschützte Verbindung zugestellt werden.

Mit MTA-STS und SMTP TLS Reporting gibt es zwei ergänzende Verfahren, die genau hier ansetzen. MTA-STS beschreibt, wie ein empfangender Mailserver sicher per TLS erreicht werden muss. TLS Reporting liefert anschließend Hinweise darüber, ob die Zustellung funktioniert oder wo Probleme auftreten.

Was ist MTA-STS?

MTA-STS steht für Mail Transfer Agent Strict Transport Security. Eine Domain veröffentlicht damit eine Richtlinie, nach der sendende Mailserver nur verschlüsselte Verbindungen zu den eigenen MX-Servern verwenden sollen. Zusätzlich wird festgelegt, dass das Zertifikat des Zielservers gültig und vertrauenswürdig sein muss.

Die Richtlinie liegt nicht direkt im DNS, sondern unter einer festen HTTPS-Adresse:

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

Über einen DNS-TXT-Eintrag wird diese Richtlinie angekündigt:

_mta-sts.example.de TXT "v=STSv1; id=20261007"

Die id ist eine frei wählbare Versionskennung. Sie sollte geändert werden, sobald die veröffentlichte Richtlinie angepasst wird. Dadurch erkennen sendende Systeme, dass sie die Datei erneut abrufen sollten.

Wie sieht eine MTA-STS-Richtlinie aus?

Die Datei mta-sts.txt enthält einfache Zeilen, zum Beispiel:

version: STSv1
mode: testing
mx: mail.example.de
max_age: 86400

Die wichtigsten Angaben sind:

• version: STSv1 kennzeichnet das Format.
• mode: testing lässt zunächst Beobachtung und Tests zu, ohne Zustellungsfehler direkt zu erzwingen.
• mode: enforce verlangt eine gültige TLS-Verbindung zu einem passenden MX-Server. Bei Fehlern soll die Nachricht nicht über einen unsicheren Weg zugestellt werden.
• mode: none deaktiviert die Durchsetzung, kann aber weiterhin als Übergang dienen.
• mx nennt die erlaubten MX-Ziele. Mehrere MX-Einträge können jeweils in einer eigenen Zeile angegeben werden.
• max_age legt fest, wie lange die Richtlinie zwischengespeichert werden darf.

Warum sollte man mit testing beginnen?

enforce erhöht den Schutz, kann bei einer falschen Konfiguration aber auch legitime E-Mails verzögern oder unzustellbar machen. Deshalb sollte zuerst geprüft werden, ob alle MX-Server über gültige Zertifikate erreichbar sind und ob die Namen in der Richtlinie tatsächlich zur Mailinfrastruktur passen.

Für eine saubere Einführung bietet sich zunächst testing mit einer kurzen Gültigkeitsdauer an. Erst wenn die Berichte keine unerwarteten Zustellungsprobleme zeigen, sollte man auf enforce umstellen und die Gültigkeitsdauer schrittweise verlängern.

Was ist SMTP TLS Reporting?

SMTP TLS Reporting – kurz TLS-RPT – ist ein Berichtsmechanismus für Fehler und Statistiken beim verschlüsselten Mailtransport. Empfangende Domains veröffentlichen dazu einen TXT-Eintrag unter _smtp._tls. Sendende Mailserver können dann zusammengefasste Berichte an die dort angegebene Adresse oder HTTPS-Schnittstelle schicken.

Ein Beispiel für einen DNS-Eintrag sieht so aus:

_smtp._tls.example.de TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.de"

Die Adresse muss zu einem Dienst gehören, der TLS-RPT-Berichte annehmen und auswerten kann. Sie ist nicht automatisch identisch mit einem DMARC-Postfach. Für meine Domain würde ich deshalb einen vom Mailanbieter oder Reporting-Dienst vorgesehenen Empfänger verwenden und nicht einfach die DMARC-Adresse wiederverwenden.

Was steht in einem TLS-Report?

Ein TLS-Report enthält normalerweise keine Nachrichteninhalte. Er fasst für einen Zeitraum zusammen, wie viele Zustellversuche erfolgreich waren und welche Fehler aufgetreten sind. Dazu können unter anderem fehlende TLS-Unterstützung, Zertifikatsfehler, DNS-Probleme oder eine nicht passende MTA-STS-Richtlinie gehören.

Das macht TLS-RPT vor allem für die Fehlersuche wertvoll: Ein Bericht kann zeigen, dass ein Mailserver noch ein altes Zertifikat ausliefert oder dass ein MX-Ziel in der Richtlinie fehlt, bevor ein Problem von einem Absender gemeldet wird.

MTA-STS und TLS-RPT gehören zusammen

1. MTA-STS beschreibt, welche verschlüsselte Verbindung erwartet wird.
2. Der sendende Mailserver versucht, diese Vorgabe umzusetzen.
3. TLS-RPT meldet zusammengefasste Erfolge und Fehler zurück.
4. Die Berichte helfen dabei, die Konfiguration zu korrigieren und später sicher auf enforce umzustellen.

Beide Verfahren ersetzen weder SPF, DKIM noch DMARC. SPF und DKIM authentifizieren den Absender beziehungsweise die Nachricht. DMARC legt fest, wie Empfänger mit fehlgeschlagenen Authentifizierungen umgehen. MTA-STS und TLS-RPT schützen dagegen den Transportweg zwischen den Mailservern und machen Probleme bei dieser Verbindung sichtbar.

Worauf sollte man bei der Einrichtung achten?

• Die MTA-STS-Datei muss über HTTPS erreichbar sein und ein gültiges Zertifikat verwenden.
• Alle produktiven MX-Ziele müssen in der Richtlinie berücksichtigt werden.
• Die DNS-TXT-Einträge sollten exakt veröffentlicht werden; zusätzliche Anführungszeichen oder Tippfehler können die Auswertung verhindern.
• Vor enforce sollte die Richtlinie zunächst mit testing und TLS-RPT-Berichten beobachtet werden.
• Die Report-Adresse sollte regelmäßig geprüft werden, weil sie technische Daten zum Mailverkehr erhalten kann.
• Nach Änderungen an MX, Zertifikaten oder Mailprovidern müssen MTA-STS, TLS-RPT, SPF, DKIM und DMARC gemeinsam überprüft werden.

Mein Fazit

MTA-STS macht die gewünschte TLS-Verbindung zwischen Mailservern verbindlicher. TLS Reporting ergänzt diese Vorgabe um eine praktische Rückmeldung aus dem laufenden Betrieb. Zusammen entsteht eine gute Grundlage, um verschlüsselte Mailzustellung nicht nur zu aktivieren, sondern auch dauerhaft zu kontrollieren.

Die konkrete Konfiguration sollte immer zu den tatsächlich verwendeten MX-Servern, Zertifikaten und Mailanbietern passen. Ein Beispiel aus einem Artikel darf deshalb nicht unverändert für eine fremde Domain übernommen werden.

Weiterführend: RFC 8461 zu MTA-STS und RFC 8460 zu SMTP TLS Reporting.

← Zurück zum Blog