Im Jahr 2015 zeigten Forschende etwas, das jedes Unternehmen, das sensible E-Mails verarbeitet, hätte erschrecken müssen: Sie konnten E-Mails zwischen Großkonzernen abfangen, indem sie eine grundlegende Schwäche in der Aushandlung der Verschlüsselung zwischen Mailservern ausnutzten. Der Angriff war elegant in seiner Einfachheit. Wenn zwei Mailserver sich verbinden, versuchen sie, per STARTTLS auf eine verschlüsselte Verbindung aufzurüsten. Sitzt jedoch ein Angreifer dazwischen, kann er das Verschlüsselungsangebot einfach entfernen und beide Server zwingen, im Klartext zu kommunizieren.
Die Server beschweren sich nicht. Sie schlagen keinen Alarm. Sie zucken nur mit den Schultern und senden Ihre vertraulichen Verträge, Krankenakten und Kontoauszüge im Klartext durchs Internet, lesbar für jeden, der mithört.
MTA-STS—Mail Transfer Agent Strict Transport Security—existiert, um genau dieses Szenario zu verhindern.
Das STARTTLS-Problem
Um zu verstehen, warum MTA-STS wichtig ist, müssen Sie wissen, wie E-Mail-Verschlüsselung typischerweise funktioniert – und warum sie überraschend fragil ist.
Wenn Ihr Mailserver eine E-Mail an eine andere Domain zustellen will, verbindet er sich mit dem Mailserver des Empfängers auf Port 25. Diese initiale Verbindung ist unverschlüsselt. Die Server verhandeln dann: "Hey, unterstützt du Verschlüsselung?" Wenn beide Seiten zustimmen, rüsten sie auf TLS auf und fahren sicher fort.
Das nennt man opportunistische Verschlüsselung, und sie hat einen fatalen Schwachpunkt. Die Aushandlung findet über einen unverschlüsselten Kanal statt. Ein Angreifer, der einen Man-in-the-Middle-Angriff durchführt, kann die Nachricht "Ich unterstütze TLS" abfangen und durch "Ich unterstütze TLS nicht" ersetzen. Beide Server glauben, der andere könne keine Verschlüsselung, also kommunizieren sie im Klartext weiter.
Das ist nicht theoretisch. Sicherheitsforscher haben dokumentiert, dass ISPs und Staaten solche Downgrade-Angriffe aktiv durchführen. In manchen Ländern ist das Routine. Ihre E-Mail ist möglicherweise verschlüsselt, wenn sie Ihren Server verlässt, und verschlüsselt, wenn sie am Ziel ankommt – aber irgendwo unterwegs hat jemand jedes Wort mitgelesen.
Wie MTA-STS das behebt
MTA-STS wählt einen einfachen Ansatz: Domaininhaber können eine Richtlinie veröffentlichen, die sagt: "Beim Zustellen von Mail an uns ist TLS stets erforderlich, und hier sind genau die Server, mit denen ihr euch verbinden sollt."
Die Richtlinie wird an zwei Stellen veröffentlicht. Erstens kündigt ein DNS-Eintrag an, dass die Domain MTA-STS verwendet. Zweitens legt eine über HTTPS gehostete Richtliniendatei die exakten Anforderungen fest. Der HTTPS-Teil ist entscheidend – er bedeutet, dass die Richtlinie selbst über einen verschlüsselten, authentifizierten Kanal geliefert wird, der nicht manipuliert werden kann.
Wenn ein sendender Mailserver an eine MTA-STS-aktivierte Domain zustellen möchte, prüft er zuerst den DNS-Eintrag. Wenn vorhanden, ruft er die Richtliniendatei über HTTPS ab. Die Richtlinie teilt ihm mit: TLS-Version 1.2 oder höher verlangen, das Zertifikat gegen diese Muster prüfen und nur Verbindungen zu diesen spezifischen Mailservern zulassen.
Wenn eine dieser Anforderungen nicht erfüllt werden kann – wenn die Verbindung nicht verschlüsselt werden kann, das Zertifikat ungültig ist oder der Servername nicht passt – verweigert der sendende Server die Zustellung. Er fällt nicht auf Klartext zurück. Er bricht mit einem Fehler ab.
MTA-STS einrichten
Die Implementierung von MTA-STS erfordert drei Komponenten: einen DNS-Eintrag, eine Richtliniendatei und einen Webserver, der diese Richtlinie hostet.
Der DNS-Eintrag ist ein TXT-Record unter _mta-sts.yourdomain.com. Er sieht so aus: "v=STSv1; id=20240115". Das Feld 'id' ist ein Versionskennzeichen – Sie ändern es, wenn Sie Ihre Richtlinie aktualisieren, wodurch sendende Server angewiesen werden, die neue Version abzurufen.
Die Richtliniendatei liegt unter https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Beachten Sie die Subdomain – Sie benötigen ein gültiges HTTPS-Zertifikat für mta-sts.yourdomain.com. Die Datei enthält Ihre Richtlinie in einem einfachen Textformat.
Eine typische Richtlinie legt die Version, den Modus (testing oder enforce), die maximale Zeit in Sekunden fest, die Sender die Richtlinie cachen sollen, sowie die MX-Hostnamen, die für Ihre Domain gültig sind. Die max_age ist wichtig – längere Werte bedeuten besseren Schutz vor Angriffen, aber eine langsamere Wiederherstellung, wenn Sie etwas ändern müssen.
Testing vs Enforce-Modus
MTA-STS unterstützt zwei Modi, und der Unterschied ist enorm wichtig.
Im Testing-Modus rufen sendende Server Ihre Richtlinie ab und werten sie aus, aber sie setzen sie nicht tatsächlich durch. Wenn eine Verbindung die Richtlinie nicht erfüllen würde, wird die E-Mail trotzdem zugestellt – aber Sie erhalten einen Bericht darüber. So können Sie Probleme identifizieren, bevor sie zu Zustellfehlern führen.
Im Enforce-Modus ist die Richtlinie obligatorisch. Verbindungen, die die Anforderungen nicht erfüllen, schlagen fehl, und die E-Mail wird nicht zugestellt. Das ist echter Schutz, aber auch echtes Risiko, wenn Ihre Richtlinie fehlerhaft ist.
Der kluge Ansatz ist, im Testing-Modus mit einer kurzen max_age zu starten. Überwachen Sie die Berichte ein paar Wochen lang. Achten Sie auf legitime Mailserver, die Ihre Anforderungen nicht erfüllen können – vielleicht ein altes Partnersystem mit veralteter TLS-Implementierung oder ein falsch konfigurierter Backup-MX. Beheben Sie diese Probleme und wechseln Sie dann in den Enforce-Modus mit einer längeren max_age.
Die Berichtsebene: TLSRPT
MTA-STS arbeitet Hand in Hand mit TLSRPT – TLS Reporting. Dies ist ein separater DNS-Eintrag, der sendenden Servern mitteilt, wohin sie Berichte über TLS-Verbindungsversuche senden sollen.
Die Berichte umfassen Erfolge und Fehler: welche Server verbunden haben, welche TLS-Version sie genutzt haben, ob die Zertifikatsprüfung bestanden wurde und – falls etwas fehlschlug – warum. Diese Sichtbarkeit ist unbezahlbar. Ohne sie fliegen Sie blind – Sie wissen nicht, ob Angreifer Downgrades versuchen oder ob legitime Absender Probleme haben.
Die Einrichtung von TLSRPT ist einfach: Fügen Sie einen TXT-Record unter _smtp._tls.yourdomain.com hinzu, der angibt, wohin Berichte gesendet werden. Sie können sie per E-Mail oder HTTPS-POST empfangen. Mehrere Dienste aggregieren und visualisieren diese Berichte für Sie, was es wesentlich einfacher macht, Muster zu erkennen.
Häufige Implementierungsfehler
Der häufigste MTA-STS-Fehler betrifft Zertifikate. Ihre mta-sts-Subdomain benötigt ein gültiges Zertifikat, und Ihre Mailserver benötigen gültige Zertifikate mit Hostnamen, die zu Ihrer Richtlinie passen. Let's Encrypt macht das leicht, aber Sie müssen daran denken, die mta-sts-Subdomain in Ihren Zertifikatserneuerungsprozess einzubeziehen.
Ein weiteres häufiges Problem sind Abweichungen zwischen MX-Einträgen. Ihre MTA-STS-Richtlinie listet spezifische Hostnamen auf, und Ihre MX-Einträge müssen genau dazu passen. Wenn Ihr MX auf mail.example.com zeigt, Ihre Richtlinie aber mx1.example.com aufführt, schlagen Verbindungen im Enforce-Modus fehl.
Auch das Vergessen, die Richtlinien-ID zu aktualisieren, stolpert viele aus. Wenn Sie Ihre Richtliniendatei ändern, müssen Sie auch die ID in Ihrem DNS-Eintrag aktualisieren. Sendende Server cachen Richtlinien basierend auf der ID – wenn Sie sie nicht ändern, rufen sie Ihre Updates nicht ab.
Schließlich ist es riskant, die max_age zu früh zu hoch anzusetzen. Wenn Sie eine Richtlinie mit einer max_age von einem Jahr veröffentlichen und dann ein Problem entdecken, werden sendende Server die fehlerhafte Richtlinie bis zu ein Jahr lang durchsetzen. Beginnen Sie mit Stunden oder Tagen, nicht mit Monaten.
MTA-STS vs. DANE
Vielleicht haben Sie von DANE (DNS-based Authentication of Named Entities) als einer weiteren Lösung für dasselbe Problem gehört. Beide verhindern TLS-Downgrade-Angriffe, aber sie funktionieren unterschiedlich.
DANE verwendet DNSSEC zur Authentifizierung von TLS-Zertifikaten. Es ist arguably eleganter – alles liegt in DNS, kein Webserver nötig. Aber die DNSSEC-Verbreitung ist nach wie vor begrenzt, und viele DNS-Provider unterstützen es nur unzureichend. MTA-STS wurde als leichter deploybare Alternative entwickelt, die mit vorhandener Infrastruktur funktioniert.
In der Praxis hat MTA-STS eine deutlich breitere Verbreitung gesehen. Google, Microsoft und die meisten großen E-Mail-Anbieter unterstützen es. Wenn Sie zwischen beiden wählen, ist MTA-STS die pragmatische Wahl. Wenn Sie sicherheitsfokussiert sind und bereits DNSSEC haben, bieten beide zusammen Defense in Depth (mehrschichtige Verteidigung).
Lohnt sich der Aufwand?
MTA-STS erfordert mehr Einrichtung als ein einfacher DNS-Eintrag. Sie müssen eine Richtliniendatei hosten, Zertifikate pflegen, Berichte überwachen. Lohnt sich das?
Wenn Sie mit sensiblen E-Mails arbeiten – Finanzdienstleistungen, Gesundheitswesen, Rechtswesen oder jedes Geschäft, bei dem das Abfangen von E-Mails katastrophal wäre – ja, unbedingt. Der Angriff, den es verhindert, ist real und wird aktiv ausgenutzt. Der Einrichtungsaufwand sind ein paar Stunden; der Schutz ist dauerhaft.
Für kleinere Organisationen mit weniger sensiblen E-Mails ist es eine Abwägung. Die gute Nachricht ist: Je mehr Domains MTA-STS einführen, desto sicherer wird das Ökosystem für alle. Angreifer können Verbindungen nicht selektiv herabstufen, wenn der Großteil des Internets Downgrades nicht akzeptiert.
Frequently asked questions
Schützt MTA-STS E-Mail-Inhalte Ende-zu-Ende?
Nein. MTA-STS schützt E-Mails auf dem Transportweg zwischen Mailservern, aber die E-Mail wird an jedem Server entschlüsselt. Für echte Ende-zu-Ende-Verschlüsselung benötigen Sie S/MIME oder PGP. MTA-STS und Ende-zu-Ende-Verschlüsselung lösen unterschiedliche Probleme und können zusammen eingesetzt werden.
Was passiert, wenn meine MTA-STS-Richtliniendatei nicht verfügbar ist?
Wenn Absender Ihre Richtlinie nicht über HTTPS abrufen können, fällt die Zustellung auf opportunistische Verschlüsselung zurück – so, als hätten Sie gar kein MTA-STS. Deshalb ist die Zuverlässigkeit des Hostings wichtig. Ziehen Sie ein CDN oder redundantes Hosting für die Richtliniendatei in Betracht.
Unterstützen alle E-Mail-Anbieter MTA-STS?
Die meisten großen Anbieter tun das, darunter Gmail, Outlook, Yahoo und andere. Einige kleinere oder ältere Mailserver jedoch nicht. Prüfen Sie TLSRPT-Berichte, um zu sehen, welche Absender Ihre Richtlinie auswerten.
Kann MTA-STS zu Zustellfehlern bei E-Mails führen?
Im Enforce-Modus ja – das ist der Punkt. Wenn ein sendender Server keine sichere Verbindung herstellen kann, die Ihren Richtlinienanforderungen entspricht, wird die E-Mail nicht zugestellt. Deshalb sind Testing-Modus und Monitoring vor dem Erzwingen essenziell.