DNS-Sicherheit für Microsoft 365 — DNSSEC, DANE & CAA
Microsoft 365 (Exchange Online) ist Mail-Hoster, nicht DNS-Hoster — DNSSEC, DANE TLSA und CAA müssen beim externen DNS-Provider (Cloudflare, IONOS, Hetzner, deSEC) aktiviert werden, der die Zone hostet. Diese Anleitung zeigt die NIS2-konforme Absicherung mit konkreten dig-Befehlen und CAA-Records.
DNS-Sicherheit für Microsoft 365 Custom Domains
Microsoft 365 stellt Exchange Online als Mail-Backend bereit, aber das DNS-Hosting für Ihre Custom-Domain läuft beim externen DNS-Provider Ihrer Wahl. DNSSEC, DANE TLSA-Records und CAA-Records werden daher dort konfiguriert — nicht im Microsoft-365-Admin-Center. Die Microsoft-Dokumentation (learn.microsoft.com, Abruf 2026-05-16) beschreibt die Pflicht-DNS-Records (MX, SPF, DKIM, CNAME, SRV), erwähnt DNSSEC jedoch nicht explizit als Empfehlung — die DNSSEC-Aktivierung ist Best Practice nach RFC 4033 und NIS2 Art. 21 Abs. 2 lit. h, nicht Microsoft-Mandat.
DANE-TLSA-Status: Microsoft 365 veröffentlicht für seine MX-Hostnamen unter <tenant>.mail.protection.outlook.com nach Stand 2026 typischerweise keine TLSA-Records — DANE-EE (RFC 7672 Usage 3) wird damit für eingehenden Mail-Traffic nicht angeboten. Microsoft empfiehlt stattdessen MTA-STS als TLS-Erzwingungs-Mechanismus für Exchange-Online-Domains. Den TLSA-Status bei Ihrer Microsoft-365-Domain prüfen Sie mit dem nachfolgenden dig-Befehl direkt.
Hardening-Pfad: MX-Record → SPF → DKIM → DMARC → MTA-STS → DNSSEC + CAA (dieser Guide). Bedrohungs-Cluster: Ein DNSSEC-gesicherter MX-Record schützt vor DNS-Hijacking-Spoofing; CAA-Records auf mta-sts-Subdomain verhindern SubdoMailing-Übernahmen über fehlerhaft ausgestellte Zertifikate.
DNSSEC beim externen DNS-Provider aktivieren
Microsoft 365 hat kein eigenes DNS-Hosting für Custom-Domains. DNSSEC muss beim DNS-Provider aktiviert werden, der Ihre Zone hostet — das ist typischerweise Ihr Domain-Registrar oder ein dedizierter DNS-Hoster (Cloudflare, IONOS, Hetzner, deSEC, INWX, Netcup).
DNSSEC-Aktivierungs-Optionen pro Provider
- Cloudflare DNS — Dashboard → DNS → Settings → DNSSEC: Enable. Algorithmus 13 (ECDSAP256SHA256) standardmäßig.
- IONOS — IONOS-Hilfecenter beschreibt automatische DNSSEC-Verwaltung bei eigenen IONOS-Nameservern (kein manueller DS-Schritt).
- deSEC.io (Berlin) — DNSSEC ist standardmäßig aktiv für alle Domains, kostenlos.
- Netcup — CCP → Domains → DNS → DNSSEC: aktivieren.
- Hetzner DNS Console — Status laut Hetzner-Doku Oktober 2018 (publiziert 2020): nicht unterstützt. Aktuellen Status im Panel pro Zone prüfen, sonst auf deSEC oder Cloudflare ausweichen.
DS-Record beim Registrar hinterlegen
Nach DNSSEC-Aktivierung beim DNS-Provider zeigt dieser den DS-Record an (Key Tag, Algorithm, Digest Type, Digest). Dieser DS-Record muss beim Registrar Ihrer Domain eingetragen werden — bei DENIC-Agenten für .de, bei der Schweizer Registry für .ch, bei .at-NIC für .at. Erst wenn der DS-Record bei der übergeordneten Zone propagiert ist, ist die Chain of Trust aktiv.
Wenn DNS-Provider und Registrar identisch sind (Cloudflare-Registrar + Cloudflare DNS, IONOS-Registrar + IONOS DNS), erfolgt die DS-Übertragung typischerweise automatisch. Bei externem Registrar (z.B. DENIC-Mitglied wie InterNetX, united-domains) ist es ein manueller Kopier-Schritt. Propagationsdauer typisch 1-24 Stunden.
Die offizielle Microsoft-365-Doku (learn.microsoft.com, Abruf 2026-05-18) dokumentiert Domain Connect als Standardprotokoll, das es Microsoft 365 erlaubt, „Confirm domain ownership“ und „Add DNS records required for Microsoft 365 services“ beim DNS-Hoster automatisch auszuführen — wenn dieser Domain Connect unterstützt. Direkt-dokumentierte Domain-Connect-fähige Provider: IONOS, 123-reg, AWS Route 53, Cloudflare, GoDaddy, Namecheap, Network Solutions, OVH, web.com, Wix. Wichtige DNSSEC-Konsequenz: Domain Connect propagiert MX/SPF/DKIM-CNAMEs, aber nicht DNSSEC-DS-Records — DNSSEC bleibt ein separater Aktivierungs-Schritt beim DNS-Provider und Registrar. Microsoft-365-MX-TTL muss weniger als 21.600 Sekunden (6 Stunden) betragen — Microsoft-Doku-Zitat zeichengenau: „Exchange Online only supports TTL values less than 6 hours (21,600 seconds).“ (Strict-Less-Than, nicht ≤). DKIM-Selector-Pattern: selector1._domainkey und selector2._domainkey als CNAMEs auf Microsoft-eigene selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com (gilt für DKIM-Setup, hat aber direkte CAA-Wechselwirkung — Microsoft-DKIM-Selectors sind CNAMEs, daher ist die CA für die Microsoft-Ziel-Subdomain relevant, nicht die eigene CAA-Politik am Apex).
CAA-Records für MTA-STS-Subdomain konfigurieren
MTA-STS (RFC 8461) verlangt ein TLS-Zertifikat auf mta-sts.example.com. Wenn Sie CAA-Records nutzen (RFC 8659), müssen Sie sicherstellen, dass mindestens die CA für das MTA-STS-Zertifikat autorisiert ist — sonst blockiert CAA die Ausstellung und MTA-STS wird wirkungslos.
; CAA-Records am Apex
example.com. IN CAA 0 issue "digicert.com" ; primärer Web-Cert
example.com. IN CAA 0 issue "letsencrypt.org" ; MTA-STS-Cert
example.com. IN CAA 0 issuewild ";" ; keine Wildcards
example.com. IN CAA 0 iodef "mailto:security@example.com"
; Subdomain-spezifischer CAA für mta-sts (RFC 8659 § 3)
mta-sts.example.com. IN CAA 0 issue "letsencrypt.org"Das CA/Browser-Forum hat im Juni 2025 mit Ballot SC-085v2 beschlossen, dass alle öffentlichen CAs ab dem 15. März 2026 DNSSEC bei CAA- und Domain-Control-Validation-Lookups validieren müssen. Wer CAA-Records ohne DNSSEC betreibt, riskiert ab März 2026 Verzögerungen bei TLS-Zertifikat-Erneuerungen — insbesondere für MTA-STS-Subdomains.
DNSSEC + DANE + CAA verifizieren
Nach der Aktivierung prüfen Sie die DNSSEC-Kette, den TLSA-Status am MX-Host und die CAA-Records mit dig — und ergänzend mit DNSViz für die visuelle Chain-of-Trust-Validierung.
# Microsoft-365-MX-Hostname per dig prüfen
dig MX example.com +short
# Erwartet: 0 .mail.protection.outlook.com.
# DNSSEC der eigenen Zone prüfen (die externe DNS-Zone)
dig +dnssec MX example.com | grep -E "RRSIG|ad;"
# Erwartet: "ad" Flag und RRSIG-Records — externe DNS-Zone signiert.
# DNSSEC am Microsoft-MX-Host selbst (Microsoft-side)
dig +dnssec MX .mail.protection.outlook.com
# Stand 2026: Microsoft signiert die outlook.com-Zone DNSSEC-konform —
# zu prüfen am eigenen Setup, der Status kann sich ändern.
# DANE/TLSA am MX-Host (Microsoft-side, NICHT von Microsoft dokumentiert)
dig TLSA _25._tcp..mail.protection.outlook.com +short
# Stand 2026: Microsoft 365 veröffentlicht für Exchange-Online-MX-Hosts
# typisch keine TLSA-Records — DANE-EE wird nicht angeboten.
# MTA-STS ist hier der dokumentierte Ersatz (siehe MTA-STS-Kapitel). Ergänzend prüfen Sie mit dem Wolf-Agents Email Security Check — dieser validiert die vollständige DNSSEC-Kette von der Root-Zone, prüft TLSA-Records am MX-Host und alle CAA-Records am Apex und auf MTA-STS-Subdomain. Das Monitoring überwacht den DNS-Stack alle 6 Stunden und alarmiert bei DS-Record-Asymmetrie oder neu ausgestellten TLS-Zertifikaten.
Häufige Fehler bei DNS-Sicherheit für Microsoft 365
DNSSEC im Microsoft-365-Admin-Center gesucht
Problem: DNSSEC-Toggle wird im M365-Admin-Center erwartet. Ursache: Microsoft 365 ist Mail-Backend, nicht DNS-Hoster. Lösung: DNSSEC bei dem DNS-Provider aktivieren, der Ihre Zone hostet (Cloudflare/IONOS/Hetzner/deSEC) — nicht in M365 selbst.
CAA blockiert MTA-STS-Zertifikat
Problem: CAA-Records am Apex erlauben nur DigiCert (für Web), MTA-STS-Hoster nutzt Let's Encrypt — Ausstellung schlägt fehl. Ursache: CAA-Politik zu restriktiv ohne Subdomain-Override. Lösung: Subdomain-spezifischen CAA-Record auf mta-sts.example.com mit kompatibler CA setzen oder mehrere issue-Tags am Apex.
DANE bei Microsoft 365 erwartet
Problem: TLSA-Records werden für Microsoft-MX-Hostnamen erwartet. Ursache: Microsoft 365 veröffentlicht für Exchange Online typischerweise keine TLSA-Records (Stand 2026). Lösung: MTA-STS als Ersatz nutzen — Microsoft dokumentiert MTA-STS-Setup für Custom-Domains; siehe MTA-STS-Kapitel für M365.
Compliance: NIS2, BSI TR-03108 und DSGVO mit Microsoft 365
Eine DNSSEC-gesicherte Custom-Domain für Microsoft 365 mit CAA-Records und MTA-STS-Policy ist der prüfbare Nachweis für NIS2 Art. 21 Abs. 2 lit. h (Kryptografie und Verschlüsselung). Das DNS-Hosting beim externen Provider (z.B. deSEC für deutsche Datensouveränität, IONOS für DACH-Hosting) erfüllt zusätzlich lit. c (Aufrechterhaltung des Betriebs) durch DNS-Redundanz. Microsoft 365 selbst ist DSGVO-konform mit EU Data Boundary (seit 2024 Full Rollout), die externen DNS-Records bleiben in der Hoheit des Domain-Inhabers.
M365 DNS-Compliance-Stack: NIS2 lit. h (DNSSEC + CAA + MTA-STS) + NIS2 lit. c (DNS-Redundanz via Anycast bei Cloudflare/deSEC) + BSI TR-03108 (DNS-Apex-Sicherung extern) + DSGVO Art. 32 lit. b (Verfügbarkeit, Microsoft EU Data Boundary). Wolf-Agents-USP: Der Email Security Check erkennt Microsoft-365-MX-Hostnamen automatisch (*.mail.protection.outlook.com Stack-Detection), prüft die DNSSEC-Kette am externen DNS-Provider, validiert TLSA-Status am Microsoft-MX-Host (typisch fehlend), prüft CAA-Records am Apex und auf MTA-STS-Subdomain — kein anderer DACH-Scanner deckt diese Microsoft-365-spezifischen Drift-Klassen ab. Cross-Verweis: DNS-Hijacking-Spoofing und SubdoMailing.
DNS-Sicherheits-Anleitung für weitere Provider:
Wie steht Ihre Domain bei DNS-Sicherheit · Microsoft 365?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.