DANE für Exchange Online und Microsoft 365 bereitstellen

Q: Wie lange dauert die Aktivierung von DANE auf Exchange Online?

Die Aktivierung erfolgt in zwei Phasen. Die MX-Migration ( Enable-DnssecForVerifiedDomain ) dauert wenige Minuten, aber die DNS-Propagation hängt von deinen TTL-Werten ab. Die TLSA-Veröffentlichung ( Enable-SmtpDaneInbound ) dauert 15 bis 30 Minuten. Rechne insgesamt mit einigen Stunden, hauptsächlich wegen der DNS-Propagation.

Von CaptainDNS
Veröffentlicht am 24. Februar 2026

Schema des DANE-Flusses zwischen einem SMTP-Absender und Exchange Online mit DNSSEC und TLSA

TL;DR

Microsoft 365 unterstützt DANE Inbound (SMTP) seit März 2024 für Exchange Online, mit automatischer Veröffentlichung der TLSA-Einträge
Die wichtigste Voraussetzung ist DNSSEC: deine Domain muss signiert und die DS-Einträge bei deinem Registrar veröffentlicht sein
Die Aktivierung migriert deinen MX von mail.protection.outlook.com zu o-v1.mx.microsoft, einer DNSSEC-signierten Domain. Microsoft veröffentlicht die TLSA-Einträge automatisch, du musst sie nicht selbst verwalten
Google Workspace unterstützt kein DANE Inbound, nur DANE Outbound (Verifizierung) ist aktiv
Überprüfe dein Deployment mit unserem DANE/TLSA-Inspektor, der DNSSEC, TLSA und die Zertifikatskette mit einem Klick testet

Microsoft hat die allgemeine Verfügbarkeit von DANE Inbound für Exchange Online im März 2024 angekündigt. Konkret können Domains, die auf Microsoft 365 gehostet sind, jetzt durch DANE geschützte E-Mails empfangen: Absender-Server, die DANE/TLSA prüfen, validieren das TLS-Zertifikat von Exchange Online über signiertes DNS, anstatt blind den Zertifizierungsstellen zu vertrauen.

DANE auf Microsoft 365 zu aktivieren, ist aber kein einfacher Klick. Die grundlegende Voraussetzung ist DNSSEC: ohne signierte DNS-Zone haben die von Microsoft veröffentlichten TLSA-Einträge keinen Wert. Und die DNSSEC-Konfiguration hängt von deinem Registrar und DNS-Hoster ab, nicht von Microsoft.

Diese Anleitung behandelt den gesamten Ablauf: Voraussetzungen prüfen, DNSSEC auf deiner Domain aktivieren, DANE in Exchange Online aktivieren und das Deployment End-to-End validieren. Außerdem vergleicht sie die Unterschiede zu Google Workspace (das kein DANE Inbound unterstützt) und On-Premise-Servern wie Postfix oder Exchange Server.

Zielgruppe: Microsoft 365-Administratoren, IT-Manager in Unternehmen, MSPs, die M365-Tenants verwalten. Für die Grundlagen von DANE und TLSA siehe den ersten Artikel dieser Serie (Link am Seitenende).

Wie funktioniert DANE mit Exchange Online?

Wenn ein Absender-Server eine E-Mail an eine auf Exchange Online gehostete und durch DANE geschützte Domain sendet:

MX-Auflösung: Der Server löst den MX von captaindns.com auf und erhält captaindns-com.o-v1.mx.microsoft (das neue MX-Format für DANE-Domains)
DNSSEC-Verifizierung: Er prüft, ob die DNS-Antwort DNSSEC-signiert ist. Die Vertrauenskette läuft über root → .microsoft → mx.microsoft → o-v1.mx.microsoft, vollständig signiert
TLSA-Abfrage: Er fragt den TLSA-Eintrag bei _25._tcp.captaindns-com.o-v1.mx.microsoft ab
TLS-Verbindung: Er verbindet sich per STARTTLS auf Port 25 und vergleicht das von Exchange Online präsentierte Zertifikat mit dem TLSA-Hash
Zustellung: Wenn alles übereinstimmt, wird die E-Mail zugestellt. Andernfalls wird sie je nach Richtlinie des Absender-Servers abgelehnt oder verzögert

Ein wichtiger Punkt: outlook.com ist nicht DNSSEC-signiert. Deshalb hat Microsoft die Infrastruktur mx.microsoft unter der TLD .microsoft aufgebaut, die durchgängig DNSSEC-signiert ist. Die Aktivierung von DANE migriert deinen MX automatisch vom alten Format mail.protection.outlook.com zum neuen o-v1.mx.microsoft.

Der wesentliche Unterschied zu einem selbst gehosteten Server (Postfix, Exchange Server On-Premise): Microsoft verwaltet die MX-Migration, die TLSA-Einträge und die TLS-Zertifikate. Du veröffentlichst die TLSA-Einträge nicht selbst. Deine einzige Verantwortung ist die Aktivierung von DNSSEC auf deiner Domain.

DANE-Fluss zwischen einem Absender-Server und Exchange Online

Voraussetzungen vor der DANE-Aktivierung

Domain mit aktivem DNSSEC

DANE basiert vollständig auf DNSSEC. Ohne gültige DNS-Signaturen werden TLSA-Einträge von den Absender-Servern ignoriert. Prüfe den aktuellen Status:

dig +dnssec captaindns.com SOA +short

Wenn die Antwort ein ad-Flag (Authenticated Data) im Header enthält, ist deine Domain signiert. Andernfalls musst du DNSSEC aktivieren.

DNSSEC-kompatibler Registrar

Nicht alle Registrare unterstützen DNSSEC auf die gleiche Weise:

Registrar	DNSSEC	Methode
Cloudflare	Automatisch	Ein Klick im Dashboard, DS wird automatisch veröffentlicht
OVH	Unterstützt	Manuelle Aktivierung, DS muss beim Registrant veröffentlicht werden
Gandi	Unterstützt	KSK-Schlüssel angeben, DS wird automatisch veröffentlicht
GoDaddy	Unterstützt	Manuelle Aktivierung in den erweiterten DNS-Einstellungen
Route 53 (AWS)	Unterstützt	Erstellung der KSK/ZSK-Kette, DS muss manuell veröffentlicht werden

Wenn dein Registrar DNSSEC nicht unterstützt, musst du deinen DNS zu einem kompatiblen Anbieter migrieren, bevor du DANE aktivieren kannst.

MX zeigt auf Exchange Online

Vor der DANE-Aktivierung zeigen deine MX-Einträge auf *.mail.protection.outlook.com. Überprüfe:

dig MX captaindns.com +short

Das Ergebnis sollte etwa so aussehen:

0 captaindns-com.mail.protection.outlook.com.

Bei der DANE-Aktivierung fordert Microsoft dich auf, diesen MX auf ein neues Format zu migrieren: captaindns-com.o-v1.mx.microsoft. Diese neue Domain ist unter der TLD .microsoft gehostet, die durchgängig DNSSEC-signiert ist. Da das alte outlook.com nicht DNSSEC-signiert ist, wäre die Vertrauenskette ohne diese Migration unmöglich.

Wenn deine MX-Einträge über ein Drittanbieter-Relay laufen (Proofpoint, Mimecast, Barracuda), schützt DANE nur den letzten Hop zu Exchange Online. Das Relay selbst muss ebenfalls DANE unterstützen, um einen End-to-End-Schutz zu gewährleisten.

DNSSEC auf deiner Domain aktivieren

Das Verfahren variiert je nach DNS-Hoster. Hier die allgemeinen Schritte.

Wenn dein DNS bei Cloudflare ist

Melde dich im Cloudflare-Dashboard an
Wähle deine Domain aus
Gehe zu DNS → DNSSEC
Klicke auf Enable DNSSEC
Cloudflare zeigt die DS-Informationen an, die du bei deinem Registrar veröffentlichen musst
Wenn Cloudflare auch dein Registrar ist, erfolgt dies automatisch

Cloudflare signiert die Zone und veröffentlicht den DS innerhalb weniger Minuten. Überprüfe anschließend:

dig +dnssec captaindns.com DNSKEY +short

Wenn dein DNS bei einem anderen Anbieter ist

Der Prozess besteht aus zwei Schritten:

Zonensignierung aktivieren bei deinem DNS-Hoster (Generierung der KSK/ZSK-Schlüssel, automatische Signierung)
DS-Eintrag veröffentlichen bei deinem Registrar (der DS-Eintrag verbindet deine signierte Zone mit der übergeordneten Zone)

Der DS muss exakt mit dem KSK-Schlüssel deiner Zone übereinstimmen. Ein Fehler im DS bricht die DNS-Auflösung deiner Domain. Teste immer zuerst in einer Staging-Umgebung oder mit einer Subdomain.

Anleitung in 4 Schritten zur Bereitstellung von DANE auf Microsoft 365

Aktiviere die DNSSEC-Signierung bei deinem DNS-Hoster und veröffentliche den DS-Eintrag bei deinem Registrar. Überprüfe mit dig +dnssec captaindns.com SOA, ob das ad-Flag in der Antwort erscheint. Rechne mit 24 bis 48 Stunden für die vollständige DS-Propagation.
Senke die TTL deines aktuellen MX auf das Minimum (nicht unter 30 Sekunden) und warte, bis die alte TTL abgelaufen ist. Führe Enable-DnssecForVerifiedDomain -DomainName captaindns.com in Exchange Online PowerShell aus. Der Befehl gibt den neuen MX-Wert zurück: captaindns-com.o-v1.mx.microsoft. Füge diesen neuen MX mit Priorität 20 hinzu, überprüfe, ob er funktioniert, setze ihn dann auf Priorität 0 und entferne den alten MX mail.protection.outlook.com.
Sobald der MX migriert und funktionsfähig ist, führe Enable-SmtpDaneInbound -DomainName captaindns.com aus. Microsoft generiert und veröffentlicht automatisch die TLSA-Einträge unter _25._tcp.captaindns-com.o-v1.mx.microsoft. Die Propagation dauert 15 bis 30 Minuten.
Verwende dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft, um die Präsenz des TLSA zu bestätigen. Teste die TLS-Verbindung mit openssl s_client -starttls smtp -connect captaindns-com.o-v1.mx.microsoft:25. Validiere alles mit dem DANE/TLSA-Prüftool von CaptainDNS.

DANE in Exchange Online aktivieren

Die Aktivierung erfolgt in zwei getrennten Phasen: zuerst die DNSSEC-Migration (neuer MX), dann die DANE-Aktivierung (TLSA-Veröffentlichung). Die Verwaltung erfolgt über Exchange Online PowerShell.

Phase 1: MX-Migration zu mx.microsoft

Diese erste Phase aktiviert DNSSEC und migriert deinen MX zur mx.microsoft-Infrastruktur, die DNSSEC-signiert ist.

# Verbindung zu Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@captaindns.com

# DNSSEC für die Domain aktivieren
Enable-DnssecForVerifiedDomain -DomainName captaindns.com

Der Befehl gibt den neuen MX-Wert zurück:

Result	DnssecMxValue
`Success`	`captaindns-com.o-v1.mx.microsoft`

MX-Migrationsprozedur:

TTL senken des aktuellen MX auf das Minimum (nicht unter 30 Sekunden)
Warten, bis die alte TTL abgelaufen ist
Neuen MX hinzufügen: captaindns-com.o-v1.mx.microsoft mit Priorität 20
Überprüfen, ob der neue MX E-Mails korrekt empfängt
Prioritäten tauschen: neuer MX auf 0, alter auf 30
Alten MX entfernen: captaindns-com.mail.protection.outlook.com
TTL erhöhen des neuen MX auf 3600 Sekunden

Wenn du MTA-STS verwendest, setze die Richtlinie auf den Modus testing und füge den neuen Hostnamen in die Richtliniendatei ein, bevor du die Migration durchführst. Stelle den Modus enforce nach Abschluss wieder her.

Phase 2: DANE-Aktivierung (TLSA-Veröffentlichung)

Sobald der MX migriert und funktionsfähig ist:

# DANE aktivieren (TLSA-Veröffentlichung)
Enable-SmtpDaneInbound -DomainName captaindns.com

# Vollständigen Status prüfen
Get-DnssecStatusForVerifiedDomain -DomainName captaindns.com

Der Status durchläuft mehrere Phasen:

Status	Bedeutung
`DnssecFeatureNotEnabled`	DNSSEC nicht aktiviert
`DnssecValidationPending`	Microsoft prüft DNSSEC auf deiner Domain
`DnssecEnabled`	DNSSEC validiert, MX migriert, TLSA noch nicht veröffentlicht
`DaneEnabled`	DANE aktiv, TLSA veröffentlicht und funktionsfähig
`DnssecValidationFailed`	DNSSEC-Validierung fehlgeschlagen, prüfe deinen DS

Zeitrahmen

MX-Migration: wenige Minuten für den Befehl, dann die Zeit für die DNS-Propagation (variiert je nach TTL)
TLSA-Veröffentlichung: 15 bis 30 Minuten nach Enable-SmtpDaneInbound
End-to-End: rechne mit einigen Stunden, hauptsächlich wegen der DNS-Propagation

Deployment verifizieren

TLSA mit dig prüfen

dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft +short

Erwartetes Ergebnis:

3 1 1 A4B5C6D7E8F9...  (SHA-256-Hash des Exchange Online-Zertifikats)

Microsoft veröffentlicht mehrere TLSA-Einträge 3 1 1 (DANE-EE, SPKI, SHA-256) und 3 1 2 (DANE-EE, SPKI, SHA-512) für Redundanz. Es ist normal, dass einige nicht mit dem aktuellen Zertifikat übereinstimmen: ein einziger Treffer genügt, um DANE zu validieren.

TLS-Verbindung prüfen

openssl s_client -starttls smtp \
  -connect captaindns-com.o-v1.mx.microsoft:25 \
  -servername captaindns-com.o-v1.mx.microsoft

Überprüfe, ob das präsentierte Zertifikat mit einem der veröffentlichten TLSA-Hashes übereinstimmt.

Mit CaptainDNS prüfen

Der im TL;DR erwähnte DANE/TLSA-Inspektor testet automatisch:

Vorhandensein und Gültigkeit von DNSSEC auf deiner Domain
MX-Auflösung zu o-v1.mx.microsoft
Vorhandensein der TLSA-Einträge unter der signierten Zone
Übereinstimmung zwischen TLSA und TLS-Zertifikat

DANE-Kompatibilitätsmatrix nach E-Mail-Anbieter

Häufige Fehler und Lösungen

DNSSEC validation failed

Ursache: Der DS-Eintrag bei deinem Registrar stimmt nicht mit dem KSK-Schlüssel deiner Zone überein.

Lösung: Überprüfe die Übereinstimmung zwischen dem veröffentlichten DS und dem KSK-Schlüssel mit dig DNSKEY captaindns.com +short und vergleiche mit dem DS bei deinem Registrar. Generiere den DS bei Bedarf neu.

TLSA nach Aktivierung nicht veröffentlicht

Ursache: Der MX wurde nicht zu o-v1.mx.microsoft migriert, Microsoft konnte DNSSEC nicht validieren, oder die Propagation läuft noch.

Lösung: Überprüfe, ob dein MX auf *.o-v1.mx.microsoft zeigt und der alte mail.protection.outlook.com entfernt ist. Prüfe den Status mit Get-DnssecStatusForVerifiedDomain. Wenn der Status DnssecValidationFailed ist, korrigiere deine DNSSEC-Konfiguration, bevor du es erneut versuchst.

Alter MX nicht entfernt

Ursache: Der alte MX mail.protection.outlook.com existiert neben dem neuen o-v1.mx.microsoft, was die korrekte Funktion von DANE verhindert.

Lösung: Folge der vollständigen MX-Migrationsprozedur. Der neue MX muss Priorität 0 haben und der alte muss entfernt sein, bevor du Enable-SmtpDaneInbound ausführst.

Drittanbieter-Relay blockiert DANE

Ursache: Ein Filterdienst (Proofpoint, Mimecast) fängt die MX-Einträge ab und unterstützt kein DANE.

Lösung: DANE schützt nur den letzten SMTP-Hop. Wenn dein Relay kein DANE unterstützt, musst du dich zwischen dem Drittanbieter-Filtering und DANE entscheiden. Einige Relays beginnen 2025-2026 mit der DANE-Unterstützung, prüfe bei deinem Anbieter nach.

E-Mails werden von strikten Servern abgelehnt

Ursache: Dein DANE ist falsch konfiguriert und Absender-Server, die eine strikte DANE-Richtlinie anwenden, lehnen Nachrichten ab.

Lösung: Verwende die Troubleshooting-Methodik aus unserer DANE/TLSA-Fehlerbehebungsanleitung (Link am Seitenende), um den genauen Fehler zu diagnostizieren. Prüfe vorrangig die DNSSEC-Kette und die Übereinstimmung TLSA/Zertifikat.

Microsoft 365 vs. Google Workspace vs. On-Premise

Funktion	Microsoft 365	Google Workspace	On-Premise (Postfix)
DANE Inbound	Ja (seit März 2024)	Nein	Ja (nativ)
DANE Outbound	Ja	Ja	Ja (nativ)
MX-Migration	Ja (`o-v1.mx.microsoft`)	N/A	Nein (MX unverändert)
TLSA-Verwaltung	Automatisch (Microsoft)	N/A	Manuell
Zertifikatsverwaltung	Automatisch (Microsoft)	N/A	Manuell (Let's Encrypt, etc.)
Voraussetzungen	DNSSEC + MX-Migration	-	DNSSEC + TLSA + Zertifikat
Komplexität	Mittel (DNSSEC + Migration)	N/A	Hoch (alles selbst verwalten)
Zertifikatsrotation	Transparent	N/A	Deploy-Hook erforderlich

Google Workspace

Google unterstützt DANE Outbound (Prüfung der TLSA-Einträge der Empfänger) seit 2023, aber kein DANE Inbound. Domains, die auf Google Workspace gehostet sind, können keine TLSA-Einträge über Google veröffentlichen. Wenn du Google Workspace nutzt und DANE Inbound möchtest, gibt es derzeit keine Lösung.

Exchange Server On-Premise

Für einen On-Premise Exchange Server (2016, 2019) funktioniert DANE wie bei jedem selbst gehosteten SMTP-Server:

Du verwaltest DNSSEC, die TLSA-Einträge und die Zertifikate selbst
Die Konfiguration ist ähnlich wie bei Postfix (siehe unser Postfix/Bind/Let's Encrypt-Tutorial in den verwandten Anleitungen)
Du musst die TLSA-Rotation bei der Zertifikatserneuerung automatisieren

DANE mit MTA-STS und TLS-RPT ergänzen

DANE und MTA-STS ergänzen sich, sie sind keine Konkurrenten:

DANE verifiziert das Zertifikat über DNS/DNSSEC (stark, erfordert aber DNSSEC)
MTA-STS erzwingt TLS über eine HTTPS-Richtlinie (einfacher, abhängig von CAs)
TLS-RPT meldet TLS- und DANE-Fehler per täglicher E-Mail

Microsoft 365 unterstützt alle drei Protokolle. Für maximale E-Mail-Sicherheit:

Aktiviere DANE (diese Anleitung)
Veröffentliche eine MTA-STS-Richtlinie mit unserem MTA-STS-Generator
Aktiviere TLS-RPT, um Fehlerberichte zu erhalten

FAQ

Unterstützt Microsoft 365 DANE?

Ja. Microsoft hat den Support für DANE Inbound für Exchange Online im März 2024 als allgemein verfügbar eingeführt. Die Aktivierung migriert deinen MX von mail.protection.outlook.com zu o-v1.mx.microsoft, einer Domain unter der TLD .microsoft, die DNSSEC-signiert ist. Microsoft veröffentlicht anschließend automatisch die TLSA-Einträge.

Muss man die TLSA-Einträge bei Microsoft 365 manuell veröffentlichen?

Nein. Im Gegensatz zu einem selbst gehosteten Server verwaltet Microsoft die Veröffentlichung und Rotation der TLSA-Einträge unter der Zone o-v1.mx.microsoft automatisch. Deine Verantwortung ist es, DNSSEC auf deiner Domain zu aktivieren und den MX auf das neue Format zu migrieren.

Unterstützt Google Workspace DANE Inbound?

Nein. Google Workspace unterstützt nur DANE Outbound (Prüfung der TLSA-Einträge der Empfänger). Es gibt keine Möglichkeit, DANE Inbound für auf Google Workspace gehostete Domains zu aktivieren.

Wie lange dauert die Aktivierung von DANE auf Exchange Online?

Die Aktivierung erfolgt in zwei Phasen. Die MX-Migration (Enable-DnssecForVerifiedDomain) dauert wenige Minuten, aber die DNS-Propagation hängt von deinen TTL-Werten ab. Die TLSA-Veröffentlichung (Enable-SmtpDaneInbound) dauert 15 bis 30 Minuten. Rechne insgesamt mit einigen Stunden, hauptsächlich wegen der DNS-Propagation.

Was passiert, wenn DNSSEC auf meiner Domain ausfällt?

Wenn DNSSEC fehlschlägt (abgelaufene Signatur, falscher DS), wird die DNS-Auflösung deiner Domain beeinträchtigt. DANE-fähige Server können die TLSA-Einträge nicht mehr validieren und werden E-Mails ablehnen oder verzögern. Deshalb ist DNSSEC-Monitoring kritisch.

Funktioniert DANE mit einem Drittanbieter-Relay (Proofpoint, Mimecast)?

Teilweise. DANE schützt nur den letzten SMTP-Hop. Wenn deine MX-Einträge auf ein Drittanbieter-Relay zeigen, das dann an Exchange Online weiterleitet, schützt DANE nur den Hop Relay → Exchange. Der Hop Absender → Relay ist nicht abgedeckt, es sei denn, das Relay unterstützt ebenfalls DANE.

Kann man DANE und MTA-STS gleichzeitig verwenden?

Ja, und es wird empfohlen. DANE verifiziert das Zertifikat über DNS/DNSSEC, MTA-STS erzwingt TLS über HTTPS. Die beiden Protokolle ergänzen sich. Microsoft 365 unterstützt beide gleichzeitig.