MTA-STS und TLS-RPT: was sie tun und ob Sie sie brauchen
MTA-STS ist eine Richtlinie, mit der Sie versendenden Servern mitteilen, dass E-Mails an Ihre Domain nur über eine verschlüsselte und verifizierte TLS-Verbindung zugestellt werden dürfen. TLS-RPT ist der dazugehörige Berichtskanal: Versender schicken Ihnen täglich einen Bericht über Verbindungen, die dieser Richtlinie nicht entsprochen haben. Beide schützen die E-Mails, die Sie empfangen; für die E-Mails, die Sie versenden, brauchen Sie vor allem einen Versandserver, der diese Richtlinien beim Empfänger respektiert.
Das Problem, das sie lösen
E-Mails zwischen Servern laufen seit Jahren größtenteils verschlüsselt, über STARTTLS. Aber STARTTLS ist opportunistisch: Der versendende Server fragt, ob der Empfänger Verschlüsselung unterstützt, und wenn die Antwort ausbleibt oder das Zertifikat nicht stimmt, fällt er stillschweigend auf eine unverschlüsselte Verbindung zurück. Jemand, der zwischen beiden Servern sitzt, kann diese Frage herausfiltern und die E-Mail in lesbarer Form passieren lassen. MTA-STS nimmt diese Rückfalloption weg: Steht Ihre Richtlinie auf „enforce“, darf ein Versender, der die Verschlüsselung nicht zustande bringt, die E-Mail nicht zustellen.
Wie MTA-STS funktioniert
Es besteht aus zwei Teilen, die Sie selbst veröffentlichen:
- Ein DNS-Eintrag auf _mta-sts.ihredomain.be mit einer Version und einer ID. Die ID ändern Sie jedes Mal, wenn Sie die Richtlinie anpassen; Versender wissen so, dass sie sie neu abrufen müssen.
- Eine Richtliniendatei unter https://mta-sts.ihredomain.be/.well-known/mta-sts.txt. Darin stehen der Modus (none, testing oder enforce), die Mailserver, die für Ihre Domain empfangen dürfen, und wie lange ein Versender die Richtlinie merken darf.
Dieser zweite Teil erklärt, warum MTA-STS über HTTPS läuft und nicht nur über DNS: Das Zertifikat dieser Webseite beweist, dass die Richtlinie wirklich von Ihrer Domain stammt, ohne dass DNSSEC nötig ist. Die Alternative, DANE, tut dasselbe über DNS, setzt aber DNSSEC auf Ihrer Domain voraus, was in der Praxis bei vielen belgischen Registraren und Hosting-Paketen nicht standardmäßig aktiv ist.
Wie TLS-RPT funktioniert
TLS-RPT ist ein einzelner DNS-Eintrag auf _smtp._tls.ihredomain.be mit einer Adresse, an der Sie Berichte empfangen wollen. Versender, die es unterstützen (darunter die großen Anbieter), schicken Ihnen dann einmal täglich einen Bericht, der pro versendendem Server angibt, wie viele Verbindungen gelungen und wie viele gescheitert sind, und warum: Zertifikat abgelaufen, Servername stimmt nicht überein, STARTTLS nicht angeboten, Richtlinie nicht abrufbar.
Dieser Bericht ist der Grund, mit TLS-RPT zu beginnen, noch bevor Sie MTA-STS durchsetzen. Er sagt Ihnen, ob es Versender gibt, die Ihre E-Mails bald nicht mehr zustellen können, wenn Sie den Modus auf enforce setzen. Vergleichen Sie es mit DMARC: erst beobachten, dann verschärfen. Wie Sie das lesen, steht in unserem Artikel über DMARC-Berichte; die Logik ist dieselbe.
Brauchen Sie es?
Das hängt davon ab, von welcher Seite der Verbindung Sie es betrachten.
Als Empfänger
Empfängt Ihre Domain sensible E-Mails (Personalakten, medizinische Daten, juristische Korrespondenz, Zahlungsanweisungen), dann ist MTA-STS ein günstiger Schutz gegen das Abfangen von E-Mails unterwegs. Für eine Domain, die vor allem Newsletter und Bestellbestätigungen empfängt, ist der Gewinn kleiner, aber es kostet wenig: ein DNS-Eintrag, eine kleine statische Datei auf einer Subdomain mit gültigem Zertifikat und ein Postfach für die Berichte.
Als Versender
MTA-STS auf Ihrer eigenen Domain ändert nichts an den E-Mails, die Sie versenden. Was zählt: Der Server, mit dem Sie versenden, muss die MTA-STS-Richtlinie des Empfängers prüfen und respektieren und selbst ein korrektes TLS-Zertifikat haben. Versenden Sie über ein SMTP-Relay, ist das die Verantwortung des Relays. Fragen Sie nach, wenn Sie es nicht sicher wissen: Ein Versender, der die Richtlinie ignoriert, wird bei einem Empfänger im Enforce-Modus abgewiesen, und das sehen Sie dann als Bounce.
Ein praktischer Ablauf
- Setzen Sie den TLS-RPT-Eintrag und lassen Sie die Berichte einige Wochen an einer Adresse eintreffen, die tatsächlich jemand liest.
- Veröffentlichen Sie die MTA-STS-Richtlinie im Modus testing. Versender melden dann Abweichungen in den Berichten, stellen aber weiterhin zu.
- Beheben Sie, was Sie in den Berichten sehen: meist ein Mailserver, der nicht in der Richtlinie stand, oder ein Zertifikat, das auf einen anderen Namen lautet.
- Setzen Sie den Modus auf enforce und erhöhen Sie die ID im DNS-Eintrag.
- Sehen Sie monatlich in die Berichte und prüfen Sie bei jeder Änderung Ihrer Mailserver, ob die Richtliniendatei noch stimmt.
Wer eine gehostete Mail-Plattform nutzt, findet die Servernamen für die Richtlinie bei den MX-Einstellungen dieser Plattform. Wer eigene Mailserver betreibt, muss das Zertifikat dieser Server überwachen: Ein abgelaufenes Zertifikat bedeutet im Enforce-Modus, dass externe E-Mails nicht mehr ankommen.
Was es nicht tut
MTA-STS sagt nichts darüber, wer E-Mails in Ihrem Namen versenden darf; dafür bleiben SPF, DKIM und DMARC nötig. Es schützt auch nicht den Weg vom empfangenden Server zum Postfach des Lesers, und es verschlüsselt den Inhalt nicht auf dem Server selbst. Es schließt eine einzelne, spezifische Lücke: den unverschlüsselten Rückfall zwischen zwei Mailservern.
Häufig gestellte Fragen
Ist MTA-STS Pflicht?
Nein. Es ist eine Empfehlung, die die großen Anbieter unterstützen, keine Voraussetzung für die Zustellung. In manchen Branchen und Ausschreibungen wird es allerdings immer häufiger verlangt.
Kann ich MTA-STS setzen, wenn meine E-Mails bei Microsoft 365 oder Google Workspace liegen?
Ja. Sie veröffentlichen die Richtlinie selbst, mit den MX-Servern dieser Plattform darin. Beide Plattformen haben gültige Zertifikate auf diesen Servern.
Was, wenn ich auf dieser Domain nur versende und nichts empfange?
Dann hat MTA-STS für diese Domain wenig Sinn. Investieren Sie Ihre Zeit dann in Authentifizierung und Zustellbarkeit; daran werden Ihre ausgehenden E-Mails gemessen.