DANE und MTA-STS
Erzwungene SMTP-Verschlüsselung, ohne Kompromisse

SMTP entstand ohne Verschlüsselung — und das merkt man

Das SMTP-Protokoll stammt aus dem Jahr 1982. Transportverschlüsselung wurde erst 2002 mit der StartTLS-Erweiterung nachgerüstet, und zwar im opportunistischenModus: zwei Mailserver verschlüsseln die Sitzung nur, wenn beide diese Funktion ankündigen. Schlägt die Aushandlung fehl oder entfernt ein Angreifer auf dem Pfad die STARTTLS-Zeile aus der Server-Antwort, fallen die beiden MTAs unbemerkt auf Klartext zurück.

Genau das ist der Downgrade-Angriff: die Nachricht wird zugestellt, der Nutzer erhält keine Warnung, aber der Inhalt — Passwort-Resets, Rechnungen, Verträge, vertrauliche Daten — wird lesbar über das Internet übertragen. Der italienische zertifizierte E-Mail-Dienst PEC hat dasselbe Problem auf der SMTP-zu-SMTP-Strecke außerhalb des PEC-Kreises, und jeder normale Geschäfts-E-Mail-Verkehr ist betroffen.

SPF, DKIM und DMARC lösen ein anderes Problem: sie belegen, dass der Absender autorisiert ist und dass die Nachricht nicht verändert wurde. Sie verhindern nicht, dass die Nachricht im Transit gelesen wird. Erforderlich sind zusätzliche Protokolle, die Verschlüsselung verbindlich und überprüfbar machen: MTA-STS und DANE.

MTA-STS: Richtlinie über HTTPS

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) ist die praktische Antwort. Die Empfängerdomäne veröffentlicht eine Richtlinie, die sendenden Servern mitteilt: «wenn ihr mir Mail schickt, müsst ihr TLS mit einem dieser Mailserver und einem gültigen Zertifikat verwenden». Die Richtlinie besteht aus drei Komponenten:

• 1TXT-Record — _mta-sts.beispiel.dedeklariert die Policy-Version und ändert sich bei jeder Aktualisierung der Richtlinie, damit die sendenden Server wissen, wann sie die Datei neu laden müssen.
• 2Policy-Datei über HTTPS — veröffentlicht unter https://mta-sts.beispiel.de/.well-known/mta-sts.txt, listet die autorisierten Mailserver und das Enforcement-Level auf (none, testing, enforce). Die Validierung stützt sich auf die öffentliche HTTPS-PKI: kein DNSSEC erforderlich.
• 3TLS-RPT (RFC 8460)— ein dedizierter TXT-Record, der eine Reporting-Adresse angibt, an die sendende Server tägliche Berichte über TLS-bedingte Zustellfehler senden. Ohne TLS-RPT operiert man blind, und der Wechsel von MTA-STS auf enforce wird riskant.

Der Standard-Rollout sieht so aus: Start im testing-Modus, TLS-RPT-Berichte zwei oder drei Wochen sammeln, etwaige Diskrepanzen zwischen DNS-Records und Zertifikaten beheben, und erst dann auf enforce wechseln. Im enforce-Modus verweigern konforme sendende Server die Zustellung, wenn die Verschlüsselung nicht aufgebaut werden kann oder wenn das Zertifikat nicht zu einem der deklarierten Mailserver passt.

DANE für SMTP: verankert im DNS

DANE (DNS-based Authentication of Named Entities, RFC 7672 für SMTP) geht dasselbe Problem aus einem anderen Blickwinkel an. Statt die Richtlinie über HTTPS zu veröffentlichen, hinterlegt DANE einen DNS-Eintrag vom Typ TLSA, der das Zertifikat (oder dessen öffentlichen Schlüssel) direkt an den Mailservernamen bindet. Wenn ein sendender MTA eine TLS-Verbindung zum Empfänger aufbauen will, ruft er den TLSA-Record ab und prüft, ob das vorgelegte Zertifikat passt.

Der entscheidende Punkt: der TLSA-Record muss mit DNSSEC signiert sein, sonst könnte jeder zwischengeschaltete Resolver ihn manipulieren. DANE für SMTP setzt DNSSEC End-to-End auf der Empfängerdomäne und auf den Domänen ihrer Mailserver (MX-Records) voraus. Das ist die wichtigste Bremse für die Verbreitung: in Italien ist DNSSEC noch wenig verbreitet, und nicht alle Registrare unterstützen es ohne manuelle Aktivierung.

Wenn DANE einmal steht, ist es technisch robuster als MTA-STS: es stützt sich nicht auf die öffentliche HTTPS-PKI (die ihre historischen Schwachstellen hatte) und verlangt vom sendenden Server keine separate HTTPS-Anfrage zum Abruf der Richtlinie. Alles läuft auf der DNS-Ebene.

Was sich ändert: Exchange Online aktiviert ausgehendes DANE

Microsoft hat die Unterstützung für ausgehendes SMTP DANE mit DNSSEC in Exchange Online Anfang 2025 in die allgemeine Verfügbarkeitüberführt. Konkret heißt das: alle Microsoft-365-Tenants, die Mail an externe Domänen mit gültigen TLSA-Records senden, sehen die Verschlüsselung von Microsoft erzwungen und geprüft. Stimmt das Empfängerzertifikat nicht mit dem TLSA-Record überein, schlägt die Zustellung mit einem expliziten NDR fehl, statt stillschweigend auf Klartext zurückzufallen.

Die eingehendeUnterstützung (also die Möglichkeit für einen Exchange-Online-Tenant, eigene TLSA-Records für die Microsoft-Mailserver zu veröffentlichen) ist noch in der Roadmap. MTA-STS hingegen wird seit mehreren Jahren in beide Richtungen unterstützt: Microsoft-365-Tenants können ihre eigene MTA-STS-Policy veröffentlichen, und die Microsoft-Server respektieren die MTA-STS-Policies der Empfänger.

Google Workspace bietet vergleichbare MTA-STS-Unterstützung in beide Richtungen und unterstützt ausgehendes DANE. Die praktische Konsequenz: der Großteil des weltweiten E-Mail-Verkehrs respektiert heute MTA-STS und DANE auf ausgehender Seite. Eine eigene MTA-STS-Policy für die eigene Domäne zu veröffentlichen ist keine theoretische Übung mehr — es ist echter Schutz.

Sinnvoller Rollout-Pfad für Ihr Unternehmen

Für nahezu jedes Unternehmen ist die praktische Reihenfolge:

• Erstens: SPF, DKIM und DMARC— die Voraussetzung für alles Weitere. Ohne korrekt konfigurierte E-Mail-Authentifizierung lösen MTA-STS und DANE nur die Hälfte des Problems. Sie können die aktuelle Konfiguration mit unserem DIG-Online-Tool prüfen oder von unserem E-Mail-Sicherheits-Service verwalten lassen.
• Zweitens: MTA-STS mit TLS-RPT— geringe Komplexität, hoher Nutzen. Ein TXT-Record, eine HTTPS-Policy-Datei und ein TLS-RPT-Record. Start im testing-Modus für zwei bis drei Wochen, anschließend Wechsel auf enforce, sobald die Berichte sauber sind.
• Drittens: DANE bewerten— sinnvoll, wenn die Domäne bereits DNSSEC betreibt oder wenn das Unternehmen erhöhte Sicherheitsanforderungen hat (öffentliche Verwaltung, Gesundheitswesen, Finanzwesen, NIS2-Lieferkette). Für viele Domänen ist der erste Schritt die Aktivierung von DNSSEC über den eigenen DNS-Verwaltungs-Service.
• Parallel dazu: ein E-Mail Security Gateway— MTA-STS und DANE schützen den Transport, nicht den Inhalt. Phishing, BEC und bösartige Anhänge gelangen weiterhin durch verschlüsselte Verbindungen. Dafür braucht es ein E-Mail Security Gateway.

Fallstricke, die Sie vermeiden sollten

Drei wiederkehrende Fehler, die wir regelmäßig auf realen Domänen sehen:

• MTA-STS direkt im enforce-Modus veröffentlichen, ohne Testphase und ohne TLS-RPT. Folge: läuft das Zertifikat eines Mailservers ab oder rotiert es, werden eingehende E-Mails von Gmail und Microsoft 365 tagelang abgelehnt, bevor es jemandem auffällt.
• TLSA-Records ohne aktiviertes DNSSEC veröffentlichen. Der Eintrag existiert, wird von den sendenden Servern aber ignoriert, weil er nicht signiert ist. Der Schutz ist nur scheinbar.
• Den TLSA-Record bei der Zertifikatserneuerung vergessen zu aktualisieren. Verweist TLSA auf den Hash des Zertifikats und ändert sich das Zertifikat, werden TLS-Verbindungen abgelehnt. Vorab-Veröffentlichung und Rotation des neuen TLSA-Records müssen vor der Erneuerung geplant werden.

Wie AtWorkStudio das Deployment durchführt

Unser Standard-E-Mail-Stack auf den von uns verwalteten Domänen umfasst SPF, DKIM, DMARC, MTA-STS, TLS-RPT und BIMI. Für Kunden, die DANE einführen möchten, aktivieren wir zuerst DNSSEC (sofern Registrar und DNS-Anbieter es zulassen), veröffentlichen TLSA im Modus 2 1 1mit Vorab-Veröffentlichung des neuen Records vor der Zertifikatserneuerung und richten kontinuierliches Monitoring der TLS-RPT-Berichte ein.

AtWorkStudio ist seit 2000 in Piacenza, Italien, tätig. Wir sind nach ISO/IEC 27001, 27017, 27018 und ISO 9001 zertifiziert und verfügen über die ACN-Qualifizierung (Italienische Nationale Cybersicherheitsbehörde) für Cloud-Dienste. Wir sind Mitglied von Clusit (Italienischer Verband für Informationssicherheit) und Confindustria Piacenza im RICT-Cluster.

Häufig gestellte Fragen