MTA-STS und TLS-RPT: E-Mails auf dem Transportweg verschlüsseln

SPF, DKIM und DMARC belegen, wer eine Nachricht gesendet hat. MTA-STS und TLS-RPT schützen die Nachricht, während sie unterwegs ist — sie stellen sicher, dass die Verbindung, die Ihre Mail überträgt, wirklich verschlüsselt ist, und melden Ihnen, wenn das nicht der Fall ist. MTA-STS (SMTP MTA Strict Transport Security, definiert in RFC 8461) erlaubt es einer Domain zu erklären, dass für ihre Server bestimmte Mail über TLS mit einem gültigen Zertifikat eintreffen muss. TLS-RPT (SMTP TLS Reporting, RFC 8460) bittet die sendenden Server, täglich einen Bericht darüber einzureichen, ob diese Verschlüsselung gelungen oder gescheitert ist. Keines von beiden authentifiziert Inhalte — zusammen schließen sie eine andere Lücke, jene, die reines opportunistisches TLS weit offen lässt. Hier erfahren Sie, was jedes leistet und wie Sie beide ausrollen, ohne Ihre eingehende Mail zu stören.

Die kurze Antwort#

MTA-STS ist eine Policy, die Sie veröffentlichen, damit die Mailserver anderer Leute die Mail verschlüsseln, die sie an Sie senden. Sie hat zwei bewegliche Teile: einen DNS-TXT-Eintrag unter _mta-sts.yourdomain.com, der signalisiert, dass die Policy existiert, und eine über HTTPS gehostete Policy-Datei unter https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, die Ihre MX-Hostnamen, einen Modus (none, testing oder enforce) und die Zwischenspeicherdauer auflistet. TLS-RPT ist ein zweiter TXT-Eintrag unter _smtp._tls.yourdomain.com, der eine Adresse für den Empfang täglicher Berichte über den Verlauf dieser TLS-Verbindungen benennt. Der sichere Rollout entspricht dem von DMARC: veröffentlichen Sie zuerst im Modus testing, lesen Sie die TLS-RPT-Berichte, bis Sie sicher sind, dass jede Verbindung sauber TLS aushandelt, und wechseln Sie dann zu enforce.

Die Lücke, die MTA-STS schließt#

Modernes SMTP verschlüsselt bereits den Großteil der Mail auf dem Transportweg mittels STARTTLS — der sendende Server fragt „Unterstützt ihr TLS?“, der Empfänger sagt Ja, und die beiden handeln einen verschlüsselten Kanal aus. Das Problem ist, dass dieser Handshake opportunistisch und nicht authentifiziert ist. Wenn eine der beiden Seiten kein TLS anbietet, fällt die Mail auf Klartext zurück, statt zu scheitern. Schlimmer noch: Ein Angreifer, der zwischen den beiden Servern sitzt, kann das STARTTLS-Angebot aus der Kommunikation entfernen — ein Downgrade-Angriff — und der sendende Server, der kein TLS-Angebot sieht, stellt die Nachricht klammheimlich im Klartext zu. Das Zertifikat wird ebenfalls nicht geprüft, sodass ein Man-in-the-Middle sein eigenes vorlegen und die Verbindung abfangen kann.

MTA-STS behebt beide Schwächen. Indem Sie eine Policy veröffentlichen, teilen Sie regelkonformen Sendern mit: Mail für diese Domain muss über TLS laufen, der empfangende Server muss ein Zertifikat vorlegen, das gültig ist und zu einem meiner aufgeführten MX-Hostnamen passt, und wenn diese Bedingungen nicht erfüllt sind, nicht zustellen — zurückstellen und erneut versuchen, statt auf Klartext zurückzufallen. Weil die Policy über HTTPS abgerufen wird, wirkt ihr eigenes Zertifikat als Vertrauensanker, und genau das verhindert, dass ein Angreifer sie fälscht oder entfernt. Das Ergebnis: Ein passiver Lauscher oder ein aktiver Downgrade-Angreifer kann Ihre eingehende Mail nicht länger in den Klartext zwingen.

Was TLS-RPT ergänzt#

MTA-STS allein ist Durchsetzung ohne Sichtbarkeit — Sie würden Sendern sagen, unsichere Verbindungen abzulehnen, hätten aber keine Möglichkeit zu sehen, wie oft das tatsächlich vorkommt oder welche Sender scheitern. TLS-RPT ist der Rückkanal. Es funktioniert genau wie das Aggregat-Reporting von DMARC und ergänzt auf natürliche Weise die Gewohnheit, DMARC-Berichte zu lesen.

Wenn Sie einen TLS-RPT-Eintrag veröffentlichen, senden Ihnen teilnehmende Sender einen täglichen JSON-Bericht, der jede TLS-Sitzung zusammenfasst, die sie zu Ihren MX-Hosts geöffnet haben: wie viele erfolgreich waren, wie viele scheiterten und — entscheidend — warum sie scheiterten. Ein Bericht könnte ein abgelaufenes Zertifikat auf einem Ihrer MX-Server zeigen, eine Hostnamen-Abweichung, eine unterbrochene STARTTLS-Aushandlung oder ein Problem beim Abruf der Policy. Genau diese Informationen brauchen Sie, bevor Sie es wagen, MTA-STS auf enforce zu stellen, denn ein Fehler im Modus enforce bedeutet zurückgestellte oder abgewiesene eingehende Mail. TLS-RPT ist das, was den Rollout sicher macht statt zu einem Sprung ins Ungewisse.

MTA-STS einrichten: der DNS-Eintrag und die Policy-Datei#

MTA-STS benötigt drei Dinge: einen DNS-Eintrag, eine Policy-Datei und eine Subdomain, um die Datei über HTTPS zu hosten.

1. Der DNS-TXT-Eintrag. Veröffentlichen Sie einen TXT-Eintrag unter _mta-sts.yourdomain.com. Seine Aufgabe ist gering — er kündigt an, dass eine Policy existiert, und trägt eine id, anhand derer Sender bemerken, wenn sich die Policy ändert.

_mta-sts.example.com.  TXT  "v=STSv1; id=20260725090000"

Die id ist eine beliebige Zeichenfolge von bis zu 32 alphanumerischen Zeichen. Ein Zeitstempel ist die übliche Konvention. Die eine Regel, die zählt: Ändern Sie die id, wann immer Sie die Policy-Datei bearbeiten. Sender speichern Ihre Policy zwischen, und eine neue id ist das Signal, das sie zum erneuten Abruf veranlasst. Vergessen Sie, sie hochzuzählen, bleiben Ihre Änderungen unter Umständen so lange unbemerkt wie Ihre max_age.

2. Die Policy-Datei. Hosten Sie eine Klartextdatei unter dem festen Pfad https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Sie listet den Modus, jeden gültigen MX-Hostnamen und eine Zwischenspeicher-Lebensdauer auf:

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

Jede mx-Zeile muss zu einem Hostnamen aus den MX-Einträgen Ihrer Domain passen, und die Wildcard-Form (*.example.com) trifft auf ein einzelnes Label ganz links zu. Jeder von Ihnen aufgeführte MX-Host muss ein Zertifikat ausliefern, das aktuell gültig ist, zu einer öffentlichen CA zurückführt und zu seinem Hostnamen passt — sonst weist ein Sender im Modus enforce ihn zurück. Die max_age ist die Zwischenspeicher-Lebensdauer in Sekunden; RFC 8461 erlaubt Werte bis 31557600 (etwa ein Jahr). Halten Sie sie kurz (einen Tag oder so), während Sie testen, damit sich Änderungen schnell verbreiten, und erhöhen Sie sie dann, sobald Sie mit enforce sicher sind — Empfänger wie Google empfehlen in der Produktion eine lange max_age, wobei der genaue Wert Ihnen überlassen bleibt.

3. Die mta-sts-Subdomain über HTTPS. Die Policy-Datei muss über HTTPS auf der mta-sts-Subdomain mit einem für mta-sts.yourdomain.com gültigen Zertifikat erreichbar sein. In der Praxis richten Sie diese Subdomain (per A/AAAA oder CNAME) auf das, was die Datei ausliefert — ein kleiner statischer Host oder ein CDN ist üblich — und stellen sicher, dass sie mit Content-Type: text/plain antwortet. Viele DNS- und Hosting-Anbieter bieten inzwischen eine verwaltete MTA-STS-Option, die Datei und Zertifikat für Sie übernimmt.

TLS-RPT einrichten#

TLS-RPT ist mit Abstand das einfachere der beiden: ein einziger TXT-Eintrag, keine Policy-Datei.

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

Das rua-Tag benennt, wohin die Berichte gehen. Es akzeptiert eine mailto:-Adresse, einen https:-Endpunkt, der per POST übermittelte Berichte empfängt, oder eine durch Kommas getrennte Liste von beidem. Rohes TLS-RPT-JSON ist dicht, deshalb richten die meisten Teams rua auf einen Monitoring-Dienst, der die Berichte in ein lesbares Dashboard aufbereitet — genauso, wie DMARC-Berichte üblicherweise in einen Parser statt in einen menschlichen Posteingang fließen. Sie können TLS-RPT für sich allein veröffentlichen, und es lohnt sich, das vor MTA-STS zu tun: Es gibt Ihnen ein Bild Ihrer aktuellen TLS-Gesundheit bei null Risiko für den Mailfluss.

MTA-STS und TLS-RPT sicher ausrollen#

Die Reihenfolge der Schritte für MTA-STS und TLS-RPT ist wichtiger als die Einträge selbst — machen Sie es falsch, können Sie Ihre eigene eingehende Mail zurückstellen. Folgen Sie derselben Monitor-vor-Durchsetzung-Disziplin, die einen guten DMARC-Rollout leitet.

1. Veröffentlichen Sie zuerst TLS-RPT. Ohne bereits vorhandene MTA-STS-Policy sagen Ihnen die Berichte schlicht, wie viel Ihrer eingehenden Mail bereits TLS nutzt und ob eines Ihrer MX-Zertifikate falsch konfiguriert ist. Beheben Sie hier alles Offensichtliche.

2. Veröffentlichen Sie MTA-STS im Modus testing. Fügen Sie den DNS-Eintrag und die Policy-Datei mit mode: testing hinzu. In diesem Modus werten Sender Ihre Policy aus und melden Fehler per TLS-RPT, stellen die Mail aber weiterhin normal zu. An Ihrem Mailfluss ändert sich nichts — Sie sammeln nur Daten. Lassen Sie es lange genug hier, um einen vollständigen Zyklus Ihrer regelmäßigen Korrespondenten zu erfassen, idealerweise ein paar Wochen.

3. Lesen Sie die TLS-RPT-Berichte und beheben Sie Fehler. Achten Sie auf Zertifikatsprobleme, Hostnamen-Abweichungen und MX-Hosts, die Sie aufzuführen vergessen haben. Jeder Fehler im Modus testing ist ein Fehler, den Sie im Modus enforce verursacht hätten. Verbessern Sie Ihre Zertifikate und Ihre Policy-Datei so lange, bis die Berichte sauber sind.

4. Wechseln Sie zu mode: enforce. Sobald die Fehler verstummt sind, ändern Sie die Policy-Datei auf enforce und erhöhen Sie die id im DNS-Eintrag, damit Sender sie erneut abrufen. Ab diesem Punkt werden regelkonforme Sender die Zustellung über eine nicht authentifizierte oder herabgestufte Verbindung verweigern. Erwägen Sie jetzt, max_age zu erhöhen, um sich stärker gegen Downgrade-Versuche zu schützen.

Wo dies neben SPF, DKIM und DMARC steht#

Es lohnt sich, genau zu sein, was MTA-STS und TLS-RPT leisten und was nicht, denn man neigt leicht dazu, sie unter „Zustellbarkeit“ einzuordnen und das Falsche zu erwarten.

SPF, DKIM und DMARC beantworten die Frage Stammt diese Nachricht wirklich von dem, von dem sie zu stammen behauptet? — sie authentifizieren Identität und Inhalt. MTA-STS und TLS-RPT beantworten eine andere Frage: War die Verbindung, die diese Nachricht übertrug, tatsächlich verschlüsselt und geprüft? — sie schützen die Vertraulichkeit auf dem Transportweg. Die beiden Ebenen ergänzen einander und sind voneinander unabhängig. Eine Nachricht kann DMARC bestehen und dennoch über Klartext reisen, und sie kann über erzwungenes TLS reisen und dabei an DMARC scheitern. Ein vollständiges Setup will beides.

Zwei ehrliche Vorbehalte. Erstens sind MTA-STS und TLS-RPT nicht Teil der Massenversender-Anforderungen von Google und Yahoo, die 2024 in Kraft traten — diese schreiben SPF, DKIM, DMARC, ein Ein-Klick-Abmelden und eine niedrige Spam-Rate vor, keine Transportsicherheits-Policies. Dennoch veröffentlichen und respektieren die großen Anbieter MTA-STS als Empfänger, sodass eine von Ihnen veröffentlichte Policy von Gmail und anderen tatsächlich durchgesetzt wird, wenn sie an Sie zustellen. Zweitens ist MTA-STS keine Lösung gegen den Spam-Ordner. Es härtet die eingehende Transportsicherheit; es verbessert für sich allein nicht, wo Ihr ausgehendes Marketing landet. Die Platzierung im Posteingang wird nach wie vor von der Absenderreputation, dem Engagement und der Listenhygiene entschieden, und wenn Ihre Mail in den Spam geht, liegen die Gründe in diesen Signalen, nicht in Ihrer TLS-Einrichtung. Behandeln Sie MTA-STS und TLS-RPT als das Transportsicherheits-Kapitel einer ausgereiften Versanddomain — lohnenswert, aber verschieden von den Hebeln im Zustellbarkeits-Leitfaden, die die Platzierung im Posteingang tatsächlich bewegen.

Wenn Sie eine Analogie wollen: MTA-STS ist ein naher Verwandter von DANE, der älteren, DNSSEC-basierten Methode, SMTP-TLS zu erzwingen. Beide zielen auf dasselbe Downgrade-Problem; MTA-STS wurde so entworfen, dass auch Domains ohne DNSSEC den Großteil des Schutzes erhalten können, indem sie stattdessen das Web-Zertifikatssystem nutzen. Wenn Sie bereits DANE betreiben, brauchen Sie MTA-STS vielleicht nicht, aber die beiden können nebeneinander bestehen.

Häufig gestellte Fragen#

Ersetzt MTA-STS SPF, DKIM oder DMARC?#

Nein — sie wirken auf unterschiedlichen Ebenen, und Sie brauchen beide. SPF, DKIM und DMARC authentifizieren Absender und Inhalt einer Nachricht und belegen, dass sie wirklich von Ihrer Domain stammt und nicht verändert wurde. MTA-STS und TLS-RPT sichern den Transport: Sie zwingen die Verbindung, die die Nachricht überträgt, zu geprüftem TLS und melden, wenn das nicht der Fall ist. Eine Nachricht braucht Authentifizierung und verschlüsselte Zustellung, deshalb steht MTA-STS neben DMARC, statt eines davon zu ersetzen.

Sind MTA-STS und TLS-RPT bei Google und Yahoo Pflicht?#

Nicht als Teil der Massenversender-Anforderungen von 2024, die SPF, DKIM, DMARC, ein Ein-Klick-Abmelden und eine Spam-Rate unter 0,3 % vorschreiben — MTA-STS steht nicht auf dieser Liste. Doch die großen Anbieter veröffentlichen selbst MTA-STS-Policies und respektieren Ihre als Empfänger, sodass eine von Ihnen veröffentlichte Policy von Gmail und anderen tatsächlich durchgesetzt wird. Es ist eine empfohlene bewährte Praxis für eine ausgereifte Versanddomain, aber keine formale Hürde für das Erreichen des Posteingangs.

Was ist der Unterschied zwischen MTA-STS und DANE?#

Beide erzwingen TLS für eingehendes SMTP und wehren Downgrade-Angriffe ab; sie unterscheiden sich darin, wie sie Vertrauen herstellen. DANE veröffentlicht Zertifikatsinformationen im DNS und stützt sich auf DNSSEC, um diese Einträge fälschungssicher zu machen. MTA-STS umgeht die DNSSEC-Voraussetzung, indem es seine Policy über HTTPS ausliefert und das gewöhnliche Web-Zertifikatssystem als Vertrauensanker nutzt. MTA-STS lässt sich für Domains ohne DNSSEC in der Regel leichter einführen; beide können auch gemeinsam laufen.

Verbessert MTA-STS meine Zustellung in den Posteingang?#

Nicht direkt. MTA-STS ist eine Transportsicherheits-Kontrolle für Mails, die in Ihre Domain hereinkommen — es ändert nichts daran, wie Ihr ausgehendes Marketing gefiltert wird. Die Platzierung im Posteingang hängt von der Absenderreputation, dem Engagement, den Beschwerderaten und der Listenqualität ab. MTA-STS lohnt sich aus Sicherheits- und Vollständigkeitsgründen, aber wenn Ihre Mails im Spam landen, liegt die Lösung in Ihrer Listenhygiene und Reputation, nicht in Ihrer TLS-Policy.

MTA-STS und TLS-RPT härten die Leitungen, durch die Ihre Mail reist, aber der Posteingang wird über die Listenqualität gewonnen. Der kostenlose E-Mail-Checker fängt tote Domains und Tippfehler ab, bevor sie zu Bounces werden, und der kostenlose Tarif führt die vollständige Verifizierungs-Pipeline über Ihre Liste aus — denn eine sichere, gut authentifizierte Domain verdient sich die Platzierung nur, wenn die Liste dahinter sauber ist.