Warum der Startpunkt bei M365 und Workspace anders ist
Die meisten Unternehmen nutzen Microsoft 365 oder Google Workspace als primäre E-Mail-Plattform - und beide Anbieter haben eigene Verfahren für SPF, DKIM und DMARC. Der größte Unterschied zu selbst gehosteten Mailservern: Viele Einstellungen werden über grafische Admin-Konsolen vorgenommen, nicht direkt über DNS-Editor-Zugänge. Das vereinfacht die Konfiguration, macht aber auch bestimmte Fallstricke plattformspezifisch.
Dieser Leitfaden führt dich Schritt für Schritt durch die Einrichtung für beide Plattformen - mit konkreten Record-Beispielen, Hinweisen zu Drittanbieter-Integrationen und der Frage, wann ein DMARC-Monitoring-Tool wie DMARCFlow sinnvoll wird.
SPF für Microsoft 365 einrichten
Für eine Domain, die ausschließlich über Microsoft 365 E-Mails versendet, lautet der Standard-SPF-Record:
v=spf1 include:spf.protection.outlook.com -all
Wichtige Ergänzungen:
- Wenn du zusätzlich eigene Server oder lokale Exchange-Hybrid-Setups nutzt, füge deren IP-Adressen hinzu:
ip4:203.0.113.10. - Für jede Subdomain, die eigenständig Mails versendet, brauchst du einen separaten SPF-Record.
- Wenn du Drittanbieter-Tools (CRM, Helpdesk, Marketing-Automation) über deine M365-Domain versenden lässt, müssen deren SPF-Includes ebenfalls hinzugefügt werden - dabei auf das 10-Lookup-Limit achten.
DKIM für Microsoft 365 aktivieren
Microsoft 365 nutzt CNAME-Delegierung für DKIM. Du veröffentlichst zwei CNAME-Records in deinem DNS, die auf Microsofts Signing-Infrastruktur zeigen. Die genauen Werte findest du im Microsoft Defender-Portal unter E-Mail & Zusammenarbeit → Richtlinien & Regeln → Bedrohungsrichtlinien → DKIM.
Schritte:
- Im Defender-Portal zur DKIM-Seite navigieren, deine Domain auswählen.
- Die beiden CNAME-Records (
selector1._domainkeyundselector2._domainkey) in deinem DNS-Provider veröffentlichen. - Nach DNS-Propagation (ca. 1 Stunde) die DKIM-Signierung im Defender-Portal aktivieren.
- Mit einer Test-E-Mail oder einem DKIM-Checker verifizieren, dass die Signatur korrekt erscheint.
Alternativ lässt sich DKIM via PowerShell aktivieren: New-DkimSigningConfig -DomainName "deinedomain.de" -Enabled $true.
SPF für Google Workspace einrichten
Für eine Domain, die ausschließlich über Google Workspace E-Mails versendet:
v=spf1 include:_spf.google.com ~all
Hinweise:
- Google empfiehlt
~all(Softfail) statt-all(Hardfail) für Workspace, da Weiterleitungsszenarien sonst zu falsch positiven Fehlern führen können. Mit DMARC p=reject ist Softfail ausreichend sicher. - Wenn du das Google SMTP-Relay für interne Systeme nutzt, sind diese automatisch über
_spf.google.comabgedeckt.
DKIM für Google Workspace aktivieren
- In der Google Admin-Konsole zu Apps → Google Workspace → Gmail → E-Mail-Authentifizierung navigieren.
- Für deine primäre Domain einen DKIM-Schlüssel generieren (2048 Bit empfohlen).
- Den angezeigten TXT-Record in deinem DNS unter
google._domainkey.deinedomain.deveröffentlichen. - Nach DNS-Propagation (bis zu 48 Stunden) die Signierung in der Admin-Konsole aktivieren.
Google Workspace signiert standardmäßig mit dem Selektor "google". Wenn du mehrere Domains in Workspace verwaltest, muss DKIM für jede Domain separat aktiviert werden.
Konfigurationsübersicht: M365 vs. Google Workspace
| Einrichtung | Microsoft 365 | Google Workspace |
|---|---|---|
| SPF-Record | include:spf.protection.outlook.com |
include:_spf.google.com |
| DKIM-Methode | 2 CNAMEs via Defender-Portal oder PowerShell | TXT-Record via Admin-Konsole, Selektor "google" |
| DKIM-Schlüssellänge | 2048 Bit (Standard) | 2048 Bit (empfohlen, auswählbar) |
| DMARC-Record | Identisch: TXT unter _dmarc.deinedomain.de, mit p=none starten und rua setzen |
|
| Drittanbieter-Integration | SPF-Include oder eigene Subdomain; DKIM via weiteres CNAME | Wie M365 - eigene Subdomain oder Provider-seitige DKIM-Konfiguration |
DMARC-Record einrichten und Monitoring starten
Sobald SPF und DKIM aktiv und verifiziert sind, kannst du den DMARC-Record veröffentlichen. Starte immer mit p=none:
v=DMARC1; p=none; rua=mailto:dmarc@deinedomain.de; ruf=mailto:dmarc-forensics@deinedomain.de; fo=1
Lasse die Reports 30 Tage laufen. In dieser Zeit erkennst du alle Sendesysteme, die im Namen deiner Domain agieren, und kannst fehlkonfigurierte Quellen bereinigen, bevor du auf p=quarantine wechselst.
DMARCFlow empfängt und parst diese XML-Reports automatisch und zeigt dir in einem Dashboard, welche Systeme gute und schlechte Authentifizierungsquoten haben - ohne dass du XML-Dateien manuell auswerten musst.
Häufige Probleme bei M365- und Workspace-Setups
- Drittanbieter-Tools vergessen: CRM, Helpdesk, E-Commerce und Newsletter-Plattformen versenden oft E-Mails über deine Domain, ohne dass SPF-Include und DKIM konfiguriert sind. Diese erscheinen in den DMARC-Reports als "failing sources".
- Weiterleitungen brechen SPF: Wenn Nutzer ihre @deinedomain.de-Adresse an ein privates Gmail weiterleiten, schlägt SPF bei Gmail fehl (die IP von Gmail ist nicht in deinem SPF autorisiert). DKIM überlebt Weiterleitungen - deshalb ist DKIM für DMARC-Stabilität wichtiger als SPF.
- Hybrid-Setup bei M365: Wer noch lokale Exchange-Server betreibt und diese als Relay für externe Mails nutzt, muss sicherstellen, dass die lokalen Server-IPs im SPF-Record stehen und DKIM-Signierung korrekt über das Hybrid-Setup läuft.
Bereit loszulegen? Prüfe deinen aktuellen Status kostenlos mit dem DMARCFlow DMARC-Prüfer und dem SPF-Prüfer.
Wählen Sie eine DMARC-Plattform mit klaren Dashboards, Automatisierung und EU-Hosting ...
Fazit
E-Mail-Authentifizierung ist für M365/Workspace unverzichtbar ...
DMARCFlow speichert Daten ausschließlich in der EU, erfüllt die DSGVO und bietet klare Reports sowie geführten Einstieg.