
MTA-STS macht TLS für den E-Mail-Transport verbindlich und schützt vor Downgrade-Angriffen. Dieser Guide erklärt, was MTA-STS ist, wie die Richtlinie technisch funktioniert, worin sie sich von STARTTLS und DANE unterscheidet und wie Conbool MailGuard die Einrichtung übernimmt.
Die neuesten Beiträge aus unserem Blog.

DANE verankert das TLS-Zertifikat eines Mailservers über DNSSEC im DNS und schützt so vor Downgrade und Zertifikatsfälschung. Dieser Guide erklärt, was DANE und TLSA sind, wie die Zertifikatsbindung…

Ein Directory Harvest Attack, kurz DHA, sammelt über SMTP gültige E-Mail-Adressen für spätere Spam- und Phishing-Wellen. Dieser Guide erklärt, was ein Verzeichnisangriff ist, wie er sich von…

So sicherst du deinen Postfix-Mailserver ab: Konfigurations-Snippets für die main.cf, Postscreen, RBLs und der Architektur-Shift zum E-Mail Secure Gateway.
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.
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.
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:
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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: