SPF, DKIM & DMARC für Microsoft 365.
Microsoft 365 (Exchange Online) authentifiziert Ihre Domain nicht über einen einzigen Assistenten, wie es ein gehosteter ESP tut — die Aufgabe verteilt sich auf zwei Konsolen. SPF ist ein echtes gemeinsam genutztes include (include:spf.protection.outlook.com), das Sie in den einen SPF-TXT-Eintrag Ihrer Domain zusammenführen, und DKIM sind zwei CNAME-"Selector"-Einträge, die Sie veröffentlichen und anschließend im Microsoft-Defender-Portal aktivieren. DMARC ist ein dritter, separater Eintrag, den Microsoft niemals für Sie anlegt. Bringen Sie alle drei in Einklang, und Exchange Online versendet vollständig authentifiziert als Ihre eigene Domain, statt sich auf die standardmäßige onmicrosoft.com-Signatur zu stützen.
Warum Microsoft 365 authentifizieren?
Die Authentifizierung einer Microsoft-365-Domain entscheidet darüber, ob Ihre Mail den Posteingang erreicht — und M365 hat eine spezifische Falle, die DMARC unbemerkt aushebelt. Seit Februar 2024 verlangen Gmail und Yahoo von jedem Massenversender (grob ab 5.000 Nachrichten pro Tag), dass SPF, DKIM und DMARC mit Ausrichtung (Alignment) bestehen, und ab Mai 2025 begann Microsoft selbst, dasselbe für aufkommensstarke Mail an Outlook.com/Hotmail/Live durchzusetzen — geschäftliche Mail, die in Microsoft-Verbraucherpostfächern landet, muss sich also ebenfalls authentifizieren. Der für M365 einzigartige Haken: Standardmäßig signiert Exchange Online Ihre ausgehende Mail per DKIM mit der onmicrosoft.com-Domain des Mandanten (d=contoso.onmicrosoft.com), was nicht mit Ihrer eigenen From-Domain (contoso.com) übereinstimmt. SPF von Microsoft stimmt hingegen überein, sodass direkte Mail einen DMARC-Pass allein über SPF erzielen kann — doch sobald eine Nachricht weitergeleitet wird (Verteilerlisten, .forward-Regeln, Filter-Gateways), bricht SPF, und weil DKIM mit der falschen Domain signiert, bleibt nichts übrig, das DMARC trägt. Die Einrichtung von DKIM mit eigener Domain schließt genau diese Lücke und sorgt dafür, dass die Versandreputation, die Sie aufbauen, Ihrer eigenen Domain zugutekommt.
Die SPF-Realität bei Microsoft 365
Microsoft 365 ist ein echter "include"-Anbieter — anders als CNAME-Delegations-ESPs (Mailchimp, Klaviyo) oder kontospezifische Versender (Amazon SES) gibt es ein einziges echtes gemeinsames include, das Sie Ihrem Root-SPF hinzufügen: include:spf.protection.outlook.com. Veröffentlichen Sie es innerhalb eines einzigen SPF-TXT-Eintrags auf der Domain, z. B. v=spf1 include:spf.protection.outlook.com -all. Zwei Dinge machen den SPF von M365 ungewöhnlich gutmütig. Erstens löst das include zu einem flachen Eintrag auf, der ausschließlich ip4:/ip6:-Bereiche und ein eigenes -all enthält — keine verschachtelten includes — sodass es nur EINEN Ihrer 10 SPF-DNS-Lookups kostet (ein verbreiteter Mythos behauptet 2–3; der aktive Eintrag hat keine Sub-includes). Zweitens richtet SPF, weil Exchange Online standardmäßig Ihre eigene Domain als SMTP-MAIL-FROM (Envelope/Return-Path) verwendet, tatsächlich AUF Ihre Domain aus (Alignment), sodass das M365-include von sich aus zu einem DMARC-Pass beiträgt — etwas, das ESPs, denen der Return-Path gehört, nicht leisten können. Microsoft empfiehlt ausdrücklich den Qualifikator -all (Hard Fail), weil zugleich erwartet wird, dass Sie DKIM und DMARC betreiben. Zwei Einschränkungen: Nur souveräne/behördliche Clouds weichen ab — GCC High und DoD verwenden include:spf.protection.office365.us, und 21Vianet (China) verwendet include:spf.protection.partner.outlook.cn; und jede versendende Subdomain benötigt ihren eigenen SPF-Eintrag (der Eintrag von contoso.com deckt marketing.contoso.com nicht ab).
Schritt für Schritt
- 1
Domain bestätigen und ihre DNS-Einträge finden
Melden Sie sich unter admin.microsoft.com an und gehen Sie zu Settings → Domains, wählen Sie Ihre Domain aus und öffnen Sie den Tab DNS records. Wenn Sie Ihre Nameserver an Microsoft delegiert haben, sind SPF und der MX (yourdomain-com.mail.protection.outlook.com) möglicherweise bereits veröffentlicht. Liegt Ihr DNS bei einem Registrar/Host, beachten Sie, dass M365 hier keine SPF- oder DMARC-Steuerung hat — diese Einträge fügen Sie selbst bei Ihrem DNS-Host hinzu.
- 2
SPF-Eintrag veröffentlichen oder zusammenführen
Legen Sie bei Ihrem DNS-Host EINEN TXT-Eintrag auf dem Root an (Host @): v=spf1 include:spf.protection.outlook.com -all. Existiert bereits ein v=spf1-Eintrag (Google Workspace, ein Marketing-Tool usw.), führen Sie das include in diesen einen Eintrag zusammen — fügen Sie niemals einen zweiten SPF-TXT hinzu. Microsoft empfiehlt, mit -all (Hard Fail) abzuschließen. GCC High/DoD verwenden spf.protection.office365.us; 21Vianet verwendet spf.protection.partner.outlook.cn.
- 3
Den DKIM-Tab öffnen
Eigenes DKIM befindet sich NICHT im M365-Admin-Center. Gehen Sie zu security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings und wählen Sie dann den DKIM-Tab.
- 4
Die beiden CNAME-Werte einblenden
Klicken Sie auf Ihre eigene Domain. Eine nie eingerichtete Domain zeigt Status = NoDKIMKeys und den Schalter Disabled. Schieben Sie den Schalter auf Enable — weil die CNAMEs noch nicht existieren, öffnet sich ein 'Client error'-Dialog und der Status wechselt zu CnameMissing. Das ist zu erwarten, kein Fehler: Der Abschnitt 'Publish CNAMEs' zeigt nun die exakten CNAME-Ziele von selector1 und selector2. Kopieren Sie diese (oder führen Sie Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME,Selector2CNAME in der Exchange Online PowerShell aus).
- 5
Die beiden DKIM-Selector-CNAMEs hinzufügen
Legen Sie selector1._domainkey und selector2._domainkey als CNAME-Einträge an, die auf die exakten Ziele zeigen, die Ihnen das Portal angegeben hat. Neuere Domains (das von Microsoft im Mai 2025 eingeführte Format) erhalten Ziele wie selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (das <char>, z. B. n oder r, ist ein von Microsoft vergebenes Partitionszeichen); davor eingerichtete Domains erhalten selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com. Verwenden Sie das Format, das das Portal anzeigt — die beiden Formate können auf einem Selector nicht gemischt werden. Ändern Sie sie nicht in TXT.
- 6
DKIM auf Enabled umschalten
Nachdem die CNAMEs propagiert sind (meist Minuten, bis zu 48 Stunden), kehren Sie zum DKIM-Tab zurück, wählen die Domain aus und schieben den Schalter erneut auf Enable. Der Status springt auf Valid und 'Rotate DKIM keys' wird verfügbar. Von nun an signiert M365 mit d=yourdomain.com statt mit dem onmicrosoft.com-Standard, sodass DKIM ausgerichtet ist.
- 7
Den DMARC-Eintrag hinzufügen
M365 legt kein DMARC an. Fügen Sie einen TXT-Eintrag auf Host _dmarc hinzu: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Beginnen Sie mit p=none — Microsofts Überwachungsmodus 'keine Aktion ausführen' — sodass nichts beeinträchtigt wird, während Sie bestätigen, dass sowohl SPF als auch DKIM ausgerichtet sind, und verschärfen Sie später.
- 8
Einen Test senden und die Header lesen
Senden Sie sich aus einem Postfach der Domain selbst eine E-Mail an Gmail, öffnen Sie die Nachricht und wählen Sie ⋮ → Original anzeigen. Sie wollen SPF: PASS mit Ihrer Domain, DKIM: PASS mit d=yourdomain.com (NICHT onmicrosoft.com) und DMARC: PASS. Bestätigen Sie anschließend mit einer Domain-Integritätsprüfung, dass jeder Eintrag auflöst.
Einzutragende Einträge
Microsoft 365 erzeugt die genauen Werte in seinem Einrichtungsassistenten — diese zeigen die Struktur dessen, was Sie bei Ihrem DNS-Anbieter hinzufügen werden.
| Typ | Host | Wert |
|---|---|---|
| TXT | @ | v=spf1 include:spf.protection.outlook.com -allRoot-SPF — behalten Sie genau EINEN SPF-Eintrag; führen Sie dieses include zusammen, falls Sie bereits einen v=spf1-Eintrag haben. Kostet ~1 DNS-Lookup. |
| CNAME | selector1._domainkey | selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftDKIM-Schlüssel 1 (automatisch rotiert). Beispielhaft — kopieren Sie das exakte Ziel aus dem Defender-Portal; vor Mai 2025 erstellte Domains enden auf .onmicrosoft.com statt auf .n-v1.dkim.mail.microsoft. |
| CNAME | selector2._domainkey | selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftDKIM-Schlüssel 2 (der zweite Selector ermöglicht Microsoft die Schlüsselrotation). Beispielhaft — verwenden Sie den exakten Wert aus dem Portal. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDiesen fügen Sie selbst hinzu — M365 legt ihn nie an. Einer pro Domain; beginnen Sie mit p=none. |
| MX | @ | contoso-com.mail.protection.outlook.comLeitet eingehende Mail an Exchange Online (Priorität 0). Kein Authentifizierungseintrag, aber Teil des M365-Setups; Punkte in Ihrer Domain werden zu Bindestrichen. |
Behalten Sie genau einen SPF-TXT-Eintrag (v=spf1) auf Ihrer Root-Domain — führen Sie jeden Absender darin zusammen. Zwei SPF-Einträge sind bereits an sich ein Fehler.
Das Budget von 10 Lookups
SPF ist auf harte 10 DNS-Lookups begrenzt — wird dieser Wert überschritten, gibt SPF einen permerror zurück und validiert überall nicht mehr. Hier sehen Sie, was die Einrichtung von Microsoft 365 von diesem Budget verbraucht.
Microsoft 365 verbraucht 1 Ihrer 10 Lookups; ip4:- und ip6:-Mechanismen sind kostenlos.
DKIM
DKIM in Microsoft 365 ist der Teil, den die meisten falsch machen, weil M365 Mail bereits signiert, bevor Sie überhaupt etwas tun — nur eben mit der falschen Domain. Standardmäßig signiert Exchange Online ausgehende Mail per DKIM mit der ursprünglichen onmicrosoft.com-Domain Ihres Mandanten (d=contoso.onmicrosoft.com). Diese Signatur ist gültig, stimmt aber nicht mit Ihrer eigenen From-Domain überein und bringt DMARC für contoso.com daher nichts. Um das zu beheben, aktivieren Sie DKIM mit eigener Domain: zwei CNAME-Einträge, selector1._domainkey und selector2._domainkey, die die öffentlichen Schlüssel zurück an Microsoft delegieren. Weil es CNAMEs sind (keine TXT-Einträge, die Sie einfügen), behält Microsoft die privaten Schlüssel und nutzt die beiden Selektoren, um Schlüssel automatisch zu rotieren, ohne dass Sie je wieder das DNS anfassen müssen. Das Zielformat änderte sich im Mai 2025: Neuere eigene Domains erhalten selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (das <char>, z. B. n oder r, ist ein von Microsoft vergebenes Partitionszeichen), während davor eingerichtete Domains weiterhin selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com verwenden — das Portal (oder Get-DkimSigningConfig in der Exchange Online PowerShell) zeigt genau, welches Ihrem Mandanten zugewiesen ist, und die beiden Formate können für einen Selector nicht koexistieren. Ablauf: Die CNAMEs im Defender-Portal einblenden (Email authentication settings → DKIM), beide bei Ihrem DNS-Host veröffentlichen, die Propagierung abwarten und dann den DKIM-Schalter für die Domain auf Enabled umlegen, sodass der Status Valid anzeigt. Schlüssel sind standardmäßig 1024-bit; 2048-bit ist über New-DkimSigningConfig (mit -KeySize 2048) verfügbar. Erst nachdem der Schalter auf Enabled steht, signiert M365 mit d=yourdomain.com und DKIM beginnt auszurichten.
DMARC
DMARC ist ein separater Richtlinien-TXT-Eintrag auf Ihrer Domain, den Microsoft 365 nicht anlegt — Sie fügen ihn bei Ihrem DNS-Host hinzu. Veröffentlichen Sie ihn unter _dmarc.yourdomain.com, beginnend mit v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none ist Microsofts empfohlener Überwachungsmodus "keine Aktion ausführen": Er ändert nichts an der Zustellung, während Sie die aggregierten (rua-)Berichte auswerten, um zu bestätigen, dass M365 (und alle anderen Versender) SPF und DKIM ausgerichtet auf Ihre Domain bestehen. Microsofts eigene Empfehlung lautet, DKIM-Signierung und DMARC im Überwachungsmodus zügig einzurichten und die Richtlinie dann hochzufahren — auf p=quarantine und anschließend p=reject verschärfen, sobald das Alignment konsistent ist. Behalten Sie nur einen einzigen _dmarc-Eintrag für die gesamte Organisationsdomain; Subdomains erben die übergeordnete Richtlinie automatisch (Sie können eine bestimmte Subdomain mit einem eigenen _dmarc-Eintrag oder dem sp=-Tag überschreiben). Weil der SPF von M365 ausgerichtet ist und — sobald Sie eigenes DKIM eingerichtet haben — auch DKIM ausgerichtet ist, besteht eine korrekt konfigurierte M365-Domain DMARC über beide Mechanismen — das robuste Setup, das eine Weiterleitung übersteht.
Prüfen, ob es wirklich funktioniert hat
Verlassen Sie sich nicht allein auf das "Valid"-Abzeichen des Defender-Portals — bestätigen Sie es an einer echten Nachricht. Senden Sie sich selbst einen Test aus einem Postfach der Domain, öffnen Sie ihn in Gmail und wählen Sie ⋮ → Original anzeigen: Sie wollen SPF: PASS, DKIM: PASS mit d=yourdomain.com (das verräterische Fehlerzeichen ist d=yourtenant.onmicrosoft.com, was bedeutet, dass eigenes DKIM noch nicht aktiviert ist) und DMARC: PASS. Im Defender-Portal sollte der DKIM-Tab Status = Valid und Toggle = Enabled für die Domain anzeigen. Lassen Sie dann Ihre Domain durch die Domain-Integritätsprüfung von Qualisend laufen, um zu bestätigen, dass der SPF, beide DKIM-Selector-CNAMEs und der DMARC-Eintrag alle sauber auflösen, und sobald die aggregierten DMARC-Berichte eintreffen, geben Sie einen davon in den DMARC-Berichtsanalysator ein — Outlook.com / Exchange Online sollte als ausgerichtete, bestehende Quelle erscheinen.
Häufige Stolperfallen
- Abdeckung
Die häufigste M365-Falle: Bis Sie DKIM mit eigener Domain aktivieren, wird Mail als d=yourtenant.onmicrosoft.com signiert, was NICHT ausgerichtet ist — DMARC erhält also keine Hilfe von DKIM und bricht, sobald eine Nachricht weitergeleitet wird. SPF allein reicht nicht.
- DNS-Einrichtung
Der 'Client error'-Dialog / Status CnameMissing, den Sie erhalten, wenn Sie den DKIM-Schalter erstmals auf Enable schieben, ist zu erwarten, kein Bug — so blendet das Portal die CNAME-Werte ein. Veröffentlichen Sie die beiden CNAMEs, kehren Sie zurück und schalten Sie erneut auf Enable.
- DNS-Einrichtung
DKIM-CNAME-Ziele änderten sich im Mai 2025: Seitdem eingerichtete eigene Domains zeigen auf <tenant>.<char>-v1.dkim.mail.microsoft, ältere auf <tenant>.onmicrosoft.com. Kopieren Sie das exakte Ziel aus dem Defender-Portal (oder Get-DkimSigningConfig) — altes und neues Format können auf demselben Selector nicht gemischt werden.
- Bricht die Authentifizierung
Behalten Sie genau EINEN SPF-TXT-Eintrag auf der Domain. Versenden Sie bereits über Google Workspace, SendGrid usw., führen Sie include:spf.protection.outlook.com in diesen einen Eintrag zusammen — zwei SPF-TXT-Einträge sind selbst ein PermError.
- Abdeckung
Von GoDaddy oder IONOS bereitgestelltes M365 liefert oft einen Standard-SPF von include:secureserver.net aus, der Exchange-Online-Postfächer NICHT autorisiert. Er muss zu include:spf.protection.outlook.com auflösen.
- DNS-Einrichtung
M365-DKIM-Einträge sind CNAMEs — liegt Ihr DNS also hinter Cloudflare, setzen Sie jeden Selector-Eintrag auf 'DNS only' (graue Wolke). Ein per Orange-Wolke proxied CNAME löst nicht zum Microsoft-Host auf und die DKIM-Aktivierung schlägt fehl.
- DNS-Einrichtung
Achten Sie auf die SPF-Syntaxfehler, auf die Microsoft hinweist: kein abschließender Punkt (include:spf.protection.outlook.com. ist falsch), ein Doppelpunkt statt Gleichheitszeichen nach 'include' und kein Leerzeichen nach dem Doppelpunkt. Viele Registrare hängen zudem automatisch Ihre Domain an CNAME-/Host-Felder an und verdoppeln sie damit.
- Abdeckung
Jede versendende Subdomain benötigt ihren eigenen SPF (und ihr eigenes DKIM). Der Eintrag auf contoso.com deckt marketing.contoso.com nicht ab — Massen-/Marketing-Tools, die von einer Subdomain versenden, benötigen dort SPF, DKIM und in der Regel eine eigene DMARC-Handhabung.
Erstellen Sie Ihren SPF-Eintrag
Microsoft 365 ist unten bereits vorausgewählt. Fügen Sie alle weiteren Plattformen hinzu, über die Sie versenden, und veröffentlichen Sie anschließend den einen zusammengeführten Eintrag.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listMicrosoft 365 SPF — FAQ
Weiterführende Lektüre
Sobald der Eintrag veröffentlicht ist, prüfen Sie mit dem Domain-Health-Check, ob alles korrekt aufgelöst wird, und lesen Sie mit der DMARC-Berichtsanalyse nach, wer in Ihrem Namen versendet. Durchsuchen Sie alle Versandquellen im Generator. Authentifizierung ist allerdings nur die halbe Zustellbarkeit — eine gelistete Absender-IP oder -Domain bringt Sie unabhängig davon, wie sauber Ihr SPF ist, im Spam-Ordner unter, deshalb lohnt es sich, mit Blacklist-Überwachung die Blacklists im Blick zu behalten.
Authentifiziert — jetzt die Liste sauber halten
SPF, DKIM und DMARC zu bestehen bringt Sie in den Posteingang; eine saubere Liste hält Sie dort. Verifizieren Sie Ihre — starten Sie kostenlos mit 100 Credits, ohne Kreditkarte.