SaaSFort Die meisten SaaS-Teams halten E-Mail-Sicherheit für erledigt, sobald SPF, DKIM und DMARC grün sind. Diese drei beantworten eine Frage gut: Stammt diese Nachricht wirklich von Ihnen?
Eine völlig andere Frage beantworten sie überhaupt nicht: Wurde die Nachricht verschlüsselt übertragen?
Die Lücke, die niemand prüft
SMTP handelt Verschlüsselung über einen Klartextbefehl aus. Ein sendender Server verbindet sich, der empfangende Server kündigt STARTTLS an, und die Sitzung wird auf TLS umgestellt.
Diese Ankündigung selbst ist nicht authentifiziert. Ein Angreifer auf dem Netzwerkpfad entfernt die STARTTLS-Fähigkeit aus der Antwort des Empfängers. Der Absender sieht kein Verschlüsselungsangebot und stellt über unverschlüsseltes TCP zu. Beide Seiten glauben, korrekt gehandelt zu haben. Nichts in SPF, DKIM oder DMARC schlägt an, denn alle drei validieren die Nachricht, nicht den Tunnel.
Das ist ein Downgrade-Angriff, und er ist praktikabel, solange es SMTP gibt.
Was MTA-STS tatsächlich leistet
MTA-STS (RFC 8461) erlaubt einer empfangenden Domain, eine Zusage zu veröffentlichen: E-Mail an mich muss über authentifiziertes TLS ankommen, und dies sind die Hosts, die sie entgegennehmen dürfen. Ein Absender mit MTA-STS-Unterstützung ruft diese Richtlinie ab, hält sie im Cache und verweigert die Zustellung, wenn die Verbindung nicht abgesichert werden kann.
Sie besteht aus zwei Teilen, und beide müssen vorhanden sein.
Ein DNS-Eintrag unter _mta-sts.ihredomain.de:
v=STSv1; id=20260913120000
Eine Richtliniendatei, über HTTPS bereitgestellt unter https://mta-sts.ihredomain.de/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.ihredomain.de
mx: *.mail.protection.outlook.com
max_age: 604800
Die HTTPS-Anforderung ist der entscheidende Punkt: Die Richtlinie wird durch das System der Zertifizierungsstellen authentifiziert. Ein Angreifer, der DNS manipulieren kann, kann die Richtlinie deshalb trotzdem nicht fälschen.
Das Feld mode ist die ganze Geschichte
Drei Werte sind zulässig, und nur einer schützt überhaupt etwas.
| Modus | Verhalten | Schützt die E-Mail? |
|---|---|---|
none | Richtlinie existiert, sagt aber nichts aus | Nein |
testing | Fehler werden gemeldet, die Zustellung erfolgt dennoch unverschlüsselt | Nein |
enforce | Der Absender verweigert die Zustellung über eine ungeschützte Verbindung | Ja |
Eine Domain, die ein Jahr lang in testing steht, hat den Anschein eines Kontrollmechanismus und keine seiner Wirkungen. Das gehört klar gesagt, denn es ist das häufigste Ergebnis: Teams stellen im Testmodus bereit, die Berichte sehen gut aus, und niemand terminiert die Umstellung.
TLS-RPT macht enforce erst gefahrlos
Ein direkter Wechsel zu enforce riskiert, legitime E-Mails still zu blockieren, etwa wenn ein MX-Host in der Richtlinie fehlt oder ein Zertifikat vorlegt, das nicht validiert.
TLS-RPT (RFC 8460) ist der Rückkanal. Ein einziger TXT-Eintrag:
_smtp._tls.ihredomain.de. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Sendende Anbieter liefern daraufhin tägliche JSON-Zusammenfassungen erfolgreicher und fehlgeschlagener TLS-Aushandlungen zu Ihrer Domain: Zertifikatsvalidierungsfehler, Handshake-Fehler, Hosts ohne jedes TLS-Angebot.
Die Reihenfolge, die funktioniert:
- Veröffentlichen Sie zuerst TLS-RPT.
- Veröffentlichen Sie MTA-STS im
mode: testing. - Lesen Sie die Berichte zwei bis vier Wochen lang. Beheben Sie jeden Fehler, den sie zeigen.
- Wechseln Sie zu
mode: enforce, sobald die Berichte sauber sind. - Lesen Sie sie weiter: Ein ablaufendes Zertifikat auf einem MX-Host taucht hier auf, bevor ein Kunde es bemerkt.
Diese Reihenfolge einzuhalten ist der Unterschied zwischen einem Kontrollmechanismus und einem Ausfall.
Die Verbreitung ist gering, und genau deshalb fällt es Einkäufern auf
Veröffentlichte Messungen über die eine Million meistbesuchten Domains verorten die MTA-STS-Verbreitung 2026 unter einem Prozent. Die praktische Folge für einen B2B-SaaS-Anbieter ist asymmetrisch: Fast niemand hat es, also ist es ein sichtbares Unterscheidungsmerkmal im Sicherheitsfragebogen, und es kostet zwei DNS-Einträge plus eine statische Datei.
Für Anbieter, die nach Deutschland verkaufen, ist das kein optionaler Feinschliff. BSI TR-03108 fordert Transportsicherheit für E-Mail und behandelt DANE, MTA-STS und TLS-RPT als Gesamtheit statt als Alternativen. Wenn Sie auf ein BSI-Prüfungsschreiben antworten, ist fehlendes MTA-STS ein Befund, den Sie an einem Nachmittag schließen können.
Zuordnung zu Rahmenwerken
- NIS2 Artikel 21(2)(h), Kryptografie und Verschlüsselung: Transportverschlüsselung für einen Kommunikationskanal mit Geschäftsdaten.
- NIS2 Artikel 21(2)(e), Netzsicherheit.
- ISO/IEC 27001:2022 A.8.24 (Einsatz von Kryptografie) und A.5.14 (Informationsübertragung).
- DORA Artikel 9, Schutz von Daten während der Übertragung, für Finanzunternehmen und ihre Dienstleister.
Prüfung von außen
Der Sinn eines externen Kontrollmechanismus ist, dass ihn jeder ohne Ihre Mitwirkung prüfen kann. Genau so wird es auch ein Einkäufer tun.
# 1. Wird eine Richtlinie angekündigt?
dig +short TXT _mta-sts.ihredomain.de
# 2. Existiert die Richtlinie, und in welchem Modus?
curl -s https://mta-sts.ihredomain.de/.well-known/mta-sts.txt
# 3. Gibt es einen Meldekanal?
dig +short TXT _smtp._tls.ihredomain.de
Ein SaaSFort-Scan führt alle drei aus und meldet den Modus, nicht bloß das Vorhandensein eines Eintrags, denn eine Richtlinie in testing ist kein bestandener Kontrollmechanismus.
Kurzfassung
SPF, DKIM und DMARC schützen Ihre Marke vor Identitätsmissbrauch. MTA-STS schützt die E-Mails Ihrer Kunden davor, unterwegs mitgelesen zu werden. Das sind verschiedene Probleme, und das zweite ist bei der überwiegenden Mehrheit der SaaS-Anbieter derzeit ungelöst.
Zwei DNS-Einträge und eine statische Datei. Starten Sie im Testmodus, lesen Sie die Berichte, dann erzwingen Sie.
Von der Theorie zur Praxis
Scannen Sie Ihre Domain kostenlos. Erste Ergebnisse in unter 10 Sekunden — ohne Registrierung.