Google verwijderde in begin 2026 stilletjes _netblocks3.google.com uit zijn SPF-recordketen, zonder officiële aankondiging. Voor de meeste Google Workspace-gebruikers verandert er niets. Maar voor domeinbeheerders of IT-teams die Googles interne SPF-structuur handmatig hebben hardcoded, is deze update een signaal om hun records nu te controleren, voordat een slordig geconfigureerde setup deliverability-problemen veroorzaakt.
Wat Google werkelijk heeft gewijzigd
Wanneer je in Googles _spf.google.com-referentie kijkt, wijst deze naar interne sub-records die Googles IP-bereiken voor e-mailverzending bevatten. Eerder bevatte de keten drie van deze sub-records. Google heeft nu stilletjes _netblocks3.google.com uit die keten verwijderd, wat eenvoudig betekent dat de sub-record niet langer actieve verzendadressen bevat. Met andere woorden, Google heeft zijn SPF-structuur opgeruimd.
Google maakte geen groot aantal aankondigingen over deze wijziging omdat voor de meeste domeinen niets breekt. Het probleem komt alleen aan het licht als je Googles interne structuur handmatig hebt gekopieerd, wat je SPF-record ongeldig kan maken of naar een onnodig referentie kan laten wijzen. Het kan e-mailbezorging niet onmiddellijk onderbreken, maar het maakt je SPF-instellingen moeilijker te onderhouden.
Wie loopt werkelijk risico
De meeste Google Workspace-gebruikers hoeven zich geen zorgen te maken over deze wijziging. Zij vertrouwen op de standaard include:_spf.google.com-vermelding, en Google beheert alles achter de schermen. Records in dit formaat werken exact zoals verwacht.
Diegenen die Googles aanbevolen include gebruiken, hebben geen problemen. Domeinbeheerders die Googles interne structuur handmatig hebben gekopieerd, kunnen echter problemen ondervinden. Dit gebeurt meestal wanneer een technisch team tegen de 10 DNS-lookup-limiet aanliep en probeerde dit op te lossen door individuele netblock-referenties hardcoded in te stellen in plaats van een SPF-flatten-tool te gebruiken.
Die lookup-limiet is geen klein probleem. Volgens RFC 7208 is SPF-evaluatie beperkt tot 10 DNS-mechanisme lookups en 2 void lookups per controle. Het overschrijden van een van beide limieten veroorzaakt een PermError die authenticatie voor elk bericht van het domein mislukt. En die fout is stil: je e-mails bounceën niet, zij belanden eenvoudig in spam of worden geweigerd zonder duidelijke fout die de afzender kan zien.
Het DNS-lookup-budgetprobleem
Deze update benadrukt ook een breder probleem voor bedrijven die meerdere verzendtools gebruiken. Googles include:_spf.google.com alleen gebruikt 4 van je 10 beschikbare lookups, waardoor nog slechts 6 voor alle andere afzenders overblijven. Als je ook SendGrid gebruikt, wat 5 lookups verbruikt, bereikt het totaal 9, en het toevoegen van slechts één afzender meer bereikt de limiet.
Een domein dat Google, Microsoft, SendGrid en Mailchimp samen gebruikt, bereikt 12 lookups. RFC 7208 beperkt evaluatie tot 10. De ontvangende mailserver retourneert een PermError en elk bericht van het domein mislukt SPF-authenticatie, ongeacht welke afzender het werkelijk van afkomstig is.
Voor groeiteams die campagnes via een marketingplatform uitvoeren terwijl zij ook transactionele e-mail van een derde service verzenden, is dit een echt en veelvoorkomend probleem.
Wat moet je controleren in je SPF-record
Als je individuele netblock-vermeldingen ziet, zoals _netblocks.google.com, _netblocks2.google.com of _netblocks3.google.com in je record, verwijder ze. Vervang ze allemaal door een enkele include die naar _spf.google.com wijst, wat je configuratie schoon houdt en automatisch door Google wordt bijgewerkt.
Als je alleen Google Workspace gebruikt om e-mail te verzenden, is het juiste record: v=spf1 include:_spf.google.com ~all
Het controleren van je SPF-instellingen elke paar maanden om verouderde vermeldingen, dubbele referenties of verbroken includes op te sporen helpt alignment-problemen en deliverability-problemen te voorkomen.
Waarom dit van belang is voor je e-mailmarketing-ROI
SPF is niet alleen een technische onderhoudstaak. Het ligt aan de basis van je afzenderreputatie. Zonder een correct geconfigureerde Google Workspace SPF-record kunnen je e-mails door ontvangende servers als spam worden gemarkeerd die je domein niet kunnen verifiëren. Je domein of IP-adres kan op een blocklist worden geplaatst, waardoor deliverability-herstel aanzienlijk moeilijker wordt dan authenticatie correct instellen. En je domeinreputatie oploopt schade op doordat spam-klachten zich in de loop van de tijd opstapelen.
Googles vereisten voor bulkafzenders, aangekondigd in oktober 2023 en afgedwongen vanaf februari 2024, vereisen dat elk domein dat 5.000 of meer berichten per dag naar Gmail-adressen verzendt, verificatie met zowel SPF als DKIM moet authenticeren, een DMARC-record van minimaal p=none moet publiceren, spam-klachttarieven onder 0,3% moet houden, en een klik-voor-afmelden-header op marketingmail moet opnemen. Deze regels gelden voor elk domein in de From-header, en Google wijst nu berichten van niet-naleving afleveringen af of stuurt ze naar spam.
Dit verkeerd doen vermindert direct je bezorgbare bereik, wat betekent dat lagere open rates, lagere click-through rates, en lagere return voor elke campagne die je verzendt.
Drie stappen om nu te ondernemen
SPF alleen is niet voldoende. Het combineren ervan met DKIM en DMARC geeft ontvangende servers de mogelijkheid berichten correct te verifiëren en phishing-pogingen met behulp van je domein te blokkeren. Tools zoals SPF-lookup-checkers, DMARC-analyzers of e-mailbeveiligingsdashboards helpen je wijzigingen te monitoren en configuratieproblemen vroegtijdig op te sporen.
Om op deze update in te werken:
- Zoek je huidige SPF-record op met behulp van een tool zoals MXToolbox of Googles Admin Toolbox.
- Als je record alleen
include:_spf.google.combevat, zijn geen wijzigingen nodig. Google beheert updates voor je. - Als je individuele
_netblocks-vermeldingen ziet, consolideer ze en controleer of je totale lookup-aantal onder de 10 blijft.
Googles stille opschoning van zijn SPF-keten is een herinnering dat e-mailautenticatie-infrastructuur zonder waarschuwing verandert. Domeinen die op handmatig samengestelde records vertrouwen, zullen dit probleem blijven tegenkomen. Het gebruik van officiële include-referenties en regelmatig je instellingen controleren is de eenvoudige manier om beschermd te blijven.
