Gefälschte Absenderadressen und domänenbasierte Spoofing-Angriffe gehören weiterhin zu den effektivsten Angriffsvektoren im E-Mail-Verkehr. In der Microsoft 365-Welt stehen mit SPF, DKIM und DMARC wichtige und notwendigen Bausteine zur Verfügung, um Absenderdomänen zu schützen, die Zustellbarkeit zu optimieren und Missbrauch transparent zu machen. Entscheidend ist jedoch die konsequente, technisch saubere Implementierung und der laufende Betrieb. In diesem Beitrag zeige ich, wie du DKIM und DMARC in Microsoft 365 korrekt einführst, welche Stolperfallen es gibt und wie du den Betrieb effizient absicherst.
Begriffsklärung: SPF, DKIM, DMARC
- SPF (Sender Policy Framework) definiert, welche IP-Adressen oder Hosts im Namen deiner Domäne E-Mails versenden dürfen. SPF ist einfach zu implementieren, bricht aber häufig bei Weiterleitungen.
- DKIM (DomainKeys Identified Mail) versieht ausgehende E-Mails mit einer kryptografischen Signatur, die vom sendenden MTA erzeugt wird. Die Signatur bleibt bei Weiterleitungen intakt, solange Inhalt und Header nicht verändert werden.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) ist die Richtlinie der From:-Domäne. Sie steuert die Durchsetzung und das Reporting auf Basis von SPF- und DKIM-Alignment. DMARC gilt als bestanden, wenn entweder SPF oder DKIM aligned PASS ist.
Alignment: Relaxed vs. Strict
DMARC unterscheidet zwischen relaxed (r) und strict (s) Alignment. Relaxed erlaubt Subdomains (z. B. header.d=mail.graber.cloud, From=graber.cloud), strict verlangt exakte Übereinstimmung (header.d=graber.cloud, From=graber.cloud). Für maximale Sicherheit empfiehlt sich strict, sobald alle legitimen Flüsse sauber aligned sind.
DKIM und DMARC gehen Hand in Hand. Hast du mehrere Domänen, so muss jede separat aktiviert und mit eigenen CNAMEs versehen werden. Für Subdomains mit eigenem From: aktiviere DKIM separat oder nutze eine spezifische DMARC sp-Policy für alle Subdomains. Wird nach dem Signieren noch ein Disclaimer oder eine Signatur eingefügt, bricht DKIM. Das Signieren muss immer auf dem finalen ausgehenden Hop erfolgen. Prüfe also deine Mailflow-Topologie sorgfältig und fahre nur fort, wenn du dir sicher bist.
Voraussetzungen in Microsoft 365
Bevor du aber startest, stelle folgendes sicher:
- Die Domäne ist in Microsoft 365 verifiziert.
- Du hast Zugriff auf den öffentliche DNS der Domäne.
- Ein korrekter SPF-Record ist veröffentlicht (z. B. v=spf1 include:spf.protection.outlook.com -all).
- Notwendigen Rolle (Global/Exchange Admin oder Security Admin).
DKIM in Exchange Online implementieren
Ziel ist es, dass ausgehende Mails deiner Domäne von Exchange Online signiert werden. Der Prozess gliedert sich in drei Kernschritte:
DKIM-DNS-Records anlegen
Für jede zu signierende Domäne müssen zwei CNAMEs im öffentlichen DNS erstellt werden:
- selector1._domainkey.<deine-domäne> → CNAME auf den von Microsoft 365 bereitgestellten Host für selector1.
- selector2._domainkey.<deine-domäne> → CNAME auf den von Microsoft 365 bereitgestellten Host für selector2.
Die exakten Ziel-Hosts werden im Microsoft 365 Defender Portal hier angezeigt. Wichtig, verwende ausschliesslich diese Werte – alles andere bricht deinen Maildienst.
DKIM für die Domäne aktivieren
Im Microsoft Defender Portal kann dann DKIM aktiviert werden, sobald der DNS-Eintrag erstellt wurde.
Alternativ kann das auch per PowerShell erledigt werden:
Connect-ExchangeOnline
Get-DkimSigningConfig -Identity <domain>
Set-DkimSigningConfig -Identity <domain> -Enabled $trueWichtig: Die beiden CNAMEs müssen im DNS sichtbar sein. Meldet das Portal „CnameMissing“ (siehe PrintScreen oben), prüfe die DNS-Konfiguration und warte die Replikationszeit ab, oder überprüfe mittels CMD nslookup.
nslookup
set type=cname
selector1._domainkey.<domain>
selector2._domainkey.<domain>Im Anschluss ist der Status mit «Valid» bestätigt und der Tobble auf «Enabled».
Schlüsselrotation etablieren
Microsoft 365 nutzt zwei Selektoren (selector1/selector2), um eine Zero-Downtime-Rotation zu ermöglichen. Die Rotation erfolgt per Portal oder PowerShell (Rotate-DkimSigningConfig -Identity <domain>). Plane die Rotation mindestens jährlich, besser quartalsweise oder halbjährlich. Am besten testest und automatisierst du diesen Prozess.
DMARC einführen – Stufenweise und mit Reporting
Das Ziel ist, die Policy von Monitoring (p=none) bis zur strikten Durchsetzung (p=reject) zu entwickeln, ohne legitime Sender auszuschliessen. So gehst du vor.
Reporting-Adressen vorbereiten
Definiere die Mailadressen für Aggregate Reports (rua) an, z. B. rua=mailto:dmarc-agg@domain.com. Diese Postfächer sollten Berichte automatisiert verarbeiten können (beispielsweise ein DMARC-Parser). Forensic/Failure Reports (ruf) ist ein detaillierter Report über eine individuelle E-Mail und ist daher optional und datenschutzrelevant.
Start mit p=none (Beobachten)
Veröffentliche eine DNS TXT-Record _dmarc.<domain>:
v=DMARC1; p=none; rua=mailto:dmarc-agg@domain.com;Ziel ist, die Senderlandschaft zu inventarisieren und das Alignment zu analysieren. Prüfe, welche Quellen SPF/DKIM aligned bestehen und wo Handlungsbedarf besteht.
Drittanbieter-/SaaS-Sender bereinigen
Identifiziere nun alle legitimen Absender (Marketing, CRM, Ticketing, Scanner, ERP, CSPs). Für jeden Sender muss SPF und DKIM korrekt konfiguriert sein. Best Practice für externe Plattformen mit Mailversand ist daher eine Subdomäne zu verwenden und dort SPF, DKIM und DMARC separat zu managen. Beispielsweise news.domain.com
Policy-Stufe erhöhen (quarantine)
Sobald die Berichte stabil sind, erhöhe die Policy schrittweise.
Mittels Tag «fo» wird die Forensik definiert. Der Wert 1 definiert, dass ein Report generiert wird sobald SPF oder DKIM Prüfung fehlschlägt. Mit «adkim=r» wird das DKIM-Alignment auf «relaxed» gesetzt und akzeptiert somit auch Subdomänen wie sub.<domain>.com. Das gleiche gilt für das Tag «aspf«, welches für das SPF-Alignment steht.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@<domain>.com; fo=1; adkim=r; aspf=rBehalte die Report im Auge und erhöhe «pct» schrittweise auf 100. Es bieten sich 25er Schritte an, also 25, 50, 75 und 100.
Policy Durchsetzen (reject)
Sobald anhand der Reports klar ist, dass alles korrekt abläuft, setzt du die Policy auf «reject», sowie das DKIM- & DMARC-Alignment auf «s» (strict).
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-agg@contoso.com; fo=1sp=reject schützt Subdomänen, falls diese keinen eigenen Record haben. Die Tags adkim/aspf können auf strict erhöht werden, wenn alle legitimen Mailflüsse 1:1 aligned sind.
Häufige Fehler und Pitholes
- Falscher Record-Typ: DKIM benötigt CNAMEs, kein TXT bei Microsoft 365.
- Falscher Eintrag: Ziel-Hosts der CNAMEs variieren – immer die im Portal angezeigten Werte verwenden.
- Zu frühe Durchsetzung: p=reject ohne Bereinigung blockiert legitime Mails, insbesondere von Drittanbietern.
- Nur auf SPF gesetzt: Forwarding bricht SPF. DKIM-Alignment ist die robustere DMARC-Säule.
- Nachträgliche Inhaltsänderung: Disclaimer/Signaturen, die nach der DKIM-Signatur eingefügt werden, invalidieren die Signatur. Signieren am letzten Hop.
- Fehlende Subdomänen-Strategie: Marketing-/Transaktionsmails sauber trennen (eigene Subdomänen, eigene DKIM/DMARC).
- Keine Rotation: DKIM-Schlüssel regelmässig rotieren und Rotation automatisieren.
- Keine Telemetrie: rua/ruf nicht konfiguriert oder Berichte werden nicht ausgewertet – damit fehlt der Sicherheitsgewinn und Überwachung.
Fazit
Mit einer sauberen Erstimplementierung von DKIM und DMARC, einer kontrollierten, datengetriebenen Verschärfung bis p=reject und einem disziplinierten Betrieb inkl. Rotation und Monitoring hebst du die Mail-Sicherheit in Microsoft 365 auf ein belastbares Niveau. Wer Drittanbieter-Sender frühzeitig einbindet und Subdomänen sauber segmentiert, erreicht eine hohe Zustellbarkeit und minimiert Spoofing-Risiken nachhaltig. DMARC und DKIM sollten in jedem Fall verwendet werden und zum Standard gehören.
Quellen:
German 
English