MTA-STS und TLS-RPT: Verschlüsselte E-Mail-Übertragung erzwingen

SPF, DKIM und DMARC schützen die Authentizität von E-Mails. Aber was schützt die Vertraulichkeit auf dem Transportweg? MTA-STS und TLS-RPT sind zwei ergänzende Standards, die erzwingen, dass E-Mails nur verschlüsselt übertragen werden – und die bei Problemen Reports liefern.

Das Problem: STARTTLS ist opportunistisch

E-Mails werden heute meistens per STARTTLS verschlüsselt übertragen. Aber STARTTLS ist opportunistisch: Wenn der empfangende Server keine Verschlüsselung anbietet oder das Zertifikat ungültig ist, sendet der absendende Mailserver die E-Mail trotzdem – dann unverschlüsselt.

Ein Angreifer, der sich in den Netzwerkpfad dazwischenklingt (Man-in-the-Middle), kann die Verschlüsselungsverhandlung aktiv sabotieren und dafür sorgen, dass E-Mails im Klartext übertragen werden – ohne dass Absender oder Empfänger es merken. Dieser Angriff wird als STARTTLS-Downgrade-Angriff bezeichnet.

Was ist MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) ist ein Standard (RFC 8461), der absendende Mailserver anweist: “Akzeptiere keine unverschlüsselte oder unsichere Verbindung zu meinem Mailserver.”

Wenn ein sendender Server versucht, eine E-Mail an deine Domain zu übermitteln, prüft er vorher die MTA-STS-Policy. Steht dort enforce, wird die E-Mail nur dann zugestellt, wenn:

• Der empfangende Server TLS unterstützt
• Das TLS-Zertifikat gültig ist (ausgestellt von einer vertrauenswürdigen CA)
• Der Hostname des Zertifikats zum MX-Record passt

Scheitert eine dieser Bedingungen, wird die E-Mail nicht zugestellt – statt sie unverschlüsselt zu senden. Das verhindert Downgrade-Angriffe zuverlässig.

Wie funktioniert MTA-STS technisch?

MTA-STS besteht aus zwei Komponenten:

1. Der DNS-Record

Ein TXT-Record unter _mta-sts.deinedomain.de signalisiert, dass MTA-STS aktiv ist:

Die id ist ein beliebiger String (z. B. Timestamp), der sich ändert, wenn die Policy aktualisiert wird. Sendende Server cachen die Policy und nutzen die id, um zu prüfen, ob sie eine neue Version laden müssen.

2. Die Policy-Datei (über HTTPS)

Die eigentliche Policy wird nicht im DNS gespeichert, sondern als Textdatei über HTTPS bereitgestellt. Der absendende Server ruft sie ab unter:

Inhalt der Policy-Datei:

• mode: enforce – Ablehnen, wenn TLS-Bedingungen nicht erfüllt sind. Alternative: testing (nur Reports, keine Ablehnung)
• mx: – Die MX-Hostnamen, die erlaubt sind (müssen mit den MX-Records übereinstimmen)
• max_age: – Cache-Dauer in Sekunden (86400 = 1 Tag, typisch: 604800 = 1 Woche)

Wichtig: Der mta-sts-Subdomain muss ein gültiges TLS-Zertifikat haben. Die meisten Hosting-Anbieter erlauben Subdomains – du musst ggf. eine neue Subdomain anlegen und ein Let's-Encrypt-Zertifikat einrichten.

Was ist TLS-RPT?

TLS-RPT (TLS Reporting, RFC 8460) ist der Reporting-Mechanismus für MTA-STS. Genauso wie DMARC täglich Reports über E-Mail-Authentifizierung sendet, sendet TLS-RPT täglich Reports über TLS-Verbindungsprobleme beim E-Mail-Transport zu deiner Domain.

TLS-RPT wird als TXT-Record unter _smtp._tls.deinedomain.de eingerichtet:

Wenn sendende Server Probleme haben, TLS-gesicherte Verbindungen zu deinem Mailserver aufzubauen, erhalten sie eine tägliche JSON-Zusammenfassung an die angegebene Adresse. Diese Reports helfen dir:

• Abgelaufene oder falsch konfigurierte TLS-Zertifikate frühzeitig zu erkennen
• MTA-STS-Policy-Fehler zu debuggen
• Zu sehen, wenn E-Mails wegen TLS-Problemen nicht zugestellt werden

MTA-STS einrichten: Schritt für Schritt

Wo steht MTA-STS bei großen Anbietern?

Google (Gmail), Microsoft (Outlook/Hotmail) und viele andere große E-Mail-Anbieter haben MTA-STS bereits aktiviert. Wenn du ihnen E-Mails sendest, prüft dein Mailserver bereits ihre MTA-STS-Policy. Durch MTA-STS auf deiner eigenen Domain schützt du E-Mails, die an dich gesendet werden.

MTA-STS vs. DANE: Was ist der Unterschied?

Es gibt eine weitere Technologie für erzwungenes TLS im E-Mail-Transport: DANE (DNS-based Authentication of Named Entities). DANE speichert das erwartete TLS-Zertifikat direkt im DNS (als TLSA-Record) und erfordert DNSSEC. DANE bietet stärkere Garantien als MTA-STS, ist aber technisch deutlich komplexer und bei Hosting-Providern weit weniger verbreitet.

MTA-STS hat den Vorteil, dass es ohne DNSSEC auskommt und von den meisten Cloud-E-Mail-Anbietern (Google, Microsoft) unterstützt wird. Für die meisten Unternehmen ist MTA-STS die praktikablere Wahl.

Häufige Probleme bei der MTA-STS-Einrichtung

Problem 1: mta-sts-Subdomain nicht erreichbar

Die Policy-Datei muss unter https://mta-sts.deinedomain.de/.well-known/mta-sts.txt per HTTPS erreichbar sein. Wenn die Subdomain nicht konfiguriert ist oder kein gültiges TLS-Zertifikat hat, ignorieren sendende Mailserver die Policy-Datei und MTA-STS funktioniert nicht.

Problem 2: MX-Hosts in Policy stimmen nicht überein

Die in der mta-sts.txt aufgelisteten mx:-Einträge müssen exakt mit den MX-Records der Domain übereinstimmen. Wenn du Google Workspace nutzt und in der Policy mx: mail.google.com statt des korrekten Musters mx: *.aspmx.l.google.com angibst, schlägt die Validierung fehl.

Problem 3: DNS-Record id nicht aktualisiert

Wenn du die Policy-Datei aktualisierst (z. B. MX-Hosts änderst oder von testing auf enforce wechselst), muss auch die id im DNS-Record (_mta-sts.deinedomain.de) geändert werden. Ohne eine neue id laden sendende Server die gecachte Policy und bemerken die Änderung nicht.

MTA-STS und das Zusammenspiel mit anderen Standards

MTA-STS ist eine sinnvolle Ergänzung zu SPF, DKIM und DMARC – schützt aber gegen eine andere Angriffskategorie:

• SPF, DKIM und DMARC schützen gegen gefälschte Absender (Spoofing)
• MTA-STS schützt gegen abgehörte Verbindungen auf dem Transportweg (Man-in-the-Middle)
• TLS-RPT informiert dich, wenn Verbindungsprobleme auftreten

Ein vollständig abgesichertes E-Mail-Setup nutzt alle diese Schichten. Beginne mit den Grundlagen (SPF, DKIM, DMARC) und ergänze MTA-STS, sobald diese funktionieren.

Weiterführende Artikel

• DMARC erklärt: Policies und Reporting
• E-Mail-Authentifizierung einrichten: SPF, DKIM, DMARC
• BIMI erklärt: Logo im Posteingang