Was ist MTA-STS? TLS für eingehende Mails

Das Problem: E-Mail-Verschlüsselung ist standardmäßig optional

Wenn ein Mailserver eine Nachricht zustellt, versucht er, mit dem Empfängerserver eine verschlüsselte TLS-Verbindung aufzubauen. Diese Verschlüsselung ist allerdings opportunistisch — spricht der Empfänger kein TLS oder ist sein Zertifikat ungültig, fällt der Sender klaglos auf Klartext zurück.

Genau das macht E-Mail anfällig für Downgrade-Angriffe: Ein Angreifer auf dem Netzwerkpfad streicht einfach die TLS-Ankündigung des Empfängers heraus und zwingt die Verbindung damit in den Klartext. Der Sender hat keine Chance zu erkennen, dass eigentlich Verschlüsselung möglich gewesen wäre.

MTA-STS schließt diese Lücke.

Was ist MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security, definiert in RFC 8461) ist ein Standard, mit dem Domain-Inhaber erklären können, dass ihre eingehenden Mailserver zwingend TLS verlangen. Ist die Policy einmal veröffentlicht, wissen Sendeserver: Eine unverschlüsselte Zustellung ist tabu — selbst wenn ein Angreifer dazwischenfunkt.

Man kann sich MTA-STS gut als das HSTS der E-Mail-Welt vorstellen.

Wie funktioniert es?

MTA-STS hat zwei Komponenten:

1. DNS-TXT-Record

Mit einem TXT-Record unter _mta-sts.deinedomain.de signalisierst du, dass deine Domain MTA-STS spricht:

_mta-sts.deinedomain.de  TXT  "v=STSv1; id=20260220"

Das id-Feld ist eine Versionskennung. Jedes Mal, wenn du die Policy änderst, musst du auch die id hochzählen — sonst merken Sendeserver nicht, dass sie die Policy-Datei neu laden müssen.

2. Policy-Datei über HTTPS

Unter https://mta-sts.deinedomain.de/.well-known/mta-sts.txt legst du die Policy-Datei ab, die die eigentlichen Regeln festhält:

version: STSv1
mode: enforce
mx: mail.deinedomain.de
mx: *.deinedomain.de
max_age: 604800

Die wichtigsten Felder sind:

mode — enforce (unverschlüsselte Zustellung ablehnen), testing (zulassen, aber Fehler melden) oder none (deaktivieren)
mx — welche Mailserver autorisiert sind (Wildcards möglich)
max_age — wie lange Sendeserver die Policy cachen sollen (in Sekunden)

MTA-STS Policy-Modi
Modus	Verhalten	Einsatzzweck
testing	Normal zustellen, aber TLS-Fehler melden	Ersteinrichtung und Validierung
enforce	Zustellung ablehnen, wenn kein TLS möglich	Produktivbetrieb nach erfolgreichen Tests
none	MTA-STS-Policy deaktivieren	Außerbetriebnahme oder Fehlersuche

Schritt-für-Schritt-Einrichtung

Schritt 1: TLS auf den Mailservern prüfen

Bevor du MTA-STS scharf schaltest, müssen alle MX-Hosts ein gültiges TLS-Zertifikat haben. Test:

openssl s_client -connect mail.deinedomain.de:25 -starttls smtp

Das Zertifikat muss gültig sein, darf nicht abgelaufen sein und muss zum MX-Hostnamen passen.

Schritt 2: Policy-Datei anlegen

Lege eine Textdatei mit deiner Policy an. Starte mit mode: testing, um Probleme zu sehen, bevor du sie tatsächlich erzwingst:

version: STSv1
mode: testing
mx: mail.deinedomain.de
max_age: 86400

Schritt 3: Policy-Datei hosten

Die Datei muss exakt unter dieser URL erreichbar sein:

https://mta-sts.deinedomain.de/.well-known/mta-sts.txt

Dafür brauchst du:

ein gültiges TLS-Zertifikat für mta-sts.deinedomain.de
einen A/AAAA-Record, der mta-sts.deinedomain.de auf deinen Webserver zeigt
die Auslieferung mit Content-Type: text/plain

Schritt 4: DNS-Record veröffentlichen

Im DNS deiner Domain einen TXT-Record anlegen:

_mta-sts.deinedomain.de  TXT  "v=STSv1; id=20260220001"

Als id reicht ein beliebiger eindeutiger Wert — ein Zeitstempel hat sich bewährt.

Schritt 5: Beobachten und auf Enforce wechseln

Mit TLS-RPT (siehe unten) bekommst du Berichte über TLS-Fehler. Sobald sicher ist, dass alle legitimen Absender per TLS zu dir durchkommen, schaltest du den Policy-Modus von testing auf enforce.

MTA-STS und TLS-RPT: ein Gespann

MTA-STS sagt dem Absender: „Du musst TLS verwenden.” TLS-RPT (RFC 8460) ergänzt: „Und falls die TLS-Aushandlung schiefgeht, melde es mir.” Zusammen geben sie dir Einblick in Verschlüsselungsprobleme:

_smtp._tls.deinedomain.de  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Ohne TLS-RPT bleibt es ein Blindflug — du erfährst schlicht nicht, wenn Absender beim Zustellen an dich an TLS-Fehlern scheitern.

Häufige Fallstricke

Abgelaufene Zertifikate — läuft das TLS-Zertifikat deines MX im Enforce-Modus ab, verweigern Sendeserver die Zustellung. Den Ablauf eng überwachen.
MX-Mismatch — die mx-Einträge in der Policy müssen zu deinen echten MX-Records passen. Beim Provider-Wechsel die Policy-Datei aktualisieren und die DNS-id hochzählen.
Fehlendes HTTPS — die Policy-Datei muss per HTTPS mit gültigem Zertifikat erreichbar sein. Selbstsignierte Zertifikate fallen durch.
Caching — Sendeserver cachen deine Policy max_age Sekunden lang. Wenn du kurzfristig etwas drehen musst, halte max_age während des Rollouts klein.

Wer sollte MTA-STS nutzen?

MTA-STS lohnt sich für jede Domain, die E-Mails empfängt und auf Transportverschlüsselung Wert legt. Besonders relevant ist es für:

Organisationen mit sensiblen Daten (Gesundheitswesen, Finanzen, Recht)
Domains, die DMARC bereits im Enforce-Modus betreiben
Unternehmen mit Compliance-Pflichten (DSGVO, HIPAA)

Fazit

MTA-STS schließt eine wichtige Lücke in der E-Mail-Sicherheit: eingehende Verbindungen sind zuverlässig verschlüsselt. Zusammen mit TLS-RPT bekommst du als Domain-Inhaber endlich Sichtbarkeit darüber, wie deine E-Mails tatsächlich zugestellt werden.

Für die Einrichtung reichen ein DNS-Record und eine gehostete Policy-Datei — der Mailserver selbst muss nicht angefasst werden. Beginne im testing-Modus, schau dir die Berichte an, und wechsle auf enforce, wenn alles sauber läuft.

DMARCPulse nimmt dir die Komplexität von MTA-STS und TLS-RPT ab: kopierfertige DNS-Records und Policy-Vorlagen, die du direkt ins DNS-Panel und in die Webserver-Konfiguration einsetzt. Spricht dein DNS-Provider Domain Connect, legt DMARCPulse die nötigen Records mit einem Klick an — ganz ohne manuelles Editieren. Auch danach bleibt DMARCPulse dran: Es überwacht deine MTA-STS-Konfiguration laufend und schickt eine E-Mail, sobald etwas hakt — ein abgelaufenes Zertifikat, ein MX-Mismatch oder eine unerreichbare Policy-Datei, die den Mail-Empfang gefährden würde. Und es sagt dir, wenn der nächste Schritt ansteht, etwa der Wechsel von testing auf enforce. Jetzt loslegen.

Zusammenfassung

MTA-STS erzwingt TLS für eingehende Mail-Zustellung
Bestandteile: ein DNS-TXT-Record plus eine per HTTPS gehostete Policy-Datei
Erst im testing-Modus laufen lassen, dann auf enforce umstellen
Mit TLS-RPT kombinieren, um Zustellfehler überhaupt zu sehen
DMARCPulse erzeugt die Policy-Datei und den DNS-Record für dich