Wie richte ich MTA-STS und TLS-RPT für meine Domain ein?

Was schützt MTA-STS?

MTA-STS erlaubt es einer Mail-Domain, zu erklären, dass sie TLS unterstützt und dass Absender die Zustellung an jeden ihrer MX-Hosts verweigern müssen, der kein gültiges Zertifikat vorweisen kann. Definiert wird es in RFC 8461, einem Proposed Standard vom September 2018. Ohne MTA-STS ist die Verschlüsselung zwischen Servern opportunistisch: Ein Absender versucht STARTTLS und sendet die Nachricht im Klartext, wenn ein Angreifer es entfernt.

Bei einer Policy im Modus enforce ruft ein Absender, der MTA-STS unterstützt, Ihre Policy ab, prüft, ob der MX-Host in der mx-Liste steht, und verlangt eine gültige TLS-Verbindung mit passendem Zertifikat. Schlägt eine Prüfung fehl, wartet die Nachricht und wird nicht über einen schwächeren Kanal zugestellt. Es schützt nur eingehende E-Mails und funktioniert nur bei Absendern, die es implementieren. Es authentifiziert keine Nachrichten: Das ist die Aufgabe der Records in SPF vs. DKIM vs. DMARC.

Was steht in der Policy-Datei?

Die Policy-Datei ist eine reine Textdatei aus Zeilen im Format Schlüssel: Wert mit Version, Modus, den erlaubten MX-Mustern und einer Gültigkeitsdauer in Sekunden. RFC 8461 definiert diese Felder. version muss STSv1 sein. mode ist enforce (Absender dürfen nicht an Hosts zustellen, welche die Prüfungen nicht bestehen), testing (die Zustellung darf erfolgen, und Absender, die TLS-RPT unterstützen, senden Fehlerberichte) oder none (als gäbe es keine Policy). Jede mx-Zeile nennt einen Host vollständig, zum Beispiel mail.protonmail.ch, oder verwendet einen Platzhalter im ganz linken Label, etwa *.example.net. max_age ist eine Anzahl von Sekunden, höchstens 31,557,600, und laut RFC sollte der Wert typischerweise Wochen oder mehr betragen. Das Beispiel dort verwendet 604800, eine Woche.

Die Datei muss über HTTPS unter mta-sts.yourdomain mit einem für diesen Namen gültigen Zertifikat bereitgestellt werden. Nur eine HTTP-200-Antwort zählt, und Weiterleitungen dürfen nicht befolgt werden; damit scheidet URL-Weiterleitung aus, ein Dienst, der mit einer Weiterleitung antwortet. Die Datei sollte als text/plain ausgeliefert werden. Verwenden Sie einen kleinen Webhost oder einen Static-Page-Host unter Ihrer Kontrolle. Die mx-Zeilen müssen zu den Records Ihres Anbieters passen, wie sie in was ein MX-Record ist aufgeführt sind.

Was sind die id und die Reihenfolge der Aktualisierung?

Die id im TXT-Record ist ein Label aus 1 bis 32 Buchstaben und Ziffern, das sich bei jeder Änderung der Policy ändern muss, damit Absender wissen, dass sie die Datei neu abrufen sollen. Laut RFC 8461 kennzeichnet sie eine Instanz einer Policy, und zwischen ids gibt es keine Ordnung, sodass ein Zeitstempel mit Datum und Uhrzeit gut funktioniert.

Aktualisieren Sie in dieser Reihenfolge: Veröffentlichen Sie zuerst die neue Policy-Datei und ändern Sie dann die id. Ein Absender, der die neue id vor der neuen Datei sieht, würde die alte Policy erneut zwischenspeichern. Wenn Sie den E-Mail-Anbieter wechseln, ändern sich auch die MX-Hosts: Bearbeiten Sie die mx-Zeilen, bevor Sie die MX-Records ändern, lassen Sie die alten Hosts während des Umzugs in der Liste und erhöhen Sie die id. Eine vergessene mx-Zeile im Modus enforce verhindert, dass E-Mails ankommen; die Umzugsanleitung wie Sie E-Mails zu einem neuen Anbieter umziehen nennt die sichere Reihenfolge für den Rest.

Was ist TLS-RPT und was enthalten die Berichte?

TLS-RPT ist ein Berichtsformat nach RFC 8460, mit dem sendende Server Ihnen täglich mitteilen, wie viele TLS-Verbindungen zu Ihrer Domain erfolgreich waren oder fehlgeschlagen sind. Sie veröffentlichen einen TXT-Record bei _smtp._tls.yourdomain mit v=TLSRPTv1 und einem rua-Feld mit einer mailto:- oder https:-Adresse. Berichte per mailto müssen eine gültige DKIM-Signatur der berichtenden Domain tragen.

Jeder Bericht ist ein JSON-Dokument für einen UTC-Tag. Er nennt die angewendete Policy (MTA-STS, DANE oder keine), zählt erfolgreiche und fehlgeschlagene Sitzungen und gibt den Fehlertyp an, etwa certificate-expired oder starttls-not-supported, mit den IP-Adressen von Sender und Empfänger. So erfahren Sie, dass ein Zertifikat abgelaufen ist oder dass eine mx-Zeile einen Tippfehler hat, bevor Sie auf enforce umstellen. Betrachten Sie die ersten Wochen als Probelauf, wie er auch für DMARC empfohlen wird.

Brauche ich MTA-STS für eine private E-Mail-Domain?

Nein: MTA-STS ist eine optionale Härtung, und die Regeln der großen Anbieter verlangen es nicht. Google, Yahoo und Microsoft verlangen von Massenversendern SPF, DKIM und DMARC und nennen MTA-STS nicht. Für eine private Domain bei Proton Mail, Fastmail oder Mailbox.org lohnt sich die Einrichtung nur, wenn Sie den Aufwand für einen Webhost und ein Zertifikat in Kauf nehmen.

Die Anbieter unterscheiden sich. Laut der Auswertung von Postelva vom 12 November 2026 zu den DNS-Einrichtungslisten von 4 Anbietern (Proton Mail, Tuta, Mailbox.org und Fastmail) führt 1 Anbieter einen MTA-STS-Record in seiner eigenen Einrichtung auf (Tuta, ein CNAME), und die für die anderen drei gelesenen Hilfeseiten dokumentieren keinen. Die gesamte Einrichtung besteht aus 3 DNS-Records und 1 Datei. Prüfen Sie jeden davon mit den Befehlen in wie Sie MX-, SPF-, DKIM- und DMARC-Records prüfen: dig TXT _mta-sts.example.com +short und dig TXT _smtp._tls.example.com +short.

Eine zitierfähige Definition: MTA-STS ist die Policy, die TLS verpflichtend macht, wenn andere Server E-Mails an Ihre Domain zustellen, und TLS-RPT ist der tägliche Bericht, der Ihnen meldet, wenn das fehlschlägt.