MTA-STS einrichten — TLS für eingehende Mails erzwingen

Was du brauchst

Zugriff auf die DNS-Zone, einen Webserver mit gültigem HTTPS-Zertifikat für die Subdomain mta-sts.deinedomain.de und eine vollständige Liste deiner MX-Hosts. Der Webserver muss dauerhaft erreichbar sein — fällt er aus, greifen sendende Server auf ihre gecachte Policy zurück, aber neue Absender können keine abrufen.

Schritt 1 — DNS-Record anlegen

Die id ist eine frei wählbare Kennung, üblicherweise ein Zeitstempel. Sie signalisiert sendenden Servern, ob sich die Policy geändert hat. Bei jeder Änderung an der Policy-Datei muss die id neu gesetzt werden — sonst arbeiten Absender bis zum Ablauf von max_age mit der alten Fassung weiter.

Schritt 2 — Policy-Datei bereitstellen

Die Datei muss exakt unter dieser URL erreichbar sein, mit gültigem Zertifikat für mta-sts.deinedomain.de und dem Content-Type text/plain:

Inhalt:

• Jeder MX-Host bekommt eine eigene mx:-Zeile. Wildcards sind erlaubt: mx: *.deinedomain.de
• max_age in Sekunden — wie lange sendende Server die Policy cachen. 604800 entspricht einer Woche. Beim Einstieg lieber niedriger ansetzen (etwa 86400), damit Korrekturen schneller greifen
• Zeilenenden: Die Datei muss CRLF verwenden. Manche Parser sind streng

Die Subdomain braucht außerdem einen A- oder CNAME-Record, damit der Webserver überhaupt erreichbar ist.

Schritt 3 — TLS-RPT aktivieren

Ohne Reporting stellst du blind scharf. TLS-RPT sorgt dafür, dass sendende Server dir täglich melden, welche Verbindungen erfolgreich verschlüsselt waren und welche nicht:

Die Berichte kommen als komprimiertes JSON. Sie zeigen dir vor der Umstellung auf enforce, ob es Absender gibt, die an deiner Policy scheitern würden.

Schritt 4 — auf enforce umstellen

Nach ein bis zwei Wochen im testing-Modus ohne auffällige Fehlerberichte änderst du die Policy-Datei:

Und anschließend die id im DNS-Record erhöhen. Ohne diesen Schritt bleibt die Änderung wirkungslos.

Häufige Fehler

• Zertifikat der mta-sts-Subdomain abgelaufen: Die gesamte Policy wird ungültig und der Schutz fällt aus. Automatische Erneuerung ist Pflicht.
• id nicht erhöht: Der häufigste Fehler nach einer Policy-Änderung.
• MX-Host vergessen: Im enforce-Modus wird an nicht gelistete MX-Hosts nicht zugestellt. Der Backup-MX ist der übliche Kandidat.
• Weiterleitung statt Auslieferung: Ein Redirect auf eine andere Domain macht die Policy ungültig — die Datei muss direkt unter der mta-sts-Subdomain liegen.
• Zertifikat der MX-Hosts passt nicht: Unter enforce wird auch der Hostname im Zertifikat geprüft. Ein Zertifikat auf den Provider-Namen statt den MX-Namen führt zu abgelehnter Zustellung.

MTA-STS oder DANE?

Beide erzwingen verifizierte TLS-Verbindungen, auf unterschiedlichem Weg. DANE setzt eine DNSSEC-signierte Zone voraus, MTA-STS nicht. Wer DNSSEC betreibt, kann und sollte beides parallel einrichten — unterschiedliche Absender unterstützen unterschiedliche Verfahren.

Testen

Sende eine E-Mail an hello@analyzemy.email. Der Report ruft deine Policy-Datei tatsächlich ab und zeigt Modus, MX-Muster, max_age sowie den TLS-RPT-Record.