MTA-STS: Was ist das und wozu dient es

Von Thomas · virtueller CISO · 2026-07-29

DMARC, SPF und DKIM beantworten alle dieselbe Frage: „Kommt diese Nachricht wirklich von dem, der sie vorgibt zu sein?" MTA-STS beantwortet eine andere und ergänzende Frage: „Ist diese Nachricht verschlüsselt gereist, geschützt vor einem Abfangen?" Beide Probleme sind real und verschieden — eine E-Mail kann perfekt authentifiziert sein und dennoch im Klartext über das Netz gelaufen sein, verwundbar durch Abhören oder Veränderung während der Übertragung. Dieser Leitfaden erklärt, was MTA-STS schützt, warum das SMTP-Protokoll es brauchte und wie man es einsetzt.

Das Problem, das MTA-STS löst

SMTP, das Protokoll, das die Post zwischen Servern befördert, wurde nicht mit nativer Verschlüsselung konzipiert. Eine Erweiterung namens STARTTLS ermöglicht es, die Verbindung zu verschlüsseln, hat aber einen strukturellen Mangel: Sie ist opportunistisch. Der Absenderserver bietet STARTTLS an, und wenn der Empfängerserver es nicht unterstützt — oder wenn ein Angreifer, der in der Lage ist, den Verkehr abzufangen, dieses Angebot entfernt — fällt die Verbindung still auf Klartext zurück. Keine Warnung, keine Blockierung: Die Nachricht geht trotzdem raus, nur ohne Verschlüsselung — und weder der Absender noch der Empfänger haben standardmäßig irgendein Mittel, um zu erfahren, dass die Herabstufung stattgefunden hat.

Dieser Angriff heißt Herabstufung (downgrade attack). Ein Angreifer, der sich zwischen den beiden Servern positioniert (im Netz, bei einem kompromittierten Zugangsanbieter oder über einen Man-in-the-Middle-Angriff), kann die STARTTLS-Aushandlung abfangen und sie absichtlich scheitern lassen, wodurch beide Server gezwungen werden, im Klartext zu sprechen, ohne dass einer von beiden es weiß. Der Inhalt der Nachricht — potenziell sensible Informationen — wird dann während der Übertragung lesbar.

Was MTA-STS ändert

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) löst dieses Problem, indem es eine explizite Policy veröffentlicht: „Meine Domain verlangt TLS, um Post zu empfangen, und wenn TLS scheitert, verweigere den Versand, statt auf Klartext zurückzufallen." Das ist kein optionales Angebot mehr, das der Angreifer entfernen kann — es ist eine im Voraus veröffentlichte Anforderung, die der Absender konsultieren und respektieren muss.

Technisch beruht dies auf zwei Elementen: einem DNS-TXT-Eintrag, der die Existenz einer MTA-STS-Policy signalisiert, und einer über HTTPS bereitgestellten Policy-Datei (die also selbst gegen Fälschung geschützt ist), die den Anwendungsmodus präzisiert. Der Absender, der MTA-STS respektiert, konsultiert diese Policy vor dem Versand und verweigert die Zustellung, wenn TLS zu einem als konform gelisteten Server nicht hergestellt werden kann.

Wie man MTA-STS einsetzt

Das Deployment umfasst drei Elemente:

Der DNS-Eintrag. Auf _mta-sts.beispiel.de wird ein TXT veröffentlicht, der eine Versionskennung der Policy enthält (v=STSv1; id=...). Diese Kennung ändert sich bei jeder Aktualisierung der Policy, um den Absendern zu signalisieren, dass sie sie erneut herunterladen müssen.
Die Policy-Datei. Über HTTPS gehostet auf https://mta-sts.beispiel.de/.well-known/mta-sts.txt, präzisiert sie den Anwendungsmodus (testing, enforce) und die Liste der MX-Server, die berechtigt sind, die Post der Domain per TLS zu empfangen.
Der Startmodus: testing vor enforce. Genau wie bei DMARC ist die gute Praxis, im Modus testing zu beginnen, der die TLS-Verbindungsfehler protokolliert, ohne die Zustellung zu blockieren, bevor man in enforce übergeht, sobald die Konfiguration validiert ist. Hier kommt das weiter unten beschriebene ergänzende Protokoll ins Spiel.

TLS-RPT: die Rückmeldung von MTA-STS

MTA-STS allein legt fest, was zu verlangen ist, sagt aber nichts darüber, was tatsächlich passiert auf Seiten der Absender, die die Domain zu erreichen versuchen. Das ist die Rolle von TLS-RPT (SMTP TLS Reporting), einem Begleitprotokoll, das für MTA-STS das tut, was die aggregierten Berichte für DMARC tun: Es schickt tägliche Berichte zurück, die die von den schreibenden Absendern beobachteten Erfolge und Misserfolge der TLS-Verbindung im Detail aufführen. Ohne TLS-RPT läuft es darauf hinaus, MTA-STS in enforce zu setzen, wie eine DMARC-Policy zu verschärfen, ohne jemals die Berichte zu lesen — eine Wette im Blindflug, bei der niemals zu erfahren ist, ob ein legitimer Absender blockiert wurde, weil er kein TLS herstellen konnte. Das Protokoll wird in TLS-RPT erklärt ausführlich behandelt; beide werden fast immer zusammen eingesetzt.

Die Parallele zu DMARC

Die methodische Ähnlichkeit mit DMARC ist kein Zufall — beide Protokolle beantworten dasselbe strukturelle Problem (ein optionaler, still umgehbarer Sicherheitsmechanismus) mit derselben Lösung (eine explizite Policy veröffentlichen und eine Berichtsschleife, um sie vor dem Verschärfen zu validieren). Wer bereits ein DMARC-Deployment über die Reihenfolge none → quarantine → reject durchgeführt hat, findet die Reihenfolge testing → enforce von MTA-STS, begleitet von TLS-RPT, vertraut. Das Vorsichtsprinzip ist identisch: Der Wechsel in die strenge Anwendung erfolgt erst, wenn die Berichte als sauber erwiesen sind.

Schützt MTA-STS gegen Fälschung?

Nein, und das ist eine häufige Verwechslung, die auszuräumen ist. MTA-STS schützt den Transport — die Vertraulichkeit und Integrität der Nachricht während ihrer Reise zwischen den Servern. Es sagt nichts über die Identität des Absenders aus, die vollständig in den Zuständigkeitsbereich von SPF, DKIM und DMARC fällt. Eine während der Übertragung perfekt verschlüsselte Nachricht kann sehr wohl eine gefälschte E-Mail sein; eine perfekt authentifizierte Nachricht kann sehr wohl im Klartext gereist sein. Die beiden Schichten sind ergänzend, nicht austauschbar — ein ernsthaftes E-Mail-Deployment im Jahr 2026 deckt beide ab, nicht die eine auf Kosten der anderen, denn MTA-STS als Ersatz für DMARC (oder umgekehrt) zu behandeln, läuft darauf hinaus, das Gefäß mit dem Inhalt zu verwechseln.

Wer am meisten von MTA-STS profitiert

Das Protokoll hat einen besonders hohen Wert für Organisationen, die sensible Informationen per E-Mail austauschen: Finanzsektor, Gesundheit, Recht, Verwaltungen. Eine auf diese Art von Verkehr ausgenutzte TLS-Herabstufung legt Daten offen, deren Vertraulichkeit oft eine regulatorische Verpflichtung ist, nicht nur eine gute Praxis — man denke an Kontoauszüge, Krankenakten oder Verfahrensunterlagen, die per E-Mail ausgetauscht werden, wo ein Abfangen im Klartext potenziell einen meldepflichtigen Vorfall darstellt. Das Thema kreuzt sich direkt mit den Compliance-Fragen, die die am stärksten regulierten Sektoren betreffen — siehe DMARC für Banken für ein Beispiel eines Sektors, in dem sich diese Art von Anforderung an verschlüsselten Transport natürlich zu den Authentifizierungspflichten gesellt. Ein Unternehmen, das seine Sorgfalt beim Schutz von E-Mail-Daten nachweisen muss, hat allen Grund, MTA-STS ebenso wie DMARC in seiner Compliance-Akte zu dokumentieren, statt es als ein rein technisches Detail ohne Beweiswert zu behandeln.

Die Rolle der über HTTPS bereitgestellten Policy-Datei

Ein architektonisches Detail verdient eine Erklärung, denn es enthüllt, warum MTA-STS robuster ist als STARTTLS allein. Die Policy-Datei ist nicht im DNS selbst gespeichert (im Gegensatz zu DMARC oder SPF) — sie ist über HTTPS gehostet, auf einer dedizierten Subdomain mta-sts.beispiel.de. Warum diese zweistufige Architektur, ein DNS-Eintrag und eine Web-Datei?

Die Antwort liegt in der Größe und Natur der Information. Ein DNS-TXT-Eintrag ist in der Größe begrenzt und wenig geeignet, um eine Liste von MX-Servern und Modusregeln zu enthalten. Ein leichter DNS-Eintrag (nur eine Versionskennung) gekoppelt mit einer vollständigen HTTPS-Datei (geschützt durch die Standard-TLS-Zertifikate des Web, die selbst verifiziert werden) gibt hingegen das Beste aus beiden Welten: eine leichte und schnell zu konsultierende Benachrichtigung im DNS und einen detaillierten Inhalt, der durch die bestehende HTTPS-Vertrauensinfrastruktur geschützt ist. Ein Angreifer, der die Policy fälschen wollte, müsste also sowohl das DNS kompromittieren als auch ein gültiges TLS-Zertifikat für die Subdomain erlangen — eine viel höhere Hürde als ein DNS-Eintrag allein.

Das Caching auf Absenderseite

Ein weiterer Mechanismus, den man kennen sollte: Die Absender, die MTA-STS respektieren, laden die Policy-Datei nicht bei jeder versendeten E-Mail erneut herunter — sie speichern sie im Cache, in der Regel für eine in der Datei selbst definierte Dauer (oft mehrere Tage). Aus diesem Grund ist die Versionskennung (id=) im DNS-Eintrag wesentlich: Es ist das Signal, das einem Absender im Cache anzeigt, dass eine neue Version existiert und erneut heruntergeladen werden muss. Wird die Policy geändert (zum Beispiel durch Hinzufügen eines neuen MX-Servers), ohne diese Kennung anzupassen, so wenden manche Absender während der gesamten Dauer ihres Caches weiterhin die alte Version an — eine klassische Falle bei einer Migration der Mail-Infrastruktur.

Zu kennende Grenzen

MTA-STS schützt nur die Reise zwischen den Mailservern (den Server-zu-Server-SMTP-Abschnitt); es deckt nicht die Verbindung zwischen einem Mail-Client und seinem eigenen Versandserver ab (in der Regel bereits durch andere Mittel verschlüsselt), noch den Inhalt, sobald er in einem Posteingang gespeichert ist. Es ist ein auf ein präzises Glied der Kette ausgerichteter Schutz — wertvoll, aber keine Ende-zu-Ende-Verschlüsselungslösung. Für dieses Garantieniveau bräuchte es separate Mechanismen wie S/MIME oder PGP, die den Inhalt selbst verschlüsseln statt nur den Transport zwischen den Servern.

Eine weitere Grenze ist die Abhängigkeit von der Kooperation der Absender. MTA-STS beschreibt, was die empfangende Domain für den eingehenden Verkehr verlangt, aber es wirkt nur, wenn der Absender das Protokoll ebenfalls respektiert. Ein Absender, dessen Server MTA-STS nicht implementiert, konsultiert die Policy schlicht nicht — er wird versuchen, per STARTTLS zuzustellen, aber ohne die Garantie, dass eine Herabstufung ihn stoppt. Die gute Nachricht ist, dass die großen Anbieter (Gmail, Outlook, Yahoo) MTA-STS unterstützen, sodass die Mehrheit des realen Verkehrs abgedeckt ist. Man sollte aber nicht davon ausgehen, dass die Veröffentlichung einer Policy jeden eingehenden Server zwingt, sie zu befolgen — sie deckt die kooperierenden Absender, was in der Praxis der größte Teil ist, aber nicht die Gesamtheit.

Schließlich ist zu beachten, dass MTA-STS eine funktionierende HTTPS- und DNS-Infrastruktur voraussetzt. Wenn das Zertifikat der Subdomain mta-sts.beispiel.de abläuft oder wenn die Datei nicht mehr erreichbar ist, können die konformen Absender ihre Prüfung nicht durchführen. Je nachdem, wie ihr System auf diesen Fehler reagiert, kann das die Zustellung an die Domain beeinträchtigen. Das ist ein weiterer Grund, den Startmodus testing ernst zu nehmen und die Erneuerung des Zertifikats zu überwachen, wie es für jeden anderen öffentlich zugänglichen Dienst selbstverständlich ist.

Zusammenfassung

MTA-STS schließt eine strukturelle Lücke von SMTP — die stille Herabstufung auf Klartext — indem es eine optionale Aushandlung durch eine veröffentlichte und überprüfbare Policy ersetzt. Verbunden mit TLS-RPT für die Sichtbarkeit und mit derselben methodischen Vorsicht eingesetzt wie ein DMARC-Deployment (testing vor enforce), ist es eine Sicherheitsschicht, die die von SPF, DKIM und DMARC gebotene Authentifizierung ergänzt, ohne sie zu ersetzen.

Um den Zustand der grundlegenden E-Mail-Authentifizierung zu prüfen, bevor diese Transportschicht hinzukommt, führt der Weg über den kostenlosen DMARC-Analysator, durch den sich jede Domain schicken lässt — die Identität zuerst, die Verschlüsselung der Reise danach, in dieser Prioritätsreihenfolge. Sobald die Transportrichtlinie veröffentlicht ist, bestätigt der kostenlose MTA-STS-Prüfer deren Modus und die korrekte Abrufbarkeit.

DMARC anwenden — konkret

Thomas, der virtuelle CISO von DMARC.com, identifiziert jede legitime Versandquelle, schreibt die exakten DNS-Einträge und bringt eine Domain sicher von p=none zu p=reject — ohne den Mailverkehr zu stören.

Zu p=reject — kostenlos