MTA-STS und TLS-RPT: zwei E-Mail-Sicherheits-Standards, die fast niemand kennt

Wer heute E-Mail aus einer eigenen Domain verschickt, kennt SPF, DKIM und DMARC. Diese drei Standards regeln, wer in Ihrem Namen senden darf und wie Empfänger Fälschungen erkennen. Was die meisten Setups jedoch offen lassen: den Weg zwischen den Mailservern selbst. Genau dort setzen MTA-STS und TLS-RPT an — zwei jüngere Standards, die in vielen deutschen Setups noch fehlen, obwohl die Konfiguration überschaubar ist.

Worum es geht: TLS zwischen Mailservern

Wenn ein Mailserver eine Nachricht zustellt, öffnet er eine SMTP-Verbindung zum empfangenden Server. SMTP startet historisch unverschlüsselt. Per STARTTLS kann die Verbindung auf TLS umgestellt werden — aber eben nur kann. Der Standard ist opportunistisch: Lehnt die Gegenseite STARTTLS ab oder schlägt der Handshake fehl, fällt der sendende Server zurück auf Klartext, statt die Zustellung abzubrechen. Das ist eine bewusste Entscheidung aus der Zeit, als TLS auf Mailservern noch die Ausnahme war. Heute ist es eine Lücke.

Konkret bedeutet das: Ein Angreifer, der sich zwischen zwei Mailservern positioniert — etwa durch BGP-Hijacking, einen kompromittierten Upstream oder schlicht ein offenes Hotelnetz auf der Strecke — kann das STARTTLS-Kommando aus dem SMTP-Dialog entfernen. Die beiden Server kommunizieren dann im Klartext, beide ohne Hinweis darauf, dass etwas eingegriffen hat. Die Mail läuft, der Inhalt liegt offen.

MTA-STS schließt diese Lücke. Es ist eine Policy, die der Empfänger veröffentlicht und die sagt: „Wer mir Mails schicken will, muss TLS verwenden — und zwar mit einem gültigen Zertifikat auf einem dieser MX-Hosts.“ Sendende Server holen diese Policy ab, cachen sie und halten sich daran. TLS-RPT ergänzt das Bild: Es ist der Rückkanal, über den sendende Server tagesaktuell melden, wie viele Zustellungen geklappt haben und welche Probleme aufgetreten sind.

Wie MTA-STS technisch aufgebaut ist

Eine MTA-STS-Konfiguration besteht aus drei Bausteinen. Erstens einem TXT-Record im DNS unter _mta-sts.ihredomain.de mit dem Inhalt v=STSv1; id=20260527T0000;. Die id ist beliebig, ändert sich aber, sobald die Policy aktualisiert wird. Sendende Server lesen daran ab, ob ihre gecachte Version noch aktuell ist. Zweitens einer Subdomain mta-sts.ihredomain.de, die per HTTPS erreichbar sein muss; das Zertifikat muss von einer regulären CA stammen, die der sendende Server kennt — Let’s Encrypt reicht. Drittens einer Datei /.well-known/mta-sts.txt auf dieser Subdomain mit dem eigentlichen Inhalt der Policy.

Die Policy-Datei sieht typischerweise so aus: version: STSv1, mode: enforce, eine oder mehrere mx:-Zeilen mit den gültigen MX-Hostnamen, und ein max_age:-Wert in Sekunden — üblich sind sieben Tage (604800). Der mode kann none, testing oder enforce sein. In testing melden Sender Verstöße nur via TLS-RPT, stellen die Mail aber trotzdem zu. In enforce wird zugestellt nur dann, wenn die Policy eingehalten wird — ansonsten landet die Nachricht im Bounce. Realistisch betreibt man eine neue Policy zwei bis vier Wochen in testing, beobachtet die Reports und schaltet erst dann scharf.

Das Feld max_age ist die Cache-Lebensdauer. Die Konsequenz: Wenn Sie Ihre Policy ändern, sehen sendende Server die Änderung erst nach Ablauf des Caches — oder wenn sich der id-Wert im TXT-Record geändert hat. Wer regelmäßig MX-Hosts wechselt, sollte den max_age entsprechend kürzer wählen.

TLS-RPT: der Rückkanal

TLS-RPT (RFC 8460) ist von MTA-STS unabhängig, ergibt aber zusammen mit MTA-STS einen geschlossenen Kreis. Der Standard veröffentlicht im DNS einen TXT-Record unter _smtp._tls.ihredomain.de mit einer Mailadresse oder URL, an die tägliche Reports geschickt werden, in der Form v=TLSRPTv1; rua=mailto:[email protected].

Große Provider — Google, Microsoft, Yahoo — senden dann täglich einen JSON-Report im Anhang. Darin steht, wie viele Zustellungen erfolgreich waren, welche an einem Policy-Verstoß gescheitert sind, welche an einem Zertifikatsfehler. Die Reports sind unscheinbar, aber sie sind das einzige Werkzeug, mit dem Sie sehen, ob Ihre eigene Policy in der Praxis funktioniert — oder ob etwa ein MX-Host falsch konfiguriert ist und Mails systematisch im Bounce landen. Wer keine eigene Auswertung aufsetzen will, kann sich an Aggregations-Dienste wie Postmark, dmarcian oder URIports halten, die TLS-RPT-Reports entgegennehmen und in einem Dashboard aufbereiten. Für den Einstieg reicht eine eigene Mailbox — die Reports sind klein genug, dass man sie zwei Wochen lang mit dem Auge durchgehen kann.

Warum das nicht von alleine passiert

SPF, DKIM und DMARC wurden in den letzten Jahren stark beworben — nicht zuletzt, weil Google und Yahoo Anfang 2024 angefangen haben, Massenversender ohne DMARC-Policy abzulehnen. Bei MTA-STS und TLS-RPT gibt es bislang keinen vergleichbaren Druck. Die Standards sind seit 2018 in der Welt, gefühlt aber kommen sie nur dort an, wo jemand aktiv hinschaut. Das hat zwei Gründe. Zum einen ist die Pflege etwas aufwändiger als ein einzelner DNS-Record: Sie brauchen eine erreichbare HTTPS-Subdomain mit gültigem Zertifikat. Zum anderen ist der Effekt nicht sofort sichtbar — ohne TLS-RPT merkt niemand, ob die Policy etwas bringt. Genau das ist der Grund, warum die zwei Standards immer zusammen gehören.

Konkretes Setup mit Postfix und Caddy

In einer typischen Manufaktur-Konfiguration mit Postfix als Mailserver und Caddy als Webserver sind die Schritte überschaubar. Sie lassen die Subdomain mta-sts.ihredomain.de per A-Record auf den Webserver zeigen. In der Caddyfile bekommt diese Subdomain einen Block, der ausschließlich /.well-known/mta-sts.txt ausliefert — alles andere wird abgewiesen. Die Policy-Datei legen Sie mit den oben beschriebenen Feldern an, zunächst mit mode: testing. Den TXT-Record _mta-sts.ihredomain.de setzen Sie mit einer id, die das Datum enthält. Der TLS-RPT-Record _smtp._tls.ihredomain.de bekommt eine Sammeladresse, idealerweise eine Mailbox, die täglich gelesen wird.

Zwei Wochen später schauen Sie sich die eingegangenen Reports an. Wenn keine Fehler auftauchen, stellen Sie die Policy auf enforce um und setzen eine neue id. Wer einen externen Mailprovider wie Microsoft 365 oder Google Workspace einsetzt, hat oft schon ein MTA-STS-Setup im Hintergrund — der Provider hat es für seine eigene Infrastruktur gemacht. Für die eigene Domain muss man trotzdem aktiv werden, weil die Policy auf den eigenen MX-Hosts basiert.

Was MTA-STS nicht ist

MTA-STS ist kein Ersatz für DANE. DANE (DNS-based Authentication of Named Entities) bindet Mailserver-Zertifikate direkt an DNSSEC-signierte TLSA-Records. Es ist kryptographisch das robustere Verfahren, setzt aber DNSSEC auf der gesamten Strecke voraus — und scheitert in Deutschland regelmäßig daran, dass viele Registrare DNSSEC nicht im Self-Service anbieten oder es bei jedem Nameserver-Wechsel verloren geht. MTA-STS ist der pragmatische Kompromiss: Es kommt mit Web-PKI aus, die jede Mailserver-Installation ohnehin schon nutzt.

MTA-STS schützt auch nicht vor einem Angreifer, der die HTTPS-Subdomain selbst kompromittiert. Wer auf dem Webserver der Domain eingreifen kann, kann die Policy ändern. In der Praxis ist das ein akzeptables Restrisiko, weil ein Angreifer, der so tief im System sitzt, ohnehin andere Wege hat, Mail abzugreifen.

Was wir konkret empfehlen

Wir setzen MTA-STS und TLS-RPT bei eigenen Domains und bei betreuten Kundenprojekten zusammen mit SPF, DKIM und DMARC auf. Die Hygiene ist in zwei Stunden erledigt, und nach den ersten 14 Tagen Reports sieht man sehr genau, ob es in der Mail-Strecke unsichtbare Probleme gab — abgelaufene Zertifikate auf einzelnen Backup-MX-Hosts sind ein Klassiker, der ohne TLS-RPT monatelang unbemerkt bleibt.

Wenn Sie ohnehin gerade Ihre Mail-Authentifizierung prüfen oder neu aufsetzen, ist der richtige Zeitpunkt, die zwei Standards mitzunehmen. Später nachzuziehen ist immer mit einem kleinen Risiko verbunden, weil die enforce-Phase ohne sauberen Vorlauf zu Bounces führen kann.

Quellen: RFC 8461 (SMTP MTA Strict Transport Security), RFC 8460 (SMTP TLS Reporting), RFC 7672 (DANE), Google Postmaster Tools (Sender Guidelines, Stand 2024), BSI TR-03108 (Sicherer E-Mail-Transport).