SPF, DKIM und DMARC authentifizieren den Absender einer E-Mail, aber keines der drei schützt den Weg, den eine Nachricht zwischen zwei SMTP-Servern nimmt. Ein böswilliger Server auf diesem Weg kann weiterhin einen Rückfall auf eine unverschlüsselte Verbindung anbieten und den Inhalt abfangen oder verändern, ohne dass Absender oder Empfänger etwas davon bemerken. MTA-STS (RFC 8461) schließt diese Lücke, indem es TLS bei der Zustellung erzwingt, und TLS-RPT (RFC 8460) liefert die Mittel, um Fehlschläge dieser Aushandlung Tag für Tag zu überwachen.
Das Problem, das MTA-STS löst: der stille TLS-Rückfall
Seit Jahren handeln die meisten SMTP-Server vor der Zustellung STARTTLS aus. Das Problem dabei: Diese Aushandlung bleibt opportunistisch. Schlägt sie fehl, erlaubt das klassische SMTP-Protokoll einen Rückfall auf eine unverschlüsselte Verbindung, statt den Versand zu blockieren. Ein Angreifer, der den Datenverkehr abfangen kann, etwa durch DNS-Hijacking, BGP-Hijacking oder einen kompromittierten Relay, kann diesen Rückfall einfach erzwingen, indem er die TLS-Aushandlung unterbricht, ohne jede Verschlüsselung knacken zu müssen. MTA-STS nimmt dem sendenden Server diese Wahl: Sobald die Policy veröffentlicht und respektiert wird, wird fehlendes gültiges TLS zum Ablehnungsgrund für den Versand statt zu einem stillen Rückfall. DANE, das auf DNSSEC setzt, verfolgt über einen anderen Weg dasselbe Ziel, doch sein Einsatz hängt von einer signierten DNS-Zone ab, die noch immer wenige Hoster standardmäßig anbieten; MTA-STS dagegen braucht nur einen TXT-Eintrag und eine HTTPS-Datei.
Eine MTA-STS-Policy Schritt für Schritt einrichten
Eine MTA-STS-Policy besteht aus drei Teilen: einem DNS-Eintrag, der ihre Existenz und Version anzeigt, einer über HTTPS auf einer eigenen Subdomain bereitgestellten Policy-Datei und einem gültigen Zertifikat für diese Subdomain. Nichts davon erfordert einen Eingriff in die Konfiguration des Mailservers selbst: Die Policy beschreibt das erwartete Verhalten fremder sendender Server, auf der Empfangsseite ändert sich nichts.
Der DNS-Eintrag sieht so aus:
_mta-sts.beispiel.de. IN TXT "v=STSv1; id=20261108000000;"
mta-sts.beispiel.de. IN CNAME beispiel.de.
Die Policy-Datei muss unter https://mta-sts.beispiel.de/.well-known/mta-sts.txt erreichbar sein, ausgeliefert mit dem Header Content-Type: text/plain:
version: STSv1
mode: testing
mx: mail.beispiel.de
mx: mail2.beispiel.de
max_age: 86400
Das Feld id im DNS-Eintrag muss sich bei jeder Änderung der Policy-Datei ändern: Daran erkennen Server, die die Policy bereits zwischengespeichert haben, dass eine neue Version existiert. Ein einfacher Zeitstempel, wie im Beispiel oben, genügt.
Die drei Modi verstehen: none, testing und enforce
Das Feld mode der Policy-Datei bestimmt das tatsächliche Verhalten der sendenden Server, die MTA-STS beachten.
| Modus | Verhalten bei TLS-Fehlschlag | Empfohlene Nutzung |
|---|---|---|
none | Keine Blockade, die Policy wird in der Praxis ignoriert | Vorübergehende Deaktivierung, ohne die Policy zu entfernen |
testing | Die E-Mail wird trotz Fehlschlag versendet, der Fehlschlag wird aber über TLS-RPT gemeldet | Beobachtungsphase vor dem produktiven Einsatz |
enforce | Die E-Mail wird ohne gültiges TLS nicht zugestellt | Endgültige Policy, nach Validierung im Testing-Modus |
enforce umzuschalten, ohne eine Testphase, birgt das Risiko, legitime E-Mails stillschweigend zu blockieren, wenn sich ein MX-Eintrag ändert, ein Zertifikat ohne automatische Erneuerung abläuft oder ein falsch konfiguriertes ausgehendes Relay bei der TLS-Aushandlung scheitert. Der über mehrere Wochen beibehaltene testing-Modus dient genau dazu, solche Fälle zu erkennen, bevor sie eine Zustellung kosten.TLS-RPT aktivieren, um Fehlerberichte zu erhalten
TLS-RPT funktioniert unabhängig von MTA-STS, doch beide ergänzen sich auf natürliche Weise: Das eine erzwingt die Verschlüsselung, das andere meldet, was passiert, wenn die Aushandlung scheitert, ob die Ursache nun MTA-STS, DANE oder eine klassische opportunistische TLS-Policy ist. Die Aktivierung beschränkt sich auf einen DNS-Eintrag:
_smtp._tls.beispiel.de. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Server, die TLS-RPT unterstützen, senden daraufhin einen meist täglichen, als komprimiertes JSON aufbereiteten Sammelbericht an die in rua angegebene Adresse. Das Prinzip gleicht den Sammelberichten aus dem Leitfaden zur SPF-, DKIM- und DMARC-Authentifizierung: eine regelmäßige Zusammenfassung statt eines Echtzeitalarms, für die automatisierte Verarbeitung gedacht statt für die tägliche manuelle Lektüre.
Einen TLS-RPT-Bericht lesen und nutzen
Ein TLS-RPT-Bericht gruppiert Verbindungsversuche nach beobachteter Policy, MTA-STS, DANE oder keiner, und nach Fehlertyp: abgelaufenes Zertifikat, ein Zertifikatsname, der nicht zum MX passt, eine gescheiterte Aushandlung selbst oder eine trotz Veröffentlichung nicht auffindbare MTA-STS-Policy. Eine Fehlerquote, die direkt nach einem Hoster- oder Zertifikatswechsel in die Höhe schnellt, ist oft das erste sichtbare Zeichen einer Fehlkonfiguration, noch bevor ein Empfänger ein Zustellproblem meldet.
Ein TLS-Rückfall auf eine unverschlüsselte Verbindung löst auf Senderseite keinen Alarm aus, wenn niemand ihn überwacht: TLS-RPT ist für den SMTP-Transport das, was Sammelberichte für DMARC in der Authentifizierung leisten.
Häufige Fallstricke und bewährte Vorgehensweisen
Drei Fehler tauchen in Deployments kleiner Versandinfrastruktur-Teams am häufigsten auf. Erstens, die automatische Erneuerung des Zertifikats der mta-sts-Subdomain zu vergessen, was eine enforce-Policy beim ersten verpassten Erneuerungstermin in eine Zustellblockade verwandelt. Zweitens, die MX-Liste zu ändern, ohne die Policy-Datei mit einer neuen id erneut zu veröffentlichen, wodurch sich sendende Server bis zum Ablauf von max_age auf eine zwischengespeicherte, inzwischen falsche Policy verlassen. Drittens, die Übereinstimmung zwischen der in der Policy angegebenen mx-Liste und den tatsächlichen MX-Einträgen der Domain zu vernachlässigen: Jede Abweichung lässt die Validierung auf Senderseite scheitern, unabhängig vom gewählten Modus.
Die vollständige Einrichtung dauert für eine Domain, die bereits die üblichen Ursachen für die Spam-Einstufung sowie ihre SPF-, DKIM- und DMARC-Authentifizierung im Griff hat, in der Regel zwei bis vier Wochen, wobei der Großteil der Zeit auf die Beobachtung des testing-Modus entfällt statt auf die technische Einrichtung selbst, die sich auf wenige DNS-Einträge und eine statische Datei beschränkt. Die meistgenutzten Plattformen für Transaktions-E-Mails dokumentieren mittlerweile ein eigenes MTA-STS-Verfahren, was den Zertifikats- und Hosting-Teil der Policy-Datei für alle vereinfacht, die keine eigenen ausgehenden Server betreiben.
Was man sich merken sollte
- MTA-STS verhindert den stillen Rückfall auf eine unverschlüsselte SMTP-Verbindung, indem es TLS bei der Zustellung erzwingt.
- Die Einrichtung umfasst einen DNS-Eintrag, eine HTTPS-Policy-Datei und einen gestuften Modus:
testingvorenforce. - TLS-RPT liefert Sammelberichte zu gescheiterten TLS-Aushandlungen, ob sie nun von MTA-STS, DANE oder einer opportunistischen Policy stammen.
- Ein nicht erneuertes Zertifikat oder eine nach einem MX-Wechsel nicht erneut veröffentlichte Policy sind im
enforce-Modus die beiden häufigsten Blockadeursachen.
MTA-STS bleibt bei Shared-Hosting-Anbietern und kleinen Infrastrukturen stark unterrepräsentiert, obwohl die technische Einrichtung spürbar einfacher ist als bei DMARC. Die eigentliche Hürde liegt in der Disziplin, die Policy bei jeder Änderung der Versandinfrastruktur erneut zu veröffentlichen, nicht in der Komplexität des Protokolls. Bei begleiteten Domains, die es eingeführt haben, hat die testing-Phase durchweg mindestens einen falsch konfigurierten sekundären MX aufgedeckt, den zuvor niemand bemerkt hatte, ein guter Grund, sie eher als kostenloses Audit zu behandeln denn als Sicherheitsformalität. — Simon Janvier
Zum Weiterlesen: die MTA-STS-Spezifikation (RFC 8461) und die TLS-RPT-Spezifikation (RFC 8460).
