MTA-STS: Die Komplettanleitung zur Absicherung deines E-Mail-Transports

Q: Was ist der Unterschied zwischen den Modi testing und enforce?

Im Modus testing versuchen die sendenden Server die TLS-Verbindung und melden Fehler via TLS-RPT, stellen die Nachricht aber trotzdem zu. Im Modus enforce verweigern die Server die Zustellung der Nachricht, wenn TLS fehlschlägt. Starte immer mit testing , um Probleme zu identifizieren, bevor du auf enforce umstellst.

Von CaptainDNS
Veröffentlicht am 6. Februar 2026

MTA-STS: E-Mail-Transport mit obligatorischer TLS-Verschlüsselung absichern

TL;DR

MTA-STS (RFC 8461) erzwingt TLS-Verschlüsselung für eingehende E-Mails und verhindert Downgrade- sowie Man-in-the-Middle-Angriffe auf SMTP
Zwei Komponenten sind einzurichten: ein DNS-TXT-Eintrag _mta-sts und eine Policy-Datei, gehostet via HTTPS unter mta-sts.captaindns.com/.well-known/mta-sts.txt
Drei Modi verfügbar: none (deaktiviert), testing (Überwachung via TLS-RPT) und enforce (Ablehnung bei fehlgeschlagener TLS-Verschlüsselung)
Starte immer im Modus testing und konfiguriere TLS-RPT, um Fehlerberichte zu erhalten, bevor du auf enforce umstellst

Deine E-Mails werden täglich zwischen SMTP-Servern übertragen. Aber weißt du, ob dieser Austausch tatsächlich verschlüsselt ist? Standardmäßig verwendet SMTP STARTTLS auf opportunistische Weise: Wenn der Zielserver nicht auf die Verschlüsselung reagiert, wird die Nachricht im Klartext gesendet. Ein Angreifer im Netzwerk kann dieses Verhalten erzwingen und deine Kommunikation abfangen.

MTA-STS (Mail Transfer Agent Strict Transport Security) löst dieses Problem. Definiert in RFC 8461, ermöglicht dieser Standard einer Domain, öffentlich zu erklären, dass sie TLS-Verschlüsselung für den E-Mail-Empfang voraussetzt. Sendende Server, die MTA-STS beachten, verweigern den Versand einer Nachricht, wenn die TLS-Verbindung fehlschlägt.

Dieser Guide erklärt dir, wie MTA-STS funktioniert, welche Komponenten es hat, wie du es Schritt für Schritt einrichtest und warum es zu einer unverzichtbaren Ergänzung von DMARC, SPF und DKIM im E-Mail-Sicherheits-Stack geworden ist.

Was ist MTA-STS? (RFC 8461)

MTA-STS, Mail Transfer Agent Strict Transport Security, ist ein Mechanismus, der es dem Inhaber einer Domain ermöglicht, eine Transportsicherheits-Policy für seine E-Mail-Empfangsserver (MX) zu veröffentlichen. Diese Policy teilt den sendenden Servern mit, dass sie:

Eine gültige TLS-Verbindung aushandeln müssen, bevor sie eine E-Mail senden
Das Zertifikat des Zielservers überprüfen müssen (Hostname, Vertrauenskette, Ablaufdatum)
Den Versand verweigern müssen, wenn die TLS-Verschlüsselung fehlschlägt (im Modus enforce)

Warum STARTTLS nicht ausreicht

STARTTLS ist der Standardmechanismus zur Verschlüsselung von SMTP-Verbindungen. Er hat jedoch zwei grundlegende Schwächen:

Downgrade-Angriff: Ein Angreifer kann den STARTTLS-Befehl aus der Serverantwort entfernen und so den Versand im Klartext erzwingen. Der sendende Server weiß nicht, dass Verschlüsselung verfügbar war.
Keine Zertifikatsvalidierung: Selbst wenn STARTTLS ausgehandelt wird, überprüft SMTP standardmäßig nicht die Identität des Zielservers. Ein gefälschter Server mit einem selbstsignierten Zertifikat kann die Nachrichten abfangen.

MTA-STS behebt beide Probleme: Die Policy, abgerufen über HTTPS (separater, authentifizierter Kanal), erzwingt die TLS-Verschlüsselung und die Zertifikatsvalidierung.

Schema der MTA-STS-Funktionsweise: Der sendende Server prüft die Policy vor dem Versand

Die zwei Komponenten von MTA-STS

MTA-STS basiert auf zwei Elementen, die zusammenwirken.

Der DNS-TXT-Eintrag `_mta-sts`

Ein TXT-Eintrag, der in deiner DNS-Zone unter _mta-sts.captaindns.com veröffentlicht wird:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Tag	Pflichtfeld	Beschreibung
`v`	Ja	Protokollversion, immer `STSv1`
`id`	Ja	Eindeutiger Bezeichner der Policy, bei jeder Aktualisierung zu ändern

Das Feld id dient als Aktualisierungssignal. Wenn ein sendender Server eine Änderung der id erkennt, lädt er die Policy erneut herunter. Verwende einen Zeitstempel (z. B. 20260205120000) oder eine fortlaufende Nummer.

Die Policy-Datei mta-sts.txt

Eine Textdatei, gehostet unter der exakten URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 604800

Direktive	Pflichtfeld	Beschreibung
`version`	Ja	Immer `STSv1`
`mode`	Ja	`none`, `testing` oder `enforce`
`mx`	Ja	Erlaubte MX-Pattern (eins pro Zeile, Wildcards wie `*.captaindns.com` erlaubt)
`max_age`	Ja	Cache-Dauer in Sekunden (max. 31 557 600 = 1 Jahr)

Obligatorisches HTTPS-Hosting

Die Policy-Datei muss via HTTPS mit einem gültigen TLS-Zertifikat auf der Subdomain mta-sts bereitgestellt werden. Das ist ein grundlegender Sicherheitsaspekt von MTA-STS: Im Gegensatz zu DNS (das ohne DNSSEC gefälscht werden kann) garantiert HTTPS die Authentizität der Policy durch die Zertifikatsvalidierung.

Die 3 MTA-STS-Modi: testing, enforce, none

Modus testing: Überwachen ohne zu blockieren

mode: testing

Im Modus testing versuchen die sendenden Server, TLS auszuhandeln, und melden Fehler via TLS-RPT (RFC 8460), aber sie stellen die Nachricht trotzdem zu, wenn die Verschlüsselung fehlschlägt. Das ist der empfohlene Startmodus.

Modus enforce: Verschlüsselung oder Ablehnung

mode: enforce

Im Modus enforce verweigern die sendenden Server die Zustellung der Nachricht, wenn die TLS-Verbindung fehlschlägt oder das Zertifikat ungültig ist. Das ist der Zielmodus für vollständigen Schutz.

Modus none: Deaktivierung

mode: none

Der Modus none zeigt an, dass MTA-STS deaktiviert ist. Verwende ihn, um eine bestehende Policy sauber zu deaktivieren (sendende Server, die eine Policy im Cache haben, müssen das Ablaufen von max_age abwarten).

Welchen max_age-Wert wählen?

Deployment-Phase	Empfohlener max_age	Dauer
Start (testing)	86 400	1 Tag
Stabilisierung	604 800	7 Tage
Produktion (enforce)	2 592 000 bis 31 557 600	30 Tage bis 1 Jahr

Ein kurzer max_age in der Testphase ermöglicht schnelle Fehlerkorrekturen. Sobald du auf enforce umgestellt hast, reduziert ein langer max_age die Häufigkeit des erneuten Herunterladens und verstärkt den Schutz gegen temporäre DNS-Angriffe.

MTA-STS Schritt für Schritt einrichten

Schritt 1: MX-Server und TLS-Zertifikate prüfen

Bevor du MTA-STS einrichtest, stelle sicher, dass alle deine MX-Server über ein gültiges TLS-Zertifikat (mindestens TLS 1.2) mit übereinstimmendem Hostnamen verfügen. Ein abgelaufenes oder falsch konfiguriertes Zertifikat führt im Modus enforce zu Ablehnungen.

Schritt 2: Die Policy-Datei erstellen

Erstelle die Datei mta-sts.txt mit deinen MX-Servern. Du kannst den MTA-STS-Generator von CaptainDNS verwenden, um sie automatisch zu erstellen:

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 86400

Schritt 3: Die Policy unter der .well-known-URL hosten

Veröffentliche die Datei unter der exakten URL:

https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Die Subdomain mta-sts muss auf einen HTTPS-Webserver mit gültigem Zertifikat auflösen. Gängige Hosting-Optionen:

Cloudflare Pages / Cloudflare Workers: kostenlos, automatisches HTTPS
GitHub Pages: kostenlos, Let's-Encrypt-Zertifikat
Azure Static Web Apps: Microsoft-365-Integration
Bestehender Webserver: Apache, Nginx mit Let's Encrypt

Der Content-Type der Antwort muss text/plain sein.

Schritt 4: Den DNS-TXT-Eintrag veröffentlichen

Füge in deiner DNS-Zone hinzu:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Schritt 5: Deine Konfiguration validieren

Verwende den MTA-STS-Checker von CaptainDNS, um zu prüfen, ob alles korrekt eingerichtet ist: DNS-Eintrag, Policy-Datei, TLS-Zertifikat, MX-Übereinstimmung.

MTA-STS-Deployment-Checkliste in 5 Schritten

MTA-STS vs. DANE vs. STARTTLS

Drei Mechanismen existieren nebeneinander, um den SMTP-Transport abzusichern. Hier sind ihre Unterschiede:

Kriterium	STARTTLS allein	MTA-STS	DANE
Schutz	Opportunistische Verschlüsselung	Obligatorische Verschlüsselung	Obligatorische Verschlüsselung
Zertifikatsvalidierung	Nein	Ja (via HTTPS/CA)	Ja (via DNSSEC/TLSA)
Schutz gegen Downgrade-Angriffe	Nein	Ja	Ja
Voraussetzungen	Keine	HTTPS auf Subdomain `mta-sts`	DNSSEC in der DNS-Zone
Deployment-Komplexität	Gering	Mittel	Hoch
Verbreitung	Universell	Wachsend (Google, Microsoft)	Begrenzt (DNSSEC-Voraussetzung)
RFC	RFC 3207	RFC 8461	RFC 7671

In der Praxis: MTA-STS ist die pragmatische Wahl. DANE bietet theoretisch höhere Sicherheit (keine Abhängigkeit von CAs), erfordert aber DNSSEC, das noch wenig verbreitet ist. Beide Ansätze sind komplementär und können parallel betrieben werden.

TLS-RPT: Dein MTA-STS-Deployment überwachen

TLS-RPT (SMTP TLS Reporting, RFC 8460) ist der unverzichtbare Begleiter von MTA-STS. Es ermöglicht dir, tägliche JSON-Berichte über erfolgreiche und fehlgeschlagene TLS-Aushandlungen für deine Domain zu erhalten.

Um TLS-RPT zu aktivieren, veröffentliche einen DNS-Eintrag:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Diese Berichte sind im Modus testing unverzichtbar: Sie ermöglichen dir, Probleme zu identifizieren (abgelaufene Zertifikate, nicht abgedeckte MX-Server, Server ohne TLS-1.2-Unterstützung), bevor du auf den Modus enforce umstellst.

Empfohlener Aktionsplan

Prüfe deine TLS-Zertifikate: Alle deine MX-Server müssen über ein gültiges Zertifikat mit TLS 1.2+ verfügen
Starte im Modus testing: Erstelle die Policy und den DNS-Eintrag mit mode: testing und max_age: 86400
Aktiviere TLS-RPT: Veröffentliche den Eintrag _smtp._tls, um Fehlerberichte zu erhalten
Überwache 2–4 Wochen: Analysiere die TLS-RPT-Berichte und behebe die identifizierten Probleme
Wechsle auf den Modus enforce: Sobald die Berichte sauber sind, ändere auf mode: enforce und erhöhe den max_age

Prüfe jetzt deine MTA-STS-Konfiguration: Verwende unseren MTA-STS-Checker, um deine Domain in wenigen Sekunden zu analysieren.

FAQ

Was ist MTA-STS und warum brauche ich es?

MTA-STS (Mail Transfer Agent Strict Transport Security) ist ein Internetstandard (RFC 8461), der es einer Domain ermöglicht zu erklären, dass sie TLS-Verschlüsselung für den E-Mail-Empfang voraussetzt. Ohne MTA-STS nutzen SMTP-Verbindungen STARTTLS auf opportunistische Weise, was sie anfällig für Downgrade- und Man-in-the-Middle-Angriffe macht. MTA-STS stellt sicher, dass deine eingehenden E-Mails während des Transports immer verschlüsselt sind.

Ist MTA-STS für die E-Mail-Sicherheit verpflichtend?

MTA-STS ist noch nicht regulatorisch verpflichtend, wird aber dringend empfohlen. Google und Microsoft haben es auf ihren Domains aktiviert und prüfen, ob MTA-STS auf den Domains vorhanden ist, die sie kontaktieren. Für Organisationen mit Compliance-Anforderungen (DSGVO, PCI-DSS) stärkt MTA-STS die Sicherheitslage des E-Mail-Transports.

Was ist der Unterschied zwischen den Modi testing und enforce?

Im Modus testing versuchen die sendenden Server die TLS-Verbindung und melden Fehler via TLS-RPT, stellen die Nachricht aber trotzdem zu. Im Modus enforce verweigern die Server die Zustellung der Nachricht, wenn TLS fehlschlägt. Starte immer mit testing, um Probleme zu identifizieren, bevor du auf enforce umstellst.

Wie vergleicht sich MTA-STS mit DANE?

MTA-STS verwendet HTTPS und Zertifizierungsstellen (CAs) zur Authentifizierung der Policy, während DANE DNSSEC und TLSA-Einträge nutzt. DANE bietet höhere Sicherheit (keine Abhängigkeit von CAs), erfordert aber DNSSEC, das noch wenig verbreitet ist. MTA-STS ist einfacher einzurichten und weiter verbreitet. Beide Mechanismen sind komplementär.

Sollte man TLS-RPT zusammen mit MTA-STS konfigurieren?

Ja, das wird dringend empfohlen. TLS-RPT (RFC 8460) sendet dir tägliche Berichte über erfolgreiche und fehlgeschlagene TLS-Aushandlungen für deine Domain. Ohne TLS-RPT hast du keine Einsicht in die Probleme deines MTA-STS-Deployments. Veröffentliche einen _smtp._tls-Eintrag mit einer Empfangsadresse.

Wie konfiguriere ich MTA-STS für Microsoft 365?

Für Microsoft 365 verwende das MX-Pattern *.mail.protection.outlook.com in deiner MTA-STS-Policy. Hoste die Policy-Datei auf Azure Static Web Apps, Cloudflare Pages oder einem beliebigen HTTPS-Server. Microsoft unterstützt MTA-STS beim Senden (es prüft die Policy deiner Empfänger) und beim Empfangen (du kannst eine Policy für deine M365-Domain veröffentlichen).

Wie konfiguriere ich MTA-STS für Google Workspace?

Für Google Workspace füge folgende MX-Pattern in deine Policy ein: aspmx.l.google.com, *.google.com und *.googlemail.com. Google prüft aktiv die MTA-STS-Policies der Domains, die es kontaktiert, und veröffentlicht TLS-RPT-Berichte. Hoste die Policy-Datei auf einem HTTPS-Server mit gültigem Zertifikat für die Subdomain mta-sts.

Was passiert, wenn die Policy-Datei nicht erreichbar ist?

Wenn die Datei mta-sts.txt nicht erreichbar ist (HTTP-Fehler, Timeout, ungültiges Zertifikat), kann der sendende Server die Policy nicht anwenden. Ohne gecachte Policy fällt er auf das standardmäßige opportunistische STARTTLS-Verhalten zurück. Wenn eine Policy im Cache ist (nicht abgelaufen gemäß max_age), wird sie weiterhin angewendet. Deshalb schützt ein ausreichend langer max_age gegen vorübergehende Ausfälle.

Glossar

MTA-STS: Mail Transfer Agent Strict Transport Security. Standard RFC 8461, der TLS-Verschlüsselung für den E-Mail-Empfang erzwingt.
STARTTLS: SMTP-Erweiterung, die es ermöglicht, eine Klartextverbindung auf eine TLS-verschlüsselte Verbindung umzustellen. Standardmäßig opportunistisch.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mechanismus zur Berichterstattung über erfolgreiche und fehlgeschlagene TLS-Aushandlungen.
DANE: DNS-based Authentication of Named Entities (RFC 7671). Nutzt DNSSEC und TLSA-Einträge zur Validierung von TLS-Zertifikaten.
Downgrade-Angriff: Technik, bei der ein Angreifer eine Verbindung zur Nutzung eines weniger sicheren Protokolls zwingt (z. B. STARTTLS entfernen, um den Versand im Klartext zu erzwingen).
max_age: Direktive der MTA-STS-Policy, die die Cache-Dauer in Sekunden angibt.