MTA-STS vs DANE: Welches Protokoll zur Absicherung des E-Mail-Transports wählen?

⚡TL;DR

• MTA-STS (RFC 8461) veröffentlicht eine Richtlinie zur Verschlüsselungspflicht über HTTPS. Es funktioniert ohne DNSSEC, aber die erste Verbindung bleibt anfällig (TOFU)
• DANE/TLSA (RFC 7672) verankert das TLS-Zertifikat im durch DNSSEC signierten DNS. Kein TOFU, aber DNSSEC ist über die gesamte Kette erforderlich
• Beide Protokolle ergänzen sich: MTA-STS deckt Domains ohne DNSSEC ab, DANE eliminiert TOFU für diejenigen, die es haben
• Hosten Sie Ihre MTA-STS-Richtlinie kostenlos mit CaptainDNS: Zwei DNS-Einträge genügen

Opportunistische SMTP-Verschlüsselung (STARTTLS) schützt die Mehrheit der E-Mails während der Übertragung. Doch "opportunistisch" bedeutet, dass ein Netzwerkangreifer sie entfernen kann, ohne dass es jemand bemerkt. SMTP-Downgrade-Angriffe nutzen diese Schwäche aus, um Nachrichten im Klartext abzufangen.

Zwei Protokolle begegnen diesem Problem: MTA-STS (RFC 8461) und DANE/TLSA (RFC 7672). Beide erzwingen obligatorische TLS-Verschlüsselung zwischen E-Mail-Servern. Doch ihre Vertrauensmechanismen, Voraussetzungen und Verbreitung unterscheiden sich.

Dieser Artikel vergleicht MTA-STS und DANE Kriterium für Kriterium. Er identifiziert die jeweiligen Einsatzszenarien und führt Sie zur besten Strategie für Ihre Infrastruktur. Ob Sie Domains mit einem Cloud-Anbieter oder eigenen MX-Servern verwalten, dieser Vergleich ist für Sie.

Wie funktionieren MTA-STS und DANE?

Beide Protokolle verfolgen dasselbe Ziel: verhindern, dass ein Absenderserver eine E-Mail im Klartext sendet, wenn der Empfängerserver TLS unterstützt. Doch sie verwenden unterschiedliche Vertrauenskanäle.

MTA-STS: eine über HTTPS veröffentlichte Richtlinie

MTA-STS basiert auf zwei Elementen:

1. Einem DNS-TXT-Eintrag _mta-sts.captaindns.com, der die Existenz der Richtlinie signalisiert und eine Versions-ID enthält
2. Einer Textdatei, die über HTTPS auf https://mta-sts.captaindns.com/.well-known/mta-sts.txt gehostet wird und die Richtlinie beschreibt: autorisierte MX-Server, Modus (Testing oder Enforce), Cache-Dauer (max_age)

Wenn ein Absenderserver (wie Gmail oder Outlook) eine E-Mail an Ihre Domain senden möchte:

1. Er fragt das DNS nach _mta-sts.captaindns.com ab
2. Er lädt die Richtlinie über HTTPS herunter (durch das Webzertifikat authentifizierter Kanal)
3. Er prüft, ob der MX-Server mit der Richtlinie übereinstimmt
4. Im Modus Enforce verweigert er den Versand im Klartext oder an einen nicht gelisteten MX

Der HTTPS-Kanal ist entscheidend: Selbst wenn ein Angreifer den SMTP-Verkehr manipuliert, kann er das HTTPS-Zertifikat der Domain nicht fälschen. Die Richtlinie bleibt zuverlässig.

Einschränkung: TOFU (Trust On First Use). Beim ersten Kontakt eines Absenderservers mit Ihrer Domain hat dieser noch keine Richtlinie im Cache. Wenn ein Angreifer diese erste HTTPS-Anfrage blockiert, weiß der Absenderserver nicht, dass MTA-STS aktiviert ist. Nachfolgende Verbindungen sind dank des Caches (gültig bis max_age) geschützt.

DANE/TLSA: das Zertifikat im signierten DNS verankert

DANE funktioniert anders. Es veröffentlicht den Fingerabdruck (Hash) des TLS-Zertifikats des MX-Servers direkt in einem TLSA-Record im DNS:

_25._tcp.mx.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

Der Absenderserver:

1. Fragt das DNS nach den MX-Records von captaindns.com ab
2. Ruft den TLSA-Record des zugehörigen MX-Servers ab
3. Überprüft die DNSSEC-Signatur der Antwort (obligatorisch)
4. Vergleicht das vom MX-Server präsentierte TLS-Zertifikat mit dem TLSA-Hash
5. Wenn alles übereinstimmt, wird die Verbindung hergestellt. Andernfalls wird die E-Mail nicht gesendet

Vorteil: kein TOFU. Jede Verbindung wird einzeln über das signierte DNS überprüft. Ein Angreifer kann weder den TLSA-Record fälschen (durch DNSSEC geschützt) noch ein falsches Zertifikat präsentieren (der Hash würde nicht übereinstimmen).

Einschränkung: DNSSEC obligatorisch. Die gesamte DNS-Kette, von der Root-Zone bis zu Ihrer Zone, muss signiert sein. Wenn Ihr Registrar oder DNS-Hoster DNSSEC nicht unterstützt, ist DANE nicht nutzbar.

Detaillierter technischer Vergleich

Kriterium	MTA-STS (RFC 8461)	DANE/TLSA (RFC 7672)
Vertrauenskanal	HTTPS (Web-PKI)	DNSSEC
Schutz bei 1. Verbindung	Nein (TOFU)	Ja
DNSSEC-Abhängigkeit	Nein	Erforderlich
Zertifikatvalidierung	Hostname-Abgleich (CN/SAN)	Hash des Zertifikats (TLSA)
Nativer Testmodus	Ja (mode: testing)	Nein
Fehlerberichte	Über TLS-RPT (RFC 8460)	Über TLS-RPT (RFC 8460)
Bereitstellungskomplexität	Gering (2 DNS-Records + HTTPS-Datei)	Hoch (DNSSEC + TLSA-Records + Rotation)
Widerruf	Richtlinie ändern (Verzögerung = max_age)	TLSA-Record ändern (Verzögerung = TTL)
Absenderunterstützung	Gmail, Outlook, Yahoo, Proton Mail	Postfix, Exim, einige EU-Betreiber
Webstandard erforderlich	Ja (gültiges HTTPS-Zertifikat)	Nein

Was diese Tabelle zeigt

MTA-STS gewinnt bei der Zugänglichkeit: kein DNSSEC erforderlich, integrierter Testmodus, breite Unterstützung durch große Anbieter. Es ist das Protokoll, das die Mehrheit der Domains sofort einsetzen kann.

DANE gewinnt bei der Sicherheit: kein TOFU, direkte kryptografische Überprüfung, keine Abhängigkeit von einer Web-Zertifizierungsstelle. Aber es erfordert DNSSEC, was nach wie vor eine erhebliche Hürde darstellt.

Welches Protokoll je nach Ihrer Situation wählen?

Es gibt keine universelle Antwort. Die Wahl hängt von Ihrer DNS-Infrastruktur und Ihren Anforderungen ab.

Fall 1: Ihr Registrar unterstützt kein DNSSEC

Empfehlung: nur MTA-STS.

Das ist die häufigste Situation. Die Mehrheit der gängigen Registrare bietet kein DNSSEC an oder macht die Konfiguration schwierig. MTA-STS ist Ihre einzige Option, und sie ist effektiv: Gmail, Outlook und Yahoo prüfen und respektieren MTA-STS-Richtlinien.

Fall 2: Sie haben DNSSEC aktiviert

Empfehlung: DANE + MTA-STS.

Sie haben das Beste aus beiden Welten. DANE eliminiert TOFU für die Absenderserver, die es unterstützen (hauptsächlich Postfix im europäischen Ökosystem). MTA-STS deckt alle anderen Absender ab (Gmail, Outlook, Yahoo). Beide Protokolle koexistieren ohne Konflikte.

Fall 3: Sie nutzen Microsoft 365 oder Google Workspace

Empfehlung: MTA-STS.

Microsoft hat die DANE-Unterstützung für Exchange Online mit automatischem DNSSEC auf den neuen MX-Domains mx.microsoft angekündigt. Google Workspace unterstützt DANE auf Empfangsseite nicht. In beiden Fällen wird MTA-STS vollständig unterstützt und ist einfach zu aktivieren.

Fall 4: Sie verwalten eigene MX-Server

Empfehlung: DANE + MTA-STS wenn DNSSEC aktiv, sonst nur MTA-STS.

Mit eigenen Servern kontrollieren Sie die TLS-Zertifikate und die DNS-Records. Wenn DNSSEC auf Ihrer Zone aktiv ist, fügen Sie TLSA-Records für jeden MX-Server hinzu. Ergänzen Sie mit MTA-STS, um Absender abzudecken, die DANE nicht unterstützen.

Warum MTA-STS und DANE kombinieren?

Beide Protokolle gleichzeitig einzusetzen ist die beste Strategie, wenn Ihre Infrastruktur es erlaubt. Hier sind die Gründe:

MTA-STS gleicht die Grenzen von DANE aus:

• Absenderserver, die DANE nicht unterstützen (Gmail, Yahoo), nutzen MTA-STS
• Der Testmodus von MTA-STS ermöglicht die Validierung der Konfiguration, bevor die Verschlüsselung erzwungen wird

DANE gleicht die Grenzen von MTA-STS aus:

• Kein TOFU: Jede Verbindung wird ab der ersten Interaktion überprüft
• Keine Abhängigkeit von einer Web-Zertifizierungsstelle: Das Vertrauen kommt vom signierten DNS

Kein Konflikt: Ein Absenderserver, der beide unterstützt, prüft zuerst DANE (direkte DNS-Überprüfung), dann MTA-STS als Sicherheitsnetz. Wenn einer der beiden fehlschlägt, übernimmt der andere.

Best Practices für die Bereitstellung

Unabhängig vom gewählten Protokoll folgen Sie diesem Ablauf:

1. Beginnen Sie mit MTA-STS im Testmodus: Veröffentlichen Sie eine Richtlinie mit mode: testing. Die Absenderserver senden E-Mails normal, melden aber TLS-Fehler in den TLS-RPT-Berichten
2. Konfigurieren Sie TLS-RPT: Ohne Berichte sind Sie blind. TLS-RPT (RFC 8460) sendet Ihnen eine tägliche Zusammenfassung der TLS-Aushandlungsfehler
3. Überwachen Sie 1 bis 2 Wochen: Prüfen Sie die Berichte. Beheben Sie Zertifikat- oder MX-Konfigurationsprobleme, bevor Sie fortfahren
4. Stellen Sie MTA-STS auf Enforce um: Absenderserver verweigern nun den Klartext-Versand an Ihre MX-Server
5. Fügen Sie DANE hinzu, wenn DNSSEC aktiv ist: Veröffentlichen Sie die TLSA-Records für jeden MX-Server. Nutzen Sie den DANE/TLSA-Prüfer zur Validierung Ihrer Records

🎯 Empfohlener Aktionsplan

1. Prüfen Sie Ihre aktuelle Konfiguration: Starten Sie eine Analyse mit dem MTA-STS-Prüfer, um den Status Ihrer Domain zu ermitteln
2. Aktivieren Sie MTA-STS im Testmodus: Hosten Sie Ihre Richtlinie kostenlos mit CaptainDNS: zwei DNS-Einträge, kein Webserver zu verwalten
3. Konfigurieren Sie TLS-RPT: Fügen Sie einen DNS-Record _smtp._tls.captaindns.com hinzu, um TLS-Fehlerberichte zu empfangen
4. Stellen Sie auf Enforce um: Wenn die Berichte null Fehler bestätigen, aktivieren Sie den Enforce-Modus, um unverschlüsselte Verbindungen zu blockieren
5. Evaluieren Sie DANE: Wenn Ihr Registrar DNSSEC unterstützt, fügen Sie TLSA-Records hinzu, um TOFU zu eliminieren und die Sicherheit zu erhöhen

---

Sichern Sie den Transport Ihrer E-Mails jetzt ab: Hosten Sie Ihre MTA-STS-Richtlinie kostenlos mit CaptainDNS. Zwei DNS-Einträge, kein Webserver, aktiver Schutz in 5 Minuten.

---

FAQ

Was ist der Unterschied zwischen MTA-STS und DANE?

MTA-STS (RFC 8461) veröffentlicht eine Richtlinie zur Verschlüsselungspflicht über eine HTTPS-Datei. Es basiert auf der Web-PKI (SSL-Zertifikate) und funktioniert ohne DNSSEC. DANE (RFC 7672) verankert das TLS-Zertifikat des MX-Servers direkt im DNS über durch DNSSEC signierte TLSA-Records. MTA-STS unterliegt dem TOFU (erste Verbindung nicht geschützt), DANE nicht. Im Gegenzug erfordert DANE DNSSEC über die gesamte DNS-Kette.

Wird DNSSEC für MTA-STS benötigt?

Nein. MTA-STS basiert auf HTTPS, nicht auf DNSSEC. Das ist sein Hauptvorteil: Jede Domain mit HTTPS-Hosting kann MTA-STS aktivieren. Mit CaptainDNS müssen Sie nicht einmal einen Webserver verwalten: zwei DNS-CNAME-Einträge genügen, um Ihre Richtlinie zu veröffentlichen.

Ist DANE besser als MTA-STS?

DANE bietet in einem bestimmten Punkt überlegene Sicherheit: Es eliminiert TOFU (Trust On First Use). Jede Verbindung wird einzeln über das signierte DNS überprüft. Aber DANE ist deutlich schwieriger bereitzustellen (DNSSEC erforderlich) und wird von den großen Anbietern schlechter unterstützt (Gmail und Yahoo prüfen kein DANE). In der Praxis schützt MTA-STS dank seiner Einfachheit mehr Domains.

Können MTA-STS und DANE gleichzeitig verwendet werden?

Ja, und das wird empfohlen. Beide Protokolle koexistieren ohne Konflikte. Ein Absenderserver, der DANE unterstützt, prüft zuerst den TLSA-Record. Wenn er nur MTA-STS unterstützt, nutzt er die HTTPS-Richtlinie. So erhalten Sie maximale Abdeckung: DANE für kompatible Server, MTA-STS für alle anderen.

Was ist das TOFU-Problem bei MTA-STS?

TOFU (Trust On First Use) bedeutet, dass die erste Verbindung eines Absenderservers zu Ihrer Domain nicht durch MTA-STS geschützt ist. Der Server muss zunächst Ihre Richtlinie herunterladen und cachen. Wenn ein Angreifer diese erste HTTPS-Anfrage blockiert, weiß der Server nicht, dass MTA-STS aktiv ist. Nachfolgende Verbindungen sind durch den Cache (gültig während max_age, typischerweise 7 Tage) geschützt. DANE beseitigt dieses Problem, da die Überprüfung bei jeder Verbindung über das DNS erfolgt.

Unterstützen Google und Microsoft DANE?

Microsoft führt schrittweise DANE-Unterstützung für Exchange Online ein, mit automatischem DNSSEC auf den neuen MX-Domains. Google Gmail unterstützt DANE auf Empfangsseite nicht (keine veröffentlichten TLSA-Records), prüft und respektiert aber die DANE-Records der Empfängerdomains auf Absenderseite. Beide unterstützen MTA-STS vollständig als Absender.

Wie teste ich meine MTA-STS- oder DANE-Konfiguration?

Für MTA-STS: Prüfen Sie, ob Ihr TXT-Record _mta-sts veröffentlicht ist und Ihre Richtliniendatei über HTTPS erreichbar ist. Für DANE: Prüfen Sie, ob Ihre TLSA-Records mit dem Zertifikat Ihrer MX-Server übereinstimmen und DNSSEC über die gesamte Kette aktiv ist. CaptainDNS bietet dedizierte Prüftools für beide Protokolle.

Vergleichstabellen herunterladen

Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.

• Vergleich herunterladen (CSV)
• Vergleich herunterladen (JSON)

📖 Glossar

• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Über HTTPS veröffentlichte Richtlinie, die TLS-Verschlüsselung für den E-Mail-Empfang einer Domain erzwingt.
• DANE: DNS-Based Authentication of Named Entities (RFC 7672 für SMTP). Mechanismus, der das TLS-Zertifikat im DNS über TLSA-Records verankert, überprüft durch DNSSEC.
• TLSA: DNS-Record-Typ, der von DANE verwendet wird, um den Fingerabdruck (Hash) des TLS-Zertifikats eines Servers zu veröffentlichen.
• TOFU: Trust On First Use. Sicherheitsmodell, bei dem die erste Verbindung nicht überprüft wird, nachfolgende jedoch dank der bei der ersten Interaktion gecachten Daten validiert werden.
• DNSSEC: DNS Security Extensions. System kryptografischer Signaturen, das DNS-Antworten authentifiziert und deren Fälschung verhindert.
• STARTTLS: SMTP-Erweiterung (RFC 3207), die es ermöglicht, nach dem Aufbau einer Klartextverbindung auf Port 25 eine TLS-Verbindung auszuhandeln.
• PKI: Public Key Infrastructure. System digitaler Zertifikate, das von HTTPS (und damit MTA-STS) zur Serverauthentifizierung verwendet wird.

📚 Verwandte Leitfäden zur E-Mail-Transportsicherheit

• SMTP-Downgrade-Angriffe: Wie sie funktionieren und wie Sie sich schützen: Mechanismus des STARTTLS-Strippings und Schutzlösungen
• Von Testing zu Enforce: Schrittweise MTA-STS-Bereitstellungsstrategie: Schritt-für-Schritt-Anleitung zur schrittweisen Bereitstellung

Quellen

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE)
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol
• RFC 8460 - SMTP TLS Reporting (TLS-RPT)
• Google Transparency Report - Email encryption in transit