SPF für Microsoft 365 und Google Workspace: die Konfiguration, die funktioniert

v=spf1 include:spf.protection.outlook.com -all

v=spf1 include:_spf.google.com -all

Beide gemeinsam

Viele Organisationen migrieren, fusionieren oder betreiben beide parallel. In diesem Fall kombiniert ein einziger SPF-Eintrag beide include:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Es gilt die goldene Regel: ein einziger v=spf1-Eintrag pro Domain. Ein Eintrag für Microsoft und ein weiterer für Google ergeben einen doppelten Eintrag, Quelle von PermError — und zahlreiche Empfänger ignorieren dann beide. Best Practice ist, alles in einer einzigen Zeile zu kombinieren.

Die Falle der Lookup-Zählung

Hier, was die Teams überrascht: Diese beiden include verbrauchen für sich allein viele DNS-Lookups. include:_spf.google.com entfaltet sich in mehrere Sub-include (_netblocks, _netblocks2, _netblocks3), also etwa vier Lookups. include:spf.protection.outlook.com verbraucht zwei oder drei. Zusammengesetzt ergeben die beiden schon sechs oder sieben Lookups, bevor ein einziger Drittdienstleister hinzugekommen ist.

Das Limit liegt aber bei zehn. Es bleiben also nur drei oder vier Lookups für den Marketing-Router, die Rechnungsstellung, das Support-Tool … Man versteht, warum so viele Einträge in PermError kippen: Microsoft und Google belegen schon die Hälfte des Budgets.

Die Strategie, um die weiteren Dienstleister hinzuzufügen

Da das Budget knapp ist, zählt die Methode. Nach Präferenz geordnet:

1. Nach Subdomain trennen. Microsoft 365 oder Google Workspace bleiben auf der Root-Domain (die menschliche Messaging), das Marketing geht von news.beispiel.de und das Transaktionale von notif.beispiel.de aus, jedes mit eigenem SPF. Jede Subdomain startet mit einem intakten Budget von zehn Lookups. Das ist bei Weitem die nachhaltigste Strategie.
2. Das DKIM-Alignment für Drittanbieter bevorzugen. Ein Router, der DKIM ausgerichtet signiert (d=beispiel.de), erfüllt DMARC ohne einen SPF-Lookup zu verbrauchen. Das ist oft der beste Weg, einen Dienstleister einzubinden, ohne das SPF zu belasten.
3. Die Dienstleister mit stabilen IPs in ip4: einfrieren, als letztes Mittel, und überwachen, dass sie sich nicht ändern.

Um jeden Preis zu vermeiden ist, die include auf der Root-Domain zu stapeln „weil es einfacher ist": Das ist der direkte Weg zum PermError.

Während einer Migration: beide, vorübergehend

Der Wechsel von Google Workspace zu Microsoft 365 (oder umgekehrt) ist ein riskanter Moment für das SPF. Während des Übergangs läuft der Versand über beide Plattformen: Der Eintrag muss also beide include gleichzeitig enthalten.

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Zwei Fallen lauern. Erstens: auf keinen Fall zwei getrennte Einträge „für die Dauer der Migration" erzeugen — das ist der sichere doppelte Eintrag und der PermError, der dazugehört. Zweitens: das include der alten Plattform entfernen, sobald die Migration abgeschlossen ist. Ein verwaistes include verbraucht Lookups für nichts, und wenn der alte Dienst am Ende seinen Eintrag schließt, wird er zu einem Void-Lookup. Eine saubere Migration endet also mit einer Bereinigung des Eintrags, nicht nur mit dem Wechsel der Messaging. Der richtige Reflex: von Anfang an das geplante Datum zum Entfernen des alten include notieren, damit es nicht monatelang herumliegt und eines Tages ein böses Erwachen im PermError beschert.

Die spezifischen Fallen

Einige Fehler kommen bei diesen beiden Plattformen wieder:

• Google- oder Microsoft-IPs von Hand kopieren. Das bricht die selbstgepflegte Verbindung und setzt Fehlschlägen aus, wenn sich die Bereiche ändern. Besser bei den offiziellen include bleiben.
• Die Versand-Subdomains vergessen. Läuft der Versand über mail.beispiel.de, braucht diese Subdomain ihr eigenes SPF — das SPF der Root gilt nicht automatisch für die Subdomains.
• SPF und DKIM/DMARC verwechseln. Das include zu konfigurieren reicht nicht: Die DKIM-Signatur ist auf Microsoft- oder Google-Seite (über deren Konsole) zu aktivieren, und der DMARC-Eintrag gehört veröffentlicht.
• Tenants vermischen. Bei mehreren Microsoft-Tenants oder mehreren Google-Domains hat jeder seine Konfiguration; ihre include gehören nicht vermischt, ohne zu prüfen, was damit wirklich autorisiert wird.

Ein vollständiger Eintrag, aus der Praxis

Nehmen wir ein typisches Unternehmen: Messaging auf Microsoft 365, Marketing über einen Router (Brevo), Rechnungsstellung über eine Fachanwendung und ein Support-Tool, das Benachrichtigungen versendet. Die Versuchung ist, eine einzige Sammelzeile zu schreiben:

v=spf1 include:spf.protection.outlook.com include:spf.brevo.com
  include:_spf.facturation.com include:_spf.support.com -all

Entfalten wir: Microsoft ≈ 3, Brevo ≈ 1-2, Rechnungsstellung ≈ 1, Support ≈ 1, plus die eventuellen Sub-include. Wir sind bei sechs oder sieben Lookups, vielleicht mehr. Das „geht" heute, aber ohne Spielraum, und das fünfte Tool kippt in PermError.

Die nachhaltige Konfiguration verteilt die Flüsse nach Subdomain:

• Root-Domain (unternehmen.de): v=spf1 include:spf.protection.outlook.com -all — nur die menschliche Messaging.
• news.unternehmen.de: v=spf1 include:spf.brevo.com -all — das Marketing, mit DKIM ausgerichtet auf der Subdomain.
• notif.unternehmen.de: v=spf1 include:_spf.support.com -all — die Benachrichtigungen.
• Die Rechnungsstellung, die nur eine feste IP hat, läuft über ausgerichtetes DKIM, ohne das SPF anzufassen.

Jeder Eintrag bleibt winzig, weit vom Limit entfernt, und jeder Fluss kann wachsen, ohne die anderen zu bedrohen. Das ist am Anfang mehr Arbeit als eine Sammelzeile, aber es ist genau das, was den PermError sechs Monate später vermeidet, wenn ein fünftes Tool ohne Vorwarnung dazukommt.

Und DMARC in all dem

Das Microsoft- oder Google-include zu konfigurieren bringt SPF durch, aber das ist nur die Hälfte des Bildes. Damit eine Domain wirklich geschützt ist, muss auch die DKIM-Signatur aktiviert (in der Konsole von Microsoft 365 oder Google Workspace) und ein DMARC-Eintrag veröffentlicht werden. Es ist das Alignment — SPF oder DKIM ausgerichtet mit dem From: — das den Schutz ausmacht, nicht das SPF allein. Beide Plattformen bieten ihr DKIM in wenigen Klicks an; beim SPF aufzuhören reicht auf keinen Fall. Sobald die drei Bausteine stehen, ist p=reject auf DMARC-Seite anzustreben, damit die Usurpation der Domain wirklich abgewiesen und nicht nur beobachtet wird.

Die Konfiguration prüfen

Sobald der Eintrag steht, ist er zu kontrollieren: ein einziges v=spf1, gültige Syntax, Lookup-Zählung unter zehn, Qualifizierung -all. Unser kostenloser Analyzer erledigt das alles in Sekunden und entfaltet die Microsoft- und Google-include, um ihre realen Kosten zu zeigen. Der vollständige Ablauf steht in wie sich ein Eintrag prüfen lässt. Und das Wesentliche nicht vergessen: Die abschließende Qualifizierung muss -all anstreben (siehe die Mechanismen -all und ~all).

Häufige Fragen

Braucht man -all oder ~all mit Microsoft 365 / Google Workspace? -all ist anzustreben, sobald alle Quellen gelistet sind. Microsoft und Google empfehlen manchmal ~all aus Vorsicht zum Start, aber das ist kein Ziel: Eine beherrschte Domain endet mit -all.

Reicht das Google-/Microsoft-include für DMARC? Nein. Es bringt SPF für die Messaging der Plattform durch, aber DMARC verlangt das Alignment mit dem From:. Für die menschliche Messaging ist das Alignment in der Regel gut; für die Drittanbieter, die „im Namen der Domain" über diese Plattformen versenden, klärt ein Blick in die Berichte das Alignment.

Warum läuft mein SPF über, obwohl ich nur Microsoft und einen Router habe? Weil spf.protection.outlook.com plus ein Router, der sich entfaltet, schon zehn Lookups nahekommen können. Der Router gehört auf eine Subdomain getrennt oder auf ausgerichtetes DKIM umgestellt.

Kann ich Microsoft 365 und Google Workspace auf dieselbe Domain setzen? Ja, indem ihre include in einem einzigen Eintrag kombiniert werden. Nur die Zählung will überwacht sein, denn beide zusammen verbrauchen schon eine gute Hälfte des Budgets.

Muss ich SPF konfigurieren, wenn ich schon DKIM nutze? Ja, beide sind komplementär. SPF und DKIM decken verschiedene Fälle ab, und DMARC stützt sich auf das eine oder das andere ausgerichtet. Beide gehören konfiguriert — siehe wie die drei Protokolle zusammenarbeiten.

Warum das Lookup-Budget so schnell aufgebraucht ist

Es lohnt sich, kurz innezuhalten und zu verstehen, warum gerade Microsoft 365 und Google Workspace so viel vom Budget der zehn Lookups verschlingen. Beide Anbieter bedienen weltweit Millionen Organisationen und betreiben eine riesige, geografisch verteilte Server-Infrastruktur. Damit ein include all diese Server abdecken kann, ohne dass jeder Kunde die IPs von Hand pflegt, splitten die Anbieter ihre Bereiche in mehrere verschachtelte Sub-Einträge auf — bei Google die _netblocks-Reihe, bei Microsoft eigene interne Verweise. Jede dieser Verschachtelungsebenen kostet einen eigenen DNS-Lookup. Was von außen wie ein einziges include aussieht, entfaltet sich beim Empfänger also in eine ganze Kaskade von Abfragen. Das ist kein Fehler der Anbieter, sondern der Preis dafür, dass sie den Eintrag zuverlässig aktuell halten.

Diese Erkenntnis ändert die richtige Strategie grundlegend. Da die Plattform-Basis allein schon die Hälfte oder mehr des Budgets belegt, ist es aussichtslos, weitere Dienstleister einfach hinten anzuhängen und zu hoffen, dass es passt. Der Spielraum ist von vornherein knapp, und jeder zusätzliche include frisst mehr, als man denkt. Deshalb ist die Subdomain-Trennung hier keine feine Optimierung, sondern die einzige wirklich skalierbare Antwort: Sie gibt jedem Fluss ein frisches, volles Budget, statt alle Flüsse um dieselben verbleibenden drei oder vier Lookups konkurrieren zu lassen.

Ein Wort zur menschlichen und zur automatischen Post

Ein Denkmodell, das die Konfiguration deutlich vereinfacht, ist die Trennung zwischen menschlicher und automatischer Post. Die menschliche Post — die E-Mails, die Mitarbeiter aus Outlook oder Gmail schreiben — gehört auf die Root-Domain und läuft über den Microsoft- oder Google-include; sie ist von Natur aus gut ausgerichtet, weil die Plattform im Namen der Organisation und mit ihrer Domain signiert. Die automatische Post — Marketing-Kampagnen, Rechnungen, Benachrichtigungen, Passwort-Resets — kommt von Drittdiensten und gehört auf dedizierte Subdomains oder wird über ausgerichtetes DKIM eingebunden. Diese Trennung ist nicht nur eine SPF-Optimierung: Sie macht den gesamten Versand lesbarer, denn sie spiegelt sich in den DMARC-Berichten wider, in denen sofort erkennbar ist, ob ein Problem die menschliche Kommunikation oder einen automatischen Fluss betrifft. Wer diese Trennung von Anfang an anlegt, erspart sich das mühsame Entwirren später, wenn alles über eine einzige überladene Root-Domain läuft.

Thomas stellt den Eintrag zusammen

Microsoft, Google und die Drittanbieter unter der Marke von zehn Lookups zu kombinieren ist ein Puzzle. Thomas, der virtuelle CISO, liest die realen Quellen, stellt den optimalen SPF-Eintrag zusammen (Root und Subdomains) und benennt, was als include zu behalten, was auf ausgerichtetes DKIM umzustellen und was auf eine Subdomain zu isolieren ist — für ein sauberes SPF, unter dem Limit und mit DMARC ausgerichtet.

Eine Domain kostenlos analysieren oder ein Konto erstellen für eine SPF-Konfiguration, die hält.