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

Microsoft 365 und Google Workspace statten die Mehrheit der Organisationen aus, und ihre SPF-Konfiguration ist oft die erste, die man einrichtet. Doch gerade hier starten viele Einträge auf dem falschen Fuß: ein schlecht kopiertes include, zwei Plattformen ohne Methode vermischt oder ein schnell erreichtes Lookup-Limit. Dieser Leitfaden liefert die korrekte SPF-Konfiguration für jede einzelne, für beide gemeinsam und vor allem die Strategie, um deine weiteren Dienstleister hinzuzufügen, ohne dein SPF zu zerbrechen.

Der include von Microsoft 365

Wenn deine Organisation über Microsoft 365 (Exchange Online) versendet, muss dein SPF den Eintrag von Microsoft einschließen:

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

Das ist das offizielle, von Microsoft gepflegte include. Du musst keine IPs von Hand auflisten: Microsoft hält den Eintrag hinter diesem include aktuell, was genau der Sinn des Mechanismus ist. Schließe mit -all ab, wenn Microsoft 365 deine einzige Versandquelle ist.

Der include von Google Workspace

Für Google Workspace (professionelles Gmail) ist das offizielle include:

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

Wie bei Microsoft pflegt Google die IP-Bereiche hinter diesem Eintrag. Achte auf einen klassischen Fehler: Man sieht manchmal historische include oder von Hand kopierte Google-IP-Bereiche — bevorzuge immer das offizielle include:_spf.google.com, stabiler und selbstgepflegt.

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

Denk an die goldene Regel: ein einziger v=spf1-Eintrag pro Domain. Wenn du einen Eintrag für Microsoft und einen weiteren für Google veröffentlichst, erzeugst du 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. Setz die beiden zusammen, und du bist schon bei sechs oder sieben Lookups, bevor du einen einzigen Drittdienstleister hinzugefügt hast.

Das Limit liegt aber bei zehn. Es bleiben dir also nur drei oder vier Lookups für deinen Marketing-Router, deine Rechnungsstellung, dein 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 deine weiteren Dienstleister hinzuzufügen

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

1. Trenn nach Subdomain. Behalte Microsoft 365 oder Google Workspace auf deiner Root-Domain (die menschliche Messaging), und lass das Marketing von news.ton-domaine.fr und das Transaktionale von notif.ton-domaine.fr ausgehen, jedes mit eigenem SPF. Jede Subdomain startet mit einem intakten Budget von zehn Lookups. Das ist bei Weitem die nachhaltigste Strategie.
2. Bevorzuge das DKIM-Alignment für Drittanbieter. Ein Router, der DKIM ausgerichtet signiert (d=ton-domaine.fr), erfüllt DMARC ohne einen SPF-Lookup zu verbrauchen. Das ist oft der beste Weg, einen Dienstleister einzubinden, ohne dein SPF zu belasten.
3. Frier die Dienstleister mit stabilen IPs in ip4: ein, als letztes Mittel, und überwache, dass sie sich nicht ändern.

Vermeide um jeden Preis, 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 dein SPF. Während des Übergangs versendest du von beiden Plattformen: Dein Eintrag muss also beide include gleichzeitig enthalten.

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

Zwei Fallen lauern. Erstens: Erzeug auf keinen Fall zwei getrennte Einträge „für die Dauer der Migration" — das ist der sichere doppelte Eintrag und der PermError, der dazugehört. Zweitens: Vergiss nicht, das include der alten Plattform zu 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: Notier dir von Anfang an das geplante Datum zum Entfernen des alten include, damit es nicht monatelang herumliegt und du eines Tages im PermError aufwachst.

Die spezifischen Fallen

Einige Fehler kommen bei diesen beiden Plattformen wieder:

• Google- oder Microsoft-IPs von Hand kopieren. Du brichst die selbstgepflegte Verbindung und setzt dich Fehlschlägen aus, wenn sich die Bereiche ändern. Bleib bei den offiziellen include.
• Die Versand-Subdomains vergessen. Wenn du von mail.ton-domaine.fr versendest, 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: Denk daran, die DKIM-Signatur auf Microsoft- oder Google-Seite (über deren Konsole) zu aktivieren und deinen DMARC-Eintrag zu veröffentlichen.
• Tenants vermischen. Wenn du mehrere Microsoft-Tenants oder mehrere Google-Domains hast, hat jeder seine Konfiguration; vermisch ihre include nicht, ohne zu prüfen, was du wirklich autorisierst.

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 (entreprise.fr): v=spf1 include:spf.protection.outlook.com -all — nur die menschliche Messaging.
• news.entreprise.fr: v=spf1 include:spf.brevo.com -all — das Marketing, mit DKIM ausgerichtet auf der Subdomain.
• notif.entreprise.fr: 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 deine Domain wirklich geschützt ist, musst du auch die DKIM-Signatur aktivieren (in der Konsole von Microsoft 365 oder Google Workspace) und einen DMARC-Eintrag veröffentlichen. Es ist das Alignment — SPF oder DKIM ausgerichtet mit deinem From: — das den Schutz ausmacht, nicht das SPF allein. Beide Plattformen bieten ihr DKIM in wenigen Klicks an; hör auf keinen Fall beim SPF auf. Sobald die drei Bausteine stehen, strebe p=reject auf DMARC-Seite an, damit die Usurpation deiner Domain wirklich abgewiesen und nicht nur beobachtet wird.

Deine Konfiguration prüfen

Sobald dein Eintrag steht, kontrolliere ihn: 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 dir ihre realen Kosten zu zeigen. Der vollständige Ablauf steht in wie du deinen Eintrag prüfst. Und vergiss das Wesentliche nicht: 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? Strebe -all an, sobald alle deine 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 deinem From:. Für die menschliche Messaging ist das Alignment in der Regel gut; für die Drittanbieter, die „in deinem Namen" über diese Plattformen versenden, prüfe das Alignment in deinen Berichten.

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. Trenn den Router auf eine Subdomain oder wechsle ihn auf ausgerichtetes DKIM.

Kann ich Microsoft 365 und Google Workspace auf dieselbe Domain setzen? Ja, indem du ihre include in einem einzigen Eintrag kombinierst. Überwache nur die Zählung, 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. Konfiguriere beide — 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 für dich 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 für dich aktuell halten.

Diese Erkenntnis ändert die richtige Strategie grundlegend. Da die Plattform-Basis allein schon die Hälfte oder mehr deines 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 deine 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 in deinem Namen und mit deiner 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 deinen gesamten Versand lesbarer, denn sie spiegelt sich in deinen DMARC-Berichten wider, in denen du sofort erkennst, 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.

Lass Thomas deinen Eintrag zusammenstellen

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

Analysiere deine Domain kostenlos → oder erstelle ein Konto für eine SPF-Konfiguration, die hält.