Was ist MTA-STS? Funktionsweise und Einrichtung einfach erklärt
E-Mail wurde nie für Vertraulichkeit entworfen. Damit eine Nachricht den Weg von einem Mailserver zum nächsten verschlüsselt zurücklegt, springt seit Jahren das Protokoll STARTTLS ein. Das Problem: STARTTLS ist freiwillig. Fällt die Verschlüsselung aus oder greift jemand aktiv ein, landet die E-Mail im Klartext im Netz, ganz ohne Warnung. Genau diese Lücke schließt MTA-STS.
Dieser Guide erklärt verständlich, was MTA-STS ist, wie die Richtlinie technisch arbeitet, worin sie sich von STARTTLS und DANE unterscheidet und wie Unternehmen die verbindliche Transportverschlüsselung sauber einführen.
Was ist MTA-STS?
TL;DR: MTA-STS, kurz für Mail Transfer Agent Strict Transport Security, ist ein in RFC 8461 standardisierter Mechanismus. Eine Domäne veröffentlicht damit eine Richtlinie, die empfangende Mailserver verpflichtet, E-Mails nur über eine geprüfte TLS-Verbindung anzunehmen. Aus der freiwilligen Verschlüsselung wird eine verbindliche Vorgabe, die vor unverschlüsselter Zustellung und vor Downgrade-Angriffen schützt.
MTA-STS ist eine Richtlinie, mit der eine Domäne gegenüber der ganzen Welt erklärt: Meine E-Mails dürfen ausschließlich verschlüsselt zugestellt werden. Die Richtlinie nennt die zuständigen Mailserver einer Domäne und schreibt vor, dass ein sendender Server vor der Zustellung sowohl den Hostnamen als auch das TLS-Zertifikat des Zielservers prüft. Stimmt etwas nicht, wird die Zustellung im strengsten Modus abgebrochen statt unverschlüsselt fortgesetzt.
Der Standard adressiert damit ein konkretes Risiko der zwischenserverlichen Kommunikation, also dem Transport von Mailserver zu Mailserver, nicht der Ende-zu-Ende-Verschlüsselung einzelner Nachrichten.
Warum reicht STARTTLS allein nicht aus?
STARTTLS verschlüsselt die Verbindung zwischen zwei Mailservern, sobald beide Seiten zustimmen. Der entscheidende Schwachpunkt liegt im Wort opportunistisch. Es gibt keine verbindliche Erwartung, dass verschlüsselt wird. Daraus ergeben sich zwei Angriffspunkte:
- Stilles Downgrade: Ein Angreifer in der Position eines Mittelsmanns entfernt das STARTTLS-Signal aus der Serverkommunikation. Beide Seiten glauben, die Gegenstelle könne nicht verschlüsseln, und die Nachricht geht im Klartext über die Leitung.
- Gefälschtes Ziel: Ohne Prüfung von Hostname und Zertifikat kann eine umgeleitete Verbindung auf einem fremden Server enden, ohne dass der sendende Server dies bemerkt.
Weil STARTTLS bei einem Fehler einfach auf Klartext zurückfällt, bleibt der Angriff unsichtbar. MTA-STS dreht diese Logik um: Eine fehlende oder nicht vertrauenswürdige TLS-Verbindung ist kein Grund zum Zurückfallen, sondern ein Grund, die Zustellung zu verweigern.
Wie funktioniert MTA-STS Schritt für Schritt?
Die Funktionsweise lässt sich in vier Schritte gliedern:
Schritt 1, Hinweis im DNS: Ein TXT-Eintrag unter _mta-sts.ihre-domain.de signalisiert, dass eine Richtlinie existiert, und enthält eine Versionskennung. Ändert sich die Richtlinie, ändert sich dieser Eintrag.
Schritt 2, Richtlinie über HTTPS: Die eigentliche Richtlinie liegt als Datei unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt. Sie nennt die erlaubten Mailserver, den Betriebsmodus und die Gültigkeitsdauer. Der Abruf über HTTPS mit gültigem Zertifikat stellt sicher, dass die Richtlinie nicht manipuliert wurde.
Schritt 3, Prüfung beim Versand: Will ein fremder Server an Ihre Domäne zustellen, ruft er die Richtlinie ab, speichert sie zwischen und vergleicht den Zielserver mit den erlaubten Hostnamen. Anschließend prüft er das TLS-Zertifikat.
Schritt 4, Entscheidung: Passt alles, wird verschlüsselt zugestellt. Passt es nicht, hängt das Verhalten vom Modus ab.
Die drei Betriebsmodi von MTA-STS
MTA-STS kennt drei Modi, die einen risikoarmen Rollout ermöglichen:
| Modus | Verhalten | Einsatz |
|---|---|---|
| none | Keine Erzwingung, Richtlinie wird zurückgezogen | Abkündigung oder Pause |
| testing | Verstöße werden nur gemeldet, Zustellung läuft weiter | Beobachtung vor der Scharfschaltung |
| enforce | Zustellung bei ungültiger TLS-Verbindung wird abgebrochen | Produktiver Schutz |
Der empfohlene Weg führt über testing. In diesem Modus sammeln Sie über Berichte ein Bild davon, welche Partner sauber verschlüsseln, ohne den Mailfluss zu riskieren. Erst wenn die Berichte stabil sind, folgt die Umstellung auf enforce.
MTA-STS und TLS-RPT gehören zusammen
MTA-STS erzwingt Verschlüsselung, sagt aber von sich aus nichts darüber, was im Transport passiert. Diese Sichtbarkeit liefert TLS-RPT, das SMTP TLS Reporting. Über einen weiteren DNS-Eintrag fordert eine Domäne damit tägliche Berichte an, die zeigen, wie viele Verbindungen erfolgreich verschlüsselt wurden und woran fehlgeschlagene Zustellungen lagen. Erst die Kombination aus Erzwingung und Berichten macht den Schritt auf enforce sicher beherrschbar.
MTA-STS, DANE und die Frage nach DNSSEC
MTA-STS und DANE verfolgen dasselbe Ziel, verbindliche Transportverschlüsselung, gehen aber unterschiedliche Wege. DANE bindet das Zertifikat eines Mailservers über einen signierten DNS-Eintrag und setzt dafür zwingend DNSSEC voraus. MTA-STS kommt ohne DNSSEC aus und stützt sich stattdessen auf die Vertrauenskette gängiger Zertifizierungsstellen sowie auf HTTPS. In der Praxis schließen sich beide nicht aus, sondern ergänzen sich. Das BSI empfiehlt in der Technischen Richtlinie TR-03108 den parallelen Einsatz beider Verfahren.
MTA-STS und Compliance: NIS2 und BSI
Verbindliche Transportverschlüsselung ist längst keine reine Fleißaufgabe mehr. Die Technische Richtlinie TR-03108 des BSI nennt MTA-STS, DANE und TLS-RPT als Bausteine für sicheren E-Mail-Transport. Über die NIS2-Richtlinie und § 30 BSIG werden Kryptografie und gesicherte Kommunikation für viele Unternehmen zur Pflicht. MTA-STS ist eine konkrete, nachweisbare Maßnahme, mit der sich ein Teil dieser Anforderungen belegen lässt, auch im Hinblick auf den Stand der Technik nach Artikel 32 DSGVO.
MTA-STS mit Conbool MailGuard einrichten
Der größte praktische Stolperstein bei MTA-STS ist die Bereitstellung der Richtliniendatei über eine eigene HTTPS-Subdomäne samt dauerhaft gültigem Zertifikat. Plattformen wie Exchange Online übernehmen diese Aufgabe nicht selbst. Conbool MailGuard löst genau das: Die Richtlinie und die Subdomäne werden bereitgestellt, das Zertifikat bleibt automatisch gültig, der Rollout von testing auf enforce erfolgt geführt und die zugehörigen TLS-Berichte laufen an einer Stelle zusammen.
Wer den aktuellen Status einer Domäne zuerst prüfen möchte, kann das mit dem kostenlosen Transportsicherheits-Check tun. Die Details zur verwalteten Lösung stehen auf der Seite zu MTA-STS.
Häufig gestellte Fragen zu MTA-STS
Was ist MTA-STS?
MTA-STS steht für Mail Transfer Agent Strict Transport Security. Eine Domäne hinterlegt damit eine Richtlinie, die empfangenden Mailservern vorschreibt, E-Mails nur über eine geprüfte TLS-Verbindung anzunehmen. So wird Transportverschlüsselung verbindlich.
Wie funktioniert MTA-STS technisch?
Ein DNS-TXT-Eintrag unter _mta-sts zeigt an, dass eine Richtlinie existiert. Die Richtlinie selbst liegt als Datei mta-sts.txt auf einer HTTPS-Subdomäne und nennt erlaubte Mailserver, Modus und Gültigkeitsdauer. Sendende Server prüfen Hostname und Zertifikat des Ziels und brechen im Modus enforce bei Abweichungen ab.
Warum reicht herkömmliches STARTTLS nicht aus?
STARTTLS ist opportunistisch und fällt bei einem Fehler still auf Klartext zurück. Ein Angreifer kann das STARTTLS-Signal entfernen und die Übertragung so unverschlüsselt erzwingen. MTA-STS verhindert das, weil eine ungültige TLS-Verbindung im Modus enforce zum Abbruch führt.
Funktioniert MTA-STS mit Microsoft 365 und Google Workspace?
Ja. Beide Plattformen werten eingehende MTA-STS-Richtlinien aus und senden TLS-Berichte. Für die eigene Domäne muss die Richtlinie auf einer erreichbaren HTTPS-Subdomäne liegen, was Exchange Online nicht selbst übernimmt. Diese Bereitstellung lässt sich auslagern.
Ist MTA-STS kostenlos?
Der Standard ist offen und ohne Lizenzkosten. Aufwand entsteht durch die Bereitstellung der Richtliniendatei über HTTPS, ein gültiges Zertifikat und die laufende Überwachung. Managed-Dienste übernehmen diese Aufgaben gegen eine Gebühr pro Domäne.
Fazit
MTA-STS schließt die größte Lücke der zwischenserverlichen E-Mail-Verschlüsselung: die Freiwilligkeit von STARTTLS. Aus einem optionalen Schutz wird eine verbindliche Vorgabe, die vor Downgrade-Angriffen und stiller Klartextzustellung bewahrt. In Kombination mit TLS-RPT und DANE entsteht ein belastbarer, nachweisbarer Transportschutz, der direkt auf die Anforderungen von BSI und NIS2 einzahlt.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem Transportsicherheits-Check und sehen Sie, wie Conbool MailGuard die Einrichtung übernimmt.
Weiterführende Artikel:
