Comment configurer les enregistrements SPF dans Google Workspace

Qu'est-ce qu'un enregistrement SPF Google Workspace ?

Un enregistrement SPF de Google Workspace est un enregistrement DNS de type TXT qui utilise le Sender Policy Framework () pour indiquer aux serveurs de messagerie destinataires quels systèmes sont autorisés à envoyer des e-mails au nom d'un domaine. En termes simples, cela permet à un serveur de réception de vérifier si l'adresse IP de l'expéditeur est autorisée à utiliser votre domaine dans le chemin d'acheminement du message.

Comment Google Workspace utilise le protocole SPF

Dans Google Workspace, l'enregistrement SPF « » autorise Gmail et tout autre service d'envoi agréé à envoyer des e-mails pour le domaine. Si Google Workspace est le seul système de gestion de la réputation ( ) à envoyer des e-mails, la valeur de référence indiquée par Google est la suivante : v=spf1 include:_spf.google.com ~all. 

Il s'agit là de la syntaxe SPF à publier. Les versions informelles telles que « include spfgooglecom », « include spfgooglecom » ou «  vspf1 include spfgooglecom » ne constituent pas, à elles seules, des valeurs valides en production.

Pourquoi les organisations devraient-elles mettre en place le protocole SPF ?

Les organisations devraient configurer le SPF dans Google Workspace, car cela contribue à réduire l'usurpation de domaine en compliquant la tâche des expéditeurs non autorisés qui tenteraient de se faire passer pour ce domaine. 

SPF ne bloque pas à lui seul toutes les menaces par e-mail, mais il aide les serveurs destinataires à déterminer si l'expéditeur est celui attendu. Google recommande également d'utiliser le protocole SPF (), le protocole DKIM( ) et le protocole DMARC afin de renforcer l'authentification et d'assurer une distribution plus fiable des e-mails.

Fonctionnement du SPF de Google Workspace

Le SPF fonctionne en comparant la source d'envoi d'un message à la politique SPF active publiée dans le DNS pour le domaine. Cette politique « » répertorie l'infrastructure de messagerie autorisée de Google ainsi que tous les autres expéditeurs approuvés, ce qui permet au serveur destinataire de vérifier, via , si l'adresse IP de l'expéditeur est autorisée.

Pour Google Workspace, la politique inclut généralement les systèmes de messagerie de Google via include:_spf.google.com, ainsi que et toute autre source approuvée. Les conditions SPF sont évaluées dans l'ordre ; la structure de l'enregistrement est donc tout aussi importante que l' e la liste des expéditeurs.

Les résultats habituels sont les suivants :

• Valide — L'adresse IP d'origine est autorisée à envoyer des e-mails pour ce domaine.
• Échec — La source n'est pas autorisée, ce qui peut indiquer une usurpation d'identité ou une faille dans la politique de sécurité.
• Softfail — La source n'est pas autorisée, mais la politique impose au destinataire de considérer le message comme suspect plutôt que de le rejeter d'emblée. La recommandation standard de Google pour Workspace utilise « ~all », ce qui entraîne un comportement de « softfail » pour les sources non autorisées.
• Neutre — Le domaine ne se prononce pas clairement sur la question de savoir si la source doit passer ou échouer au test SPF.
• Aucun enregistrement SPF n'a été trouvé — Aucune politique SPF applicable n'est disponible pour ce nom d'hôte dans le DNS ; le destinataire ne dispose donc d'aucune indication SPF de la part du domaine.

Étapes de configuration du SPF pour Google Workspace

La configuration d'un enregistrement SPF dans Google Workspace est très simple si vous suivez la bonne procédure. L'essentiel est d'identifier d'abord tous les expéditeurs approuvés , puis de publier et de valider une politique SPF exacte.

Étape 1 : Identifiez tous les expéditeurs d'e-mails de votre domaine

Commencez la configuration du SPF par un inventaire des expéditeurs avant d'effectuer toute modification du DNS. Google Workspace est le principal expéditeur, mais il se peut qu'il ne soit pas le seul. Vous devez également tenir compte des prestataires qui envoient des e-mails au nom de votre domaine, notamment :

• Plateformes tierces
• Services de relais
• Scanners
• Applications internes
• Formulaires Web
• Outils de billetterie

Cette étape est importante, car le SPF doit refléter l'intégralité de votre environnement de messagerie sortante. Si ne serait-ce qu'un seul expéditeur légitime venait à manquer, les messages provenant de cette source risqueraient de ne pas passer le test SPF, d'être signalés comme suspects ou de nuire à leur délivrabilité. Dans les environnements d' s plus complexes, il est recommandé de passer en revue à la fois les systèmes internes et les prestataires externes avant de mettre en production toute modification. 

Étape 2 : Créer l'enregistrement SPF Google Workspace approprié

Une fois tous les expéditeurs identifiés, créez un enregistrement SPF unique et regroupé. Si Google Workspace est le seul expéditeur autorisé, la valeur recommandée par Google est v=spf1 include:_spf.google.com ~all.  Cet enregistrement de référence autorise l'infrastructure « » de Google via « include:_spf.google.com » et applique un « softfail » aux sources non approuvées, ce qui en fait un point de départ « » pour les domaines qui envoient des e-mails exclusivement via Gmail.

S'il existe d'autres expéditeurs, ceux-ci doivent être ajoutés à la même politique SPF. La règle principale est la consolidation : un domaine doit disposer d'une seule politique SPF par nom d'hôte, et non de plusieurs enregistrements SPF. La publication d'enregistrements SPF distincts et autonomes pour Google Workspace et d'autres plateformes peut entraîner l'échec de la validation SPF, car les destinataires ne les considèrent pas comme des politiques distinctes et valides.

Étape 3 : Ajoutez l'enregistrement SPF à votre DNS

Le SPF est publié sous la forme d'un enregistrement TXT DNS via votre hébergeur de domaine ou votre fournisseur DNS, et non via la console d'administration Google. L'interface exacte dépend du fournisseur, mais la procédure est généralement la même : accédez à vos paramètres DNS, créez ou modifiez l'entrée TXT, associez-la au nom d'hôte approprié, puis enregistrez la modification.

Avant de publier, assurez-vous de mettre à jour le domaine et le nom d'hôte corrects. Un mauvais placement est une cause fréquente de problèmes liés au SPF ( ). Il est également important de garder à l'esprit que le SPF est distinct de votre enregistrement MX, car le MX gère le routage de l' du courrier entrant, tandis que le SPF définit quelles sources sont autorisées à envoyer du courrier sortant pour le domaine.

Étape 4 : Associez Google Workspace à des expéditeurs tiers avec prudence

De nombreuses organisations utilisent Google Workspace pour la messagerie de leurs utilisateurs, tout en s'appuyant sur d'autres outils pour l'envoi de messages sortants. Il peut s'agir notamment de plateformes marketing, de systèmes de billetterie, de relais SMTP, d'outils de facturation, de plateformes CRM et d'appareils multifonctions .

Lorsque ces outils existent, ils doivent être intégrés dans la même politique SPF plutôt que d'être ajoutés sous forme d'entrées SPF distinctes. Cela revêt une importance encore plus grande dans les grandes organisations, où différentes équipes peuvent être chargées de gérer différents expéditeurs. En l'absence d' e coordination, les politiques SPF peuvent s'avérer incomplètes ou contradictoires ; il convient donc de considérer le SPF comme une tâche de maintenance continue plutôt que comme une modification ponctuelle du DNS.

Étape 5 : Vérification de la syntaxe SPF et des limites de recherche

Une fois l'enregistrement créé, l'étape suivante consiste à s'assurer qu'il est correctement structuré et qu'il peut être traité sans erreur d' . Cela signifie qu'il faut vérifier à la fois la syntaxe du SPF et le fonctionnement de la recherche DNS avant de considérer la configuration comme terminée.

Vérifier la syntaxe de l'enregistrement SPF

La validation syntaxique est une étape obligatoire de la configuration du SPF. Une fiche peut contenir les sources appropriées et néanmoins être rejetée si le formatage de l' s n'est pas correct. La vérification de la syntaxe des enregistrements SPF permet de s'assurer que la politique démarre correctement, qu'elle utilise uniquement les termes prévus par l' , et qu'elle ne contient pas d'erreurs susceptibles d'empêcher son évaluation. 

Chaque mécanisme SPF doit également être utilisé avec précaution, car la structure de l'enregistrement influe sur la manière dont les serveurs destinataires le traitent.

Surveiller les limites des requêtes DNS

Les équipes doivent également surveiller l'utilisation des requêtes DNS. La RFC 7208 limite l'évaluation SPF à 10 mécanismes et modificateurs de requêtes DNS, , et le dépassement de cette limite peut entraîner une erreur permanente. 

Cela pose souvent problème dans les environnements de grande envergure où plusieurs fournisseurs ajoutent des inclusions imbriquées ; il est donc judicieux de simplifier l'enregistrement, de désactiver les anciens expéditeurs et de revoir toute logique SPF héritée qui ne reflète plus le flux réel d' s par courrier électronique.

Étape 6 : Vérifiez que l'enregistrement SPF a bien été publié

Une fois la publication effectuée, vérifiez que l'enregistrement SPF en production est visible dans le DNS et qu'il correspond exactement à la politique souhaitée. La propagation des modifications apportées à l' DNS peut prendre un certain temps ; par conséquent, le fait d'enregistrer la mise à jour ne signifie pas toujours que la configuration est terminée.

Pour cette étape, les équipes utilisent souvent un outil de vérification du SPF disponible sur ou des outils de la Google Admin Toolbox, tels que Check MX et Messageheader. L'objectif est de vérifier que l'enregistrement TXT SPF figure bien sous le nom d'hôte correct et qu'il correspond à la valeur que vous souhaitiez publier.

Étape 7 : Vérifier les résultats de l'authentification et résoudre les problèmes

Une fois l'enregistrement effectif, vérifiez que le SPF fonctionne correctement en consultant les en-têtes des messages envoyés ou les journaux de messagerie. La fonctionnalité « Messageheader » de Google Admin Toolbox permet d'analyser les en-têtes SMTP et d'afficher les résultats SPF dans les lignes « Authentication-Results » ou « » de l'en-tête « Received-SPF ».

Si les messages ne sont pas transmis comme prévu, commencez par examiner les causes les plus courantes :

• politiques redondantes
• erreurs de syntaxe
• expéditeurs tiers manquants
• mauvais emplacement de l'enregistrement
• Erreurs de publication DNS

Pour bénéficier d'une visibilité en continu sur les performances d'envoi vers Gmail, Postmaster Tools peut également vous aider en proposant des tableaux de bord sur le taux de spam « », la réputation, l'authentification des messages et les erreurs de livraison.

Erreurs courantes à éviter concernant les enregistrements SPF pour Google Workspace

Pour configurer correctement le SPF, il ne suffit pas d'ajouter une entrée DNS. Cela nécessite également un inventaire complet des expéditeurs, une structure claire de la politique de gestion des messages ( ) et un suivi régulier à mesure que votre environnement de messagerie évolue.

Omettre des sources d'envoi légitimes

Une erreur courante consiste à oublier d'inclure toutes les sources d'envoi approuvées. Un domaine peut disposer de Google Workspace ( ), mais il peut tout de même lui manquer une plateforme de gestion des tickets, un outil marketing, un scanner, un relais ou une application permettant d'envoyer des e-mails au nom de ce domaine. Ce type de décalage peut entraîner des échecs du SPF, même lorsque la configuration principale de Workspace semble correcte.

Utilisation de plusieurs enregistrements SPF

Un autre problème courant consiste à publier plusieurs enregistrements SPF au lieu d'une seule politique TXT regroupée. L'outil « » de Google Admin Toolbox, dans la section « Vérification des enregistrements MX », indique qu'il ne doit pas y avoir plus d'un enregistrement SPF. Si un domaine publie plusieurs politiques distinctes, l'évaluation de l' ité SPF peut ne plus fonctionner correctement.

Erreurs de syntaxe et de mise en forme

Des problèmes de syntaxe apparaissent également fréquemment. Cela inclut notamment les problèmes de mise en forme, les qualificatifs incorrects, les mécanismes non valides, le placement erroné du nom d'hôte « », ou encore le fait de tenter d'ajouter de nouvelles entrées à un enregistrement SPF existant et obsolète sans l'avoir préalablement nettoyé. Même de petites erreurs dans la syntaxe des enregistrements SPF ou une mauvaise utilisation du mécanisme SPF peuvent perturber l'authentification.

Adopter une politique trop générale

Les politiques trop générales constituent un autre risque. Autoriser un trop grand nombre de sources peut sembler pratique, mais cela affaiblit la protection offerte par , car cela facilite l'usurpation d'identité si une source autorisée est compromise ou utilisée à mauvais escient. 

Le SPF ne doit inclure que les systèmes qui ont réellement besoin d'envoyer des e-mails au nom du domaine. Cela revêt d'autant plus d'importance lorsque vous gérez également un enregistrement DMARC, car une mauvaise configuration DMARC peut entraîner des problèmes d'authentification et de livraison en aval.

Ne pas tenir compte des limites de recherche et des cas limites

Il faut également tenir compte des contraintes techniques et des cas limites d'exploitation. La limite de 10 requêtes pour la recherche SPF peut entraîner des problèmes d'évaluation de l' lorsque trop d'inclusions imbriquées s'accumulent. Le transfert peut également compromettre la validité du SPF, même lorsque l'expéditeur d'origine a été correctement configuré, car le SPF évalue le chemin emprunté lors de la remise finale plutôt que l'intention initiale seule.

Considérer le SPF comme une tâche ponctuelle

Les dossiers SPF doivent être examinés régulièrement. Les fournisseurs changent, de nouveaux outils viennent s'ajouter et les anciens services sont supprimés. Les recommandations de Google relatives à la politique d' indiquent explicitement qu'il convient de mettre à jour cette politique lorsque de nouveaux serveurs de messagerie ou des expéditeurs tiers sont mis en place. Cette analyse continue d' permet de garantir à la fois la délivrabilité et l'authentification des e-mails à mesure que l'environnement évolue.

Configurer correctement le SPF de Google Workspace

La fiabilité d'un enregistrement SPF de Google Workspace dépend entièrement de la qualité de la base d'expéditeurs qui le sous-tend. Le fait d'identifier toutes les sources d' s de messagerie approuvées avant d'effectuer des modifications DNS permet d'éviter les lacunes susceptibles d'entraîner des échecs SPF, un traitement des messages jugés suspects ou une délivrabilité in ment irrégulière.

Pour les organisations qui souhaitent bénéficier d'une meilleure visibilité sur les sources d'envoi, d'un contrôle plus strict des politiques et d'un accompagnement accru dans l' , afin de réduire les risques liés aux e-mails, Mimecast peut vous aider à étendre votre contrôle au-delà de la simple configuration native.