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 Ihren TTL-Werten ab. Die TLSA-Veröffentlichung ( Enable-SmtpDaneInbound ) dauert 15 bis 30 Minuten. Rechnen Sie insgesamt mit einigen Stunden, hauptsächlich wegen der DNS-Propagation.

Von CaptainDNS
Veröffentlicht am 24. Februar 2026

Aktualisiert am 23. Mai 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: Ihre Domain muss signiert und die DS-Einträge bei Ihrem Registrar veröffentlicht sein
Die Aktivierung migriert Ihren MX von mail.protection.outlook.com zu o-v1.mx.microsoft, einer DNSSEC-signierten Domain. Microsoft veröffentlicht die TLSA-Einträge automatisch, Sie müssen sie nicht selbst verwalten
Google Workspace unterstützt kein DANE Inbound, nur DANE Outbound (Verifizierung) ist aktiv
Überprüfen Sie Ihr Deployment mit unserem DANE/TLSA-Inspektor, der DNSSEC, TLSA und die Zertifikatskette mit einem Klick testet, und kontrollieren Sie die rohe Form eines TLSA-Eintrags mit dem DANE/TLSA-Syntax-Validator

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 Ihrem Registrar und DNS-Hoster ab, nicht von Microsoft.

Diese Anleitung behandelt den gesamten Ablauf: Voraussetzungen prüfen, DNSSEC auf Ihrer 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 Ihren 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. Sie veröffentlichen die TLSA-Einträge nicht selbst. Ihre einzige Verantwortung ist die Aktivierung von DNSSEC auf Ihrer 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üfen Sie den aktuellen Status:

dig +dnssec captaindns.com SOA +short

Wenn die Antwort ein ad-Flag (Authenticated Data) im Header enthält, ist Ihre Domain signiert. Andernfalls müssen Sie 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 Ihr Registrar DNSSEC nicht unterstützt, müssen Sie Ihren DNS zu einem kompatiblen Anbieter migrieren, bevor Sie DANE aktivieren können.

MX zeigt auf Exchange Online

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

dig MX captaindns.com +short

Das Ergebnis sollte etwa so aussehen:

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

Bei der DANE-Aktivierung fordert Microsoft Sie 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 Ihre 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 Ihrer Domain aktivieren

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

Wenn Ihr DNS bei Cloudflare ist

Melden Sie sich im Cloudflare-Dashboard an
Wählen Sie Ihre Domain aus
Gehen Sie zu DNS → DNSSEC
Klicken Sie auf Enable DNSSEC
Cloudflare zeigt die DS-Informationen an, die Sie bei Ihrem Registrar veröffentlichen müssen
Wenn Cloudflare auch Ihr Registrar ist, erfolgt dies automatisch

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

dig +dnssec captaindns.com DNSKEY +short

Wenn Ihr DNS bei einem anderen Anbieter ist

Der Prozess besteht aus zwei Schritten:

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

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

DANE für Exchange Online aktivieren

Anleitung in 4 Schritten zur Bereitstellung von DANE auf Microsoft 365

Schritt 1: DNSSEC auf der Domain aktivieren
Aktivieren Sie die DNSSEC-Signierung bei Ihrem DNS-Hoster und veröffentlichen Sie den DS-Eintrag bei Ihrem Registrar. Überprüfen Sie mit dig +dnssec captaindns.com SOA, ob das ad-Flag in der Antwort erscheint. Rechnen Sie mit 24 bis 48 Stunden für die vollständige DS-Propagation.
Schritt 2: DNSSEC in Exchange Online aktivieren und MX migrieren
Senken Sie die TTL Ihres aktuellen MX auf das Minimum (nicht unter 30 Sekunden) und warten Sie, bis die alte TTL abgelaufen ist. Führen Sie 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ügen Sie diesen neuen MX mit Priorität 20 hinzu, überprüfen Sie, ob er funktioniert, setzen Sie ihn dann auf Priorität 0 und entfernen Sie den alten MX mail.protection.outlook.com.
Schritt 3: DANE aktivieren (TLSA-Veröffentlichung)
Sobald der MX migriert und funktionsfähig ist, führen Sie 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.
Schritt 4: DANE-Deployment verifizieren
Verwenden Sie dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft, um die Präsenz des TLSA zu bestätigen. Testen Sie die TLS-Verbindung mit openssl s_client -starttls smtp -connect captaindns-com.o-v1.mx.microsoft:25. Validieren Sie 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 Ihren 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 Sie MTA-STS verwenden, setzen Sie die Richtlinie auf den Modus testing und fügen Sie den neuen Hostnamen in die Richtliniendatei ein, bevor Sie die Migration durchführen. Stellen Sie 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 Ihrer 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üfen Sie Ihren 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: rechnen Sie 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üfen Sie, 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 Ihrer 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 Ihrem Registrar stimmt nicht mit dem KSK-Schlüssel Ihrer Zone überein.

Lösung: Überprüfen Sie die Übereinstimmung zwischen dem veröffentlichten DS und dem KSK-Schlüssel mit dig DNSKEY captaindns.com +short und vergleichen Sie mit dem DS bei Ihrem Registrar. Generieren Sie 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üfen Sie, ob Ihr MX auf *.o-v1.mx.microsoft zeigt und der alte mail.protection.outlook.com entfernt ist. Prüfen Sie den Status mit Get-DnssecStatusForVerifiedDomain. Wenn der Status DnssecValidationFailed ist, korrigieren Sie Ihre DNSSEC-Konfiguration, bevor Sie es erneut versuchen.

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: Folgen Sie der vollständigen MX-Migrationsprozedur. Der neue MX muss Priorität 0 haben und der alte muss entfernt sein, bevor Sie Enable-SmtpDaneInbound ausführen.

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 Ihr Relay kein DANE unterstützt, müssen Sie sich zwischen dem Drittanbieter-Filtering und DANE entscheiden. Einige Relays beginnen 2025-2026 mit der DANE-Unterstützung, prüfen Sie bei Ihrem Anbieter nach.

E-Mails werden von strikten Servern abgelehnt

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

Lösung: Verwenden Sie die Troubleshooting-Methodik aus unserer DANE/TLSA-Fehlerbehebungsanleitung (Link am Seitenende), um den genauen Fehler zu diagnostizieren. Prüfen Sie 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 Sie Google Workspace nutzen und DANE Inbound möchten, 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:

Sie verwalten 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)
Sie müssen 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:

Aktivieren Sie DANE (diese Anleitung)
Veröffentlichen Sie eine MTA-STS-Richtlinie mit unserem MTA-STS-Generator
Aktivieren Sie 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 Ihren 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. Ihre Verantwortung ist es, DNSSEC auf Ihrer 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 Ihren TTL-Werten ab. Die TLSA-Veröffentlichung (Enable-SmtpDaneInbound) dauert 15 bis 30 Minuten. Rechnen Sie 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 Ihrer 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 Ihre 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.