Aktivierung von SMTP DANE in Exchange Online und was dabei zu beachten ist

Das Simple Mail Transfer Protocol (SMTP) ist seit Jahrzehnten das Rückgrat der E-Mail-Kommunikation. Seine Einfachheit war ein Vorteil in der frühen Internetzeit, heute stellt sie eine Schwachstelle dar. Standard-SMTP überträgt E-Mails unverschlüsselt. Zwar kann durch TLS (Transport Layer Security) eine verschlüsselte Übertragung etabliert werden, jedoch erfolgt dies in der Praxis meist opportunistisch (auch in Exchange Online): Der Versandserver versucht eine TLS-Verbindung aufzubauen. Gelingt das nicht, wird oft dennoch per Klartext versendet.

Diese Nachgiebigkeit gegenüber TLS-Nichtverfügbarkeit öffnet Downgrade-Angriffen Tür und Tor: Ein Angreifer in der Netzwerkmitte (Man-in-the-Middle) kann STARTTLS-Anfragen abfangen oder manipulieren, um so die TLS-Negotiation zu unterbinden. Die Folge: E-Mails werden im Klartext übertragen, obwohl Sender und Empfänger eigentlich TLS unterstützen.

DANE als Lösung: Authentifizierte TLS-Verbindungen über DNS

DANE (DNS-based Authentication of Named Entities) wurde als Antwort auf diese Problematik entwickelt. Der RFC 7672 definiert, wie DANE im Kontext von SMTP verwendet wird. Die Idee dabei ist, der Empfänger signalisiert über DNSSEC-validierte TLSA-Records, dass er TLS erwartet und zwar inklusive der Anforderungen an das Serverzertifikat. Damit wird:

• Der TLS-Einsatz verbindlich,
• die Echtheit des Zielservers verifiziert, und
• die Möglichkeit für Downgrade- und MITM-Angriffe eliminiert.

DANE hängt dabei direkt von DNSSEC (Domain Name System Security Extensions) ab, da nur DNS-Einträge mit kryptografischer Signatur als vertrauenswürdig gelten. DNSSEC schützt DNS-Antworten durch kryptografische Signaturen, sodass der Absender einer E-Mail sicher sein kann, dass die erhaltenen DNS-Einträge (MX, A, TLSA) echt und nicht manipuliert sind.

Funktionsweise von DANE für SMTP (nach RFC 7672)

Die Validierung erfolgt in mehreren Schritten:

1. Der sendende Mailserver ermittelt den MX-Record der Empfänger-Domain via DNS.
2. Der zugehörige MX-Host wird auf A/AAAA-Records und TLSA-Records geprüft.
3. DNSSEC stellt sicher, dass diese DNS-Antworten nicht manipuliert wurden.
4. Existiert ein gültiger TLSA-Record, beginnt der Verbindungsaufbau:
   1. Der sendende Server stellt eine TLS-Verbindung her,
   2. prüft das Zertifikat des Empfängers anhand des TLSA-Records,
   3. und überträgt die Nachricht nur, wenn die Prüfung erfolgreich ist.

Ein TLSA-Record beschreibt, welcher Teil eines Zertifikats (z. B. der SPKI-Hash) und wie genau (z. B. via SHA-256) geprüft werden soll. Die gängige DANE-Konfiguration für SMTP (RFC-konform) verwendet:

• Zertifikatverwendung: 3 (DANE-EE – End Entity)
• Selector: 1 (SPKI – Public Key Info)
• Match Type: 1 (SHA-256)

So werden Zertifikatsdetails gezielt auf ihre Übereinstimmung mit dem DNS-Eintrag unabhängig von öffentlichen CAs geprüft.

Einführung der Unterstützung von SMTP DANE in Exchange Online

Microsoft hat die Einführung von DANE in Exchange Online in zwei Phasen strukturiert (Releasing: Outbound SMTP DANE with DNSSEC). Exchange Online hostet dabei die TLSA-Records:

• Outbound DANE mit DNSSEC: Bereits seit März 2022 aktiv und standardmäßig für alle Kunden im Einsatz. Ausgehende Mails von Exchange Online werden mit DANE validiert, wenn die Empfängerdomäne korrekt konfiguriert ist.
• Inbound DANE mit DNSSEC: Seit Juni 2024 allgemein verfügbar. Exchange Online kann nun TLSA-Einträge veröffentlichen und eingehende Mails über DANE absichern. Vorausgesetzt die Empfängerdomäne entsprechend eingerichtet ist.

Struktur eines TLSA-Records erklärt

Ein TLSA-Record ist ein spezieller DNS-Ressourceneintrag (Typ 52), der dem MX-Zielhost zugeordnet ist und etwa wie folgt aussieht:

_25._tcp.mx.example.com. IN TLSA 3 1 1 abc123...xyz789

Die Felder bedeuten:

• 3: DANE-EE -> das Zertifikat muss exakt mit dem TLS-Zertifikat des Servers übereinstimmen
• 1: SPKI -> geprüft wird der öffentliche Schlüssel
• 1: SHA-256 -> Hash-Algorithmus für den Vergleich

Die Angaben im TLSA-Datensatz müssen mit dem Zertifikat des Mailservers übereinstimmen. Wenn sie das nicht tun, wird die Verbindung abgelehnt oder zurückgestellt.

Aktivierung von Inbound DANE in Exchange Online

1. Prüfen, ob die Domain DNSSEC unterstützt
   Dafür stehen unter anderem die Tools Verisign DNSSEC Debugger oder Microsoft Remote Connectivity Analyzer zur Verfügung.
   
   Alle DNS-Antworten (MX, A, TLSA) müssen DNSSEC-validiert sein.
   

1. TTL des bestehenden MX-Eintrags reduzieren
   Setzen Sie den TTL-Wert auf das Minimum (z. B. 60 Sekunden), um schnelle Umstellung zu ermöglichen.
2. DNSSEC in Exchange Online aktivieren

Enable-DnssecForVerifiedDomain -DomainName <domain.tld>

4. Neuen MX-Eintrag in der DNS-Zone veröffentlichen
   In der öffentlichen DNS-Zone den neuen MX-Record eintragen. Dabei sollte die Priorität zunächst höher als der alte Eintrag (z. B. 20) sein.
5. DNSSEC Funktionstest / Validierung durchführen
   Mit dem Microsoft Remote Connectivity Analyzer den "Eingehende SMTP-E-Mail"-Test durchführen und das Ergebniss sichten.

1. Legacy-MX Record entfernen
   Entfernen Sie nun den alte MX-Eintrag aus der DNS-Zone (z. B. domain-tld.mail.protection.outlook.com) und setzen Sie den neuen MX auf die Priorität die der Legacy-MX zuvor hatte.
2. DANE aktivieren
   Durch Ausführung dieses PowerShell-Befehls wird Exchange Online automatisch die TLSA-Einträge in der DNS-Zone von Microsoft erstellen. Die DNS-Propagation kann bis zu 30 Minuten dauern.

Enable-SmtpDaneInbound -DomainName <domain.tld>

1. DANE Funktionstest / Validierung durchführen
   Mit dem Remote Connectivity Analyzer Test "DNSSEC- und DANE-Validierungstest" können Sie nun überprüfen, ob die Änderungen erfolgreich gewesen sind.