Was ist MTA-STS?

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

Wenn ein Mailserver eine E-Mail versendet, versucht er eine verschlüsselte TLS-Verbindung mit dem Empfängerserver aufzubauen. Aber diese Verschlüsselung ist opportunistisch — wenn der Empfängerserver kein TLS unterstützt oder das Zertifikat ungültig ist, fällt der Sendeserver einfach auf Klartext zurück.

Das macht E-Mail anfällig für Downgrade-Angriffe: Ein Angreifer auf dem Netzwerkpfad kann die TLS-Ankündigung des Empfängerservers entfernen und die Verbindung erzwingen, unverschlüsselt zu laufen. Der Sendeserver hat keine Möglichkeit zu wissen, dass Verschlüsselung eigentlich verfügbar sein sollte.

MTA-STS löst dieses Problem.

MTA-STS (Mail Transfer Agent Strict Transport Security), definiert in RFC 8461, ermöglicht es Domain-Inhabern zu erklären, dass ihre eingehenden Mailserver TLS-Verschlüsselung erfordern. Es verhindert Downgrade-Angriffe, indem sendende Server angewiesen werden, unverschlüsselte Zustellung abzulehnen — ähnlich wie HSTS für HTTPS funktioniert.

MTA-STS (Mail Transfer Agent Strict Transport Security, definiert in RFC 8461) ist ein Standard, der es Domain-Inhabern ermöglicht zu erklären, dass ihre Mailserver TLS erfordern. Einmal veröffentlicht, wissen Sendeserver, dass sie die Zustellung über eine unverschlüsselte Verbindung verweigern müssen — selbst wenn ein Angreifer versucht einzugreifen.

Man kann es sich wie HSTS (HTTP Strict Transport Security) vorstellen, nur für E-Mail.

Wie funktioniert es?

MTA-STS hat zwei Komponenten:

1. DNS-TXT-Record

Du veröffentlichst einen TXT-Record unter _mta-sts.deinedomain.de, um zu signalisieren, dass deine Domain MTA-STS unterstützt:

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

Das id-Feld ist eine Versionskennung. Jedes Mal, wenn du deine Policy aktualisierst, musst du die id ändern, damit Sendeserver wissen, dass sie die Policy-Datei neu abrufen müssen.

2. Policy-Datei über HTTPS

Du hostest eine Policy-Datei unter https://mta-sts.deinedomain.de/.well-known/mta-sts.txt, die die Regeln festlegt:

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: Prüfe, ob deine Mailserver TLS unterstützen

Bevor du MTA-STS aktivierst, stelle sicher, dass alle deine MX-Hosts gültige TLS-Zertifikate haben. Du kannst das testen mit:

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

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

Schritt 2: Erstelle die Policy-Datei

Erstelle eine Textdatei mit deiner Policy. Beginne mit mode: testing, um Probleme zu erkennen, bevor du erzwingst:

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

Schritt 3: Hoste die Policy-Datei

Die Datei muss unter genau dieser URL erreichbar sein:

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

Das erfordert:

Ein gültiges SSL-Zertifikat für mta-sts.deinedomain.de
Einen A/AAAA-Record, der mta-sts.deinedomain.de auf deinen Webserver zeigt
Die Datei muss mit Content-Type: text/plain ausgeliefert werden

Schritt 4: Veröffentliche den DNS-Record

Füge einen TXT-Record zum DNS deiner Domain hinzu:

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

Wähle einen beliebigen eindeutigen Wert für id — ein Zeitstempel funktioniert gut.

Schritt 5: Überwachen und auf Enforce umschalten

Nutze TLS-RPT (siehe unten), um Berichte über TLS-Fehler zu erhalten. Sobald du sicher bist, dass alle legitimen Absender per TLS verbinden können, ändere den Policy-Modus von testing auf enforce.

MTA-STS und TLS-RPT: Besser zusammen

MTA-STS sagt Absendern, dass sie TLS verwenden müssen. TLS-RPT (RFC 8460) sagt Absendern, dass sie berichten sollen, wenn die TLS-Aushandlung fehlschlägt. Zusammen geben sie dir Einblick in Verschlüsselungsprobleme:

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

Ohne TLS-RPT fliegst du blind — du hast keine Möglichkeit zu wissen, ob Absender TLS-Fehler erleben, wenn sie an deine Domain zustellen.

Häufige Fallstricke

Abgelaufene Zertifikate — Wenn das TLS-Zertifikat deines MX-Servers abläuft, während MTA-STS im Enforce-Modus ist, werden Sendeserver die Zustellung verweigern. Überwache den Zertifikatsablauf genau.
Nicht übereinstimmende MX-Hosts — Die mx-Einträge in deiner Policy müssen mit deinen tatsächlichen MX-Records übereinstimmen. Wenn du den Mail-Provider wechselst, aktualisiere die Policy-Datei und erhöhe die DNS-id.
Fehlendes HTTPS — Die Policy-Datei muss über HTTPS mit einem gültigen Zertifikat bereitgestellt werden. Selbstsignierte Zertifikate funktionieren nicht.
Caching — Sendeserver cachen deine Policy für max_age Sekunden. Wenn du dringend Änderungen vornehmen musst, halte max_age während des Rollouts kurz.

Wer sollte MTA-STS nutzen?

MTA-STS ist wertvoll für jede Domain, die E-Mails empfängt und Verschlüsselung im Transit garantieren möchte. Besonders wichtig ist es für:

Organisationen, die sensible Daten verarbeiten (Gesundheitswesen, Finanzen, Recht)
Domains, die bereits DMARC mit einer erzwingenden Policy nutzen
Unternehmen, die Compliance-Anforderungen unterliegen (DSGVO, HIPAA)

Fazit

MTA-STS schließt eine kritische Lücke in der E-Mail-Sicherheit, indem es sicherstellt, dass eingehende E-Mail-Verbindungen immer verschlüsselt sind. Kombiniert mit TLS-RPT für das Monitoring gibt es Domain-Inhabern Kontrolle darüber, wie ihre E-Mails zugestellt werden.

Die Einrichtung erfordert einen DNS-Record und eine gehostete Policy-Datei — keine Änderungen an deiner Mailserver-Konfiguration. Starte im testing-Modus, überwache die Berichte und schalte auf enforce um, wenn du bereit bist.

DMARCPulse nimmt dir die Komplexität der MTA-STS- und TLS-RPT-Einrichtung ab. Es generiert kopierfertige DNS-Records und Policy-Datei-Vorlagen, die du direkt in dein DNS-Panel und deine Webserver-Konfiguration einfügen kannst. Wenn dein DNS-Provider Domain Connect unterstützt, kann DMARCPulse die erforderlichen DNS-Records mit einem Klick für dich anlegen — ohne manuelles Editieren. Über die Ersteinrichtung hinaus überwacht DMARCPulse deine MTA-STS-Konfiguration kontinuierlich und alarmiert Administratoren per E-Mail, wenn etwas nicht stimmt — etwa ein abgelaufenes Zertifikat, ein nicht übereinstimmender MX-Eintrag oder eine nicht erreichbare Policy-Datei, die den Empfang eingehender E-Mails verhindern könnte. Außerdem weist es dich darauf hin, wenn Konfigurationsänderungen anstehen, zum Beispiel wenn es Zeit ist, vom testing- in den enforce-Modus zu wechseln. Starte noch heute.

Zusammenfassung

MTA-STS erzwingt TLS-Verschlüsselung für eingehende E-Mail-Zustellung
Es besteht aus einem DNS-TXT-Record und einer HTTPS-gehosteten Policy-Datei
Starte mit dem testing-Modus, bevor du auf enforce umstellst
Kombiniere MTA-STS mit TLS-RPT für volle Sichtbarkeit bei Zustellfehlern
DMARCPulse generiert die Policy-Datei und den DNS-Record für dich