Google a discrètement retiré _netblocks3.google.com de sa chaîne d'enregistrements SPF au début 2026, sans annonce officielle. Pour la plupart des utilisateurs de Google Workspace, rien ne change. Mais pour les propriétaires de domaines ou les équipes informatiques qui ont codé en dur la structure SPF interne de Google, cette mise à jour est un signal pour auditer leurs enregistrements maintenant, avant qu'une configuration défaillante ne provoque un problème de délivrabilité.
Ce que Google a vraiment modifié
Quand vous consultez la référence _spf.google.com, elle pointe vers des sous-enregistrements internes contenant les plages d'IP de Google pour l'envoi d'e-mails. Auparavant, la chaîne incluait trois de ces sous-enregistrements. Google a maintenant discrètement retiré _netblocks3.google.com de cette chaîne, ce qui signifie simplement que le sous-enregistrement ne contient plus d'adresses d'envoi actives. En clair, Google a nettoyé sa structure SPF.
Google n'a fait aucune annonce spectaculaire à ce sujet car, pour la plupart des domaines, rien ne se casse. Le problème ne surgit que si vous avez manuellement copié la structure interne de Google, ce qui pourrait rendre votre enregistrement SPF invalide ou pointant vers une référence inutile. Cela pourrait ne pas casser immédiatement la livraison d'e-mails, mais cela rend votre configuration SPF plus difficile à maintenir.
Qui est réellement à risque
La plupart des utilisateurs de Google Workspace n'ont pas besoin de s'inquiéter de ce changement. Ils s'appuient sur l'entrée standard include:_spf.google.com, et Google gère tout en arrière-plan. Les enregistrements dans ce format continuent de fonctionner exactement comme prévu.
Ceux qui utilisent l'include recommandé par Google ne rencontreront aucun problème. Cependant, les propriétaires de domaines qui ont manuellement copié la structure interne de Google peuvent rencontrer des problèmes. Cela se produit généralement lorsqu'une équipe technique a atteint la limite de 10 recherches DNS et a essayé de la résoudre en codant en dur les références de bloc réseau individuelles au lieu d'utiliser un outil d'aplatissement SPF.
Cette limite de recherche n'est pas une préoccupation mineure. Selon la RFC 7208, l'évaluation SPF est limitée à 10 recherches de mécanisme DNS et 2 recherches vides par vérification. Dépasser l'une ou l'autre limite produit une PermError qui échoue l'authentification pour chaque message du domaine. Et cet échec est silencieux : vos e-mails ne rebondissent pas, ils atterrissent simplement dans les spams ou sont rejetés sans erreur claire que l'expéditeur peut voir.
Le problème du budget de recherche DNS
Cette mise à jour met également en lumière un problème plus large pour les entreprises utilisant plusieurs outils d'envoi. Le seul include:_spf.google.com de Google utilise 4 de vos 10 recherches disponibles, n'en laissant que 6 pour tous les autres expéditeurs. Si vous utilisez également SendGrid, qui consomme 5 recherches, le total combiné atteint 9, et l'ajout d'un expéditeur de plus franchit la limite.
Un domaine qui inclut Google, Microsoft, SendGrid et Mailchimp ensemble atteint 12 recherches. La RFC 7208 plafonne l'évaluation à 10. Le serveur de messagerie récepteur retourne une PermError et chaque message du domaine échoue l'authentification SPF, quel que soit l'expéditeur dont il provient réellement.
Pour les équipes de croissance exécutant des campagnes via une plateforme marketing tout en envoyant des e-mails transactionnels à partir d'un service tiers, c'est un piège réel et courant.
Ce qu'il faut vérifier dans votre enregistrement SPF
Si vous voyez des entrées de bloc réseau individuelles comme _netblocks.google.com, _netblocks2.google.com ou _netblocks3.google.com dans votre enregistrement, supprimez-les. Remplacez-les tous par une seule include pointant vers _spf.google.com, ce qui garde votre configuration propre et automatiquement mise à jour par Google.
Si vous utilisez uniquement Google Workspace pour envoyer des e-mails, l'enregistrement correct est: v=spf1 include:_spf.google.com ~all
Vérifier votre configuration SPF tous les quelques mois pour détecter les entrées obsolètes, les références dupliquées ou les includes cassées aide à prévenir les problèmes d'alignement et de délivrabilité.
Pourquoi cela compte pour le ROI du marketing par e-mail
SPF n'est pas qu'une tâche d'hygiène technique. C'est à la base de votre réputation d'expéditeur. Sans un enregistrement SPF Google Workspace correctement configuré, vos e-mails peuvent être signalés comme spam par les serveurs récepteurs qui ne peuvent pas vérifier votre domaine. Votre domaine ou adresse IP peut être mis en liste noire, rendant la récupération de la délivrabilité significativement plus difficile que de mettre en place l'authentification correctement dès le départ. Et votre réputation de domaine accumule les dommages à mesure que les plaintes de spam s'aggravent avec le temps.
Les exigences de Google pour les expéditeurs en masse, annoncées en octobre 2023 et appliquées à partir de février 2024, exigent que tout domaine envoyant 5 000 messages ou plus par jour aux adresses Gmail s'authentifie avec à la fois SPF et DKIM, publie un enregistrement DMARC d'au moins p=none, maintienne les taux de plainte de spam en dessous de 0,3% et inclue un en-tête de désabonnement en un clic sur le courrier marketing. Ces règles s'appliquent à chaque domaine dans l'en-tête From, et Google rejette maintenant ou route vers les spams tout message d'un expéditeur en masse non conforme.
Mal faire cela coupe directement votre portée livrable, ce qui signifie des taux d'ouverture plus bas, des taux de clics plus bas et un retour plus faible sur chaque campagne que vous envoyez.
Trois étapes à suivre maintenant
SPF seul ne suffit pas. Le combiner avec DKIM et DMARC donne aux serveurs récepteurs la capacité de vérifier correctement les messages et de bloquer les tentatives de phishing utilisant votre domaine. Des outils comme les vérificateurs de recherche SPF, les analyseurs DMARC ou les tableaux de bord de sécurité des e-mails vous aident à surveiller les changements et à détecter les problèmes de configuration dès le début.
Pour agir sur cette mise à jour:
- Consultez votre enregistrement SPF actuel en utilisant un outil comme MXToolbox ou Google Admin Toolbox.
- Si votre enregistrement ne contient que
include:_spf.google.com, aucune modification n'est nécessaire. Google gère les mises à jour pour vous. - Si vous voyez des entrées
_netblocksindividuelles, consolidez-les et vérifiez que votre nombre total de recherches reste en dessous de 10.
Le nettoyage silencieux de sa chaîne SPF par Google est un rappel que l'infrastructure d'authentification des e-mails change sans avertissement. Les domaines qui s'appuient sur des enregistrements construits manuellement continueront à rencontrer ce problème. Utiliser des références include officielles et examiner régulièrement votre configuration est le moyen simple de rester protégé.
