Google hat Anfang 2026 stillschweigend _netblocks3.google.com aus seiner SPF-Record-Kette entfernt, ohne offizielle Ankündigung. Für die meisten Google Workspace-Nutzer ändert sich nichts. Doch für Domain-Besitzer oder IT-Teams, die Googles interne SPF-Struktur manuell hart codiert haben, ist dieses Update ein Signal, ihre Einträge jetzt zu überprüfen, bevor eine fehlerhafte Konfiguration zu Zustellungsproblemen führt.
Was Google tatsächlich geändert hat
Wenn Sie in Googles _spf.google.com-Referenz schauen, verweist sie auf interne Untereinträge, die Googles IP-Bereiche für den E-Mail-Versand enthalten. Früher umfasste die Kette drei dieser Untereinträge. Google hat nun stillschweigend _netblocks3.google.com aus dieser Kette entfernt, was einfach bedeutet, dass der Untereintrag keine aktiven Versandadressen mehr enthält. Kurz gesagt: Google hat seine SPF-Struktur bereinigt.
Google machte keine großen Ankündigungen über diese Änderung, da für die meisten Domains nichts bricht. Das Problem tritt nur auf, wenn Sie Googles interne Struktur manuell kopiert haben, was Ihren SPF-Record ungültig oder auf eine unnötige Referenz verweisend machen könnte. Es könnte den E-Mail-Versand nicht sofort unterbrechen, macht aber Ihr SPF-Setup schwerer zu warten.
Wer ist tatsächlich gefährdet
Die meisten Google Workspace-Nutzer müssen sich über diese Änderung keine Gedanken machen. Sie verlassen sich auf den Standard-Eintrag include:_spf.google.com, und Google verwaltet alles im Hintergrund. Records in diesem Format funktionieren weiterhin genau wie erwartet.
Wer Googles empfohlenem Include folgt, wird keine Probleme haben. Domain-Besitzer, die Googles interne Struktur manuell kopiert haben, könnten jedoch auf Schwierigkeiten stoßen. Dies geschieht typischerweise, wenn ein technisches Team das 10 DNS-Lookup-Limit erreicht hat und versucht hat, es zu umgehen, indem es einzelne Netblock-Referenzen hart codiert hat, statt ein SPF-Flattening-Tool zu nutzen.
Dieses Lookup-Limit ist kein untergeordnetes Anliegen. Gemäß RFC 7208 ist die SPF-Auswertung auf 10 DNS-Mechanismus-Lookups und 2 Void-Lookups pro Überprüfung begrenzt. Das Überschreiten beider Limits führt zu einem PermError, der die Authentifizierung für jede Nachricht der Domain fehlschlagen lässt. Und dieser Fehler ist lautlos: Ihre E-Mails werden nicht abgelehnt, sondern landen einfach im Spam oder werden ohne klare Fehlermeldung abgelehnt, die der Absender sehen kann.
Das DNS-Lookup-Budget-Problem
Dieses Update verdeutlicht auch ein breiteres Problem für Unternehmen, die mehrere Versandtools nutzen. Googles include:_spf.google.com allein verbraucht 4 Ihrer 10 verfügbaren Lookups und hinterlässt nur 6 für alle anderen Versender. Wenn Sie auch SendGrid nutzen, das 5 Lookups verbraucht, erreicht die Gesamtsumme 9, und das Hinzufügen nur eines weiteren Versenders schlägt fehl.
Eine Domain, die Google, Microsoft, SendGrid und Mailchimp zusammen enthält, erreicht 12 Lookups. RFC 7208 begrenzt die Auswertung auf 10. Der empfangende Mailserver gibt einen PermError zurück, und jede Nachricht der Domain schlägt bei der SPF-Authentifizierung fehl, unabhängig davon, von welchem Versender sie tatsächlich stammt.
Für Growth Teams, die Kampagnen über eine Marketing-Plattform durchführen und gleichzeitig Transaktions-E-Mails von einem anderen Dienst versenden, ist dies eine echte und häufige Falle.
Was Sie in Ihrem SPF-Record überprüfen sollten
Wenn Sie einzelne Netblock-Einträge wie _netblocks.google.com, _netblocks2.google.com oder _netblocks3.google.com in Ihrem Record sehen, entfernen Sie sie. Ersetzen Sie alle durch einen Include, der auf _spf.google.com verweist, was Ihre Konfiguration sauber und automatisch von Google aktualisiert hält.
Wenn Sie nur Google Workspace zum E-Mail-Versand nutzen, ist der korrekte Record: v=spf1 include:_spf.google.com ~all
Die Überprüfung Ihres SPF-Setups alle paar Monate, um veraltete Einträge, doppelte Referenzen oder fehlerhafte Includes zu erkennen, hilft Zustellungsprobleme zu vermeiden.
Warum das für Ihre E-Mail-Marketing-ROI wichtig ist
SPF ist nicht nur eine technische Hygiene-Aufgabe. Es ist die Grundlage Ihres Sender-Rufs. Ohne ein richtig konfiguriertes Google Workspace SPF-Record können Ihre E-Mails von Empfänger-Servern, die Ihre Domain nicht verifizieren können, als Spam gekennzeichnet werden. Ihre Domain oder IP-Adresse kann auf die schwarze Liste gesetzt werden, was die Wiederherstellung der Zustellbarkeit erheblich schwieriger macht als die korrekte Authentifizierung von Anfang an. Und Ihr Domain-Ruf nimmt Schaden an, wenn sich Spam-Beschwerden im Laufe der Zeit anhäufen.
Googles Anforderungen für Massen-Versender, angekündigt im Oktober 2023 und durchgesetzt ab Februar 2024, erfordern, dass jede Domain, die 5.000 oder mehr Nachrichten pro Tag an Gmail-Adressen versendet, sich mit SPF und DKIM authentifiziert, einen DMARC-Record mit mindestens p=none veröffentlicht, Spam-Beschwerdequoten unter 0,3% hält und eine One-Click-Abmelde-Kopfzeile bei Marketing-Mails hinzufügt. Diese Regeln gelten für jede Domain im From-Header, und Google lehnt nun Nachrichten von nicht konformen Massen-Versender ab oder leitet sie in den Spam weiter.
Wenn Sie das falsch machen, sinkt Ihre erreichbare Reichweite direkt, was zu niedrigeren Öffnungsquoten, niedrigeren Click-Through-Raten und niedriger Return-on-Investment für jede Kampagne führt, die Sie versenden.
Drei Schritte zum Handeln
SPF allein reicht nicht aus. Die Kombination mit DKIM und DMARC ermöglicht es Empfänger-Servern, Nachrichten richtig zu verifizieren und Phishing-Versuche mit Ihrer Domain zu blockieren. Tools wie SPF-Lookup-Checker, DMARC-Analyzer oder E-Mail-Sicherheits-Dashboards helfen Ihnen, Änderungen zu überwachen und Konfigurationsprobleme frühzeitig zu erkennen.
Um auf dieses Update zu reagieren:
- Suchen Sie Ihren aktuellen SPF-Record mit einem Tool wie MXToolbox oder Googles Admin Toolbox auf.
- Wenn Ihr Record nur
include:_spf.google.comenthält, sind keine Änderungen erforderlich. Google verwaltet Updates für Sie. - Wenn Sie einzelne
_netblocks-Einträge sehen, konsolidieren Sie sie und überprüfen Sie, dass Ihre Gesamtanzahl der Lookups unter 10 bleibt.
Googles stille Bereinigung seiner SPF-Kette ist eine Erinnerung daran, dass sich E-Mail-Authentifizierungsinfrastruktur ohne Vorwarnung ändert. Domains, die sich auf manuell konstruierte Records verlassen, werden dieses Problem immer wieder haben. Die Verwendung offizieller Include-Referenzen und die regelmäßige Überprüfung Ihres Setups ist der unkomplizierte Weg, um geschützt zu bleiben.
