Configuration de l'enregistrement SPF pour Gmail : guide pratique pour Google Workspace

Pour configurer SPF pour Google Workspace, publiez un enregistrement TXT DNS sur votre domaine racine contenant v=spf1 include:_spf.google.com ~all. Le mécanisme include:_spf.google.com autorise tous les serveurs de messagerie de Google à envoyer en votre nom. Ajoutez des mécanismes include ou ip4/ip6 supplémentaires pour tout service tiers qui envoie également des e-mails depuis votre domaine, tout en restant dans la limite des 10 requêtes DNS définie par la RFC 7208.

Selon les exigences de Google de février 2024 relatives aux expéditeurs en masse, tout domaine envoyant plus de 5 000 messages par jour à des utilisateurs de Gmail doit disposer d’une authentification SPF ou DKIM et d’une politique DMARC publiée d’au moins p=none, ce qui fait d’une configuration SPF correcte une exigence de conformité, et pas seulement une bonne pratique.

« Les administrateurs de Google Workspace héritent souvent d’enregistrements SPF comportant déjà 8 à 9 includes. Ajouter _spf.google.com les fait dépasser la limite de 10 requêtes, et soudain les messages légitimes commencent à être rejetés », explique Brad Slavin, directeur général d’AutoSPF. « La solution n’est pas de supprimer des expéditeurs, mais d’aplatir l’enregistrement pour que chaque service reste autorisé dans la limite de la RFC 7208. »

Pour des instructions de configuration couvrant Google Workspace et des dizaines d’autres plateformes, consultez notre guide de configuration des enregistrements SPF.

Le Sender Policy Framework (SPF) est un contrôle d’authentification des e-mails fondamental qui aide Gmail et les autres fournisseurs à vérifier quels serveurs sont autorisés à envoyer du courrier au nom de votre domaine. Pour les organisations utilisant Google Workspace, un enregistrement SPF correctement publié améliore la délivrabilité des e-mails, renforce la sécurité et soutient la protection des données en signalant la confiance aux systèmes destinataires et en dissuadant le spoofing et le phishing.

Impact sur l’activité et la conformité

• L’authentification des e-mails réduit le risque d’usurpation d’identité et soutient les obligations légales et de conformité liées à la confirmation d’identité et au contrôle d’accès. Elle complète DMARC et DKIM dans le cadre d’une stratégie de sécurité multicouche.

• De solides pratiques de gestion du domaine — comme s’assurer que l’enregistrement SPF est exact dans le DNS — protègent la réputation de la marque et réduisent la charge du service d’assistance liée au support et au dépannage.

• Les administrateurs peuvent utiliser la console d’administration de Google Workspace pour configurer et gérer les services, vérifier la configuration et exploiter les rapports et la surveillance afin de suivre l’alignement de l’authentification, ce qui facilite la préparation aux audits.

Avantages opérationnels pour les administrateurs

• Moins de faux positifs et un meilleur placement en boîte de réception avec Gmail grâce à des signaux d’autorisation clairs.

• Une gestion des utilisateurs plus simple, en particulier lors d’une migration de données ou du déploiement d’applications qui envoient du courrier, car les politiques sont centralisées dans le DNS plutôt que réparties sur les terminaux.

• S’aligne sur les paramètres de sécurité de la gestion des appareils et des applications internes, ce qui réduit les risques de shadow IT liés aux applications et intégrations non contrôlées.

Comment fonctionne SPF : mécanismes, qualificateurs et principes essentiels de l’enregistrement TXT DNS

SPF se définit au moyen d’un enregistrement TXT DNS sur le domaine racine. Les destinataires évaluent l’enregistrement SPF du domaine MAIL FROM pour déterminer les résultats de réussite ou d’échec. Si l’un des mécanismes ci-dessous ne vous est pas familier, notre glossaire des termes SPF les définit.

Mécanismes SPF : les blocs de construction

Parmi les mécanismes courants figurent :

• a et mx : autorisent les hôtes A ou MX du domaine à envoyer.
• ip4 et ip6 : autorisent des plages d’adresses IP explicites.
• include : délègue à l’enregistrement SPF d’un autre domaine (par exemple, celui de Google).
• exists et ptr : options avancées ou héritées ; à utiliser avec parcimonie.
• all : un mécanisme fourre-tout qui doit apparaître en dernier.

Qualificateurs et sémantique de la politique

• + (pass) est implicite lorsqu’il est omis.
• ~ (softfail) signale « non autorisé, mais accepter et signaler ».
• - (fail) rejette d’emblée les sources non autorisées.
• ? (neutral) ne fait aucune affirmation.

La plupart des organisations commencent par ~all afin de limiter les perturbations, puis durcissent la politique en -all une fois la cartographie des expéditeurs terminée. Pour un examen plus approfondi des différents types d’enregistrements SPF, consultez notre guide complet.

Principes essentiels de l’enregistrement TXT DNS pour les administrateurs

• Placez l’enregistrement SPF dans le DNS sous la forme d’une seule chaîne TXT commençant par v=spf1.
• Respectez la limite de 10 requêtes DNS réparties entre include, a, mx, ptr et exists.
• Maintenez l’enregistrement sous 255 caractères par chaîne (utilisez des découpages entre guillemets si nécessaire).
• Coordonnez les changements dans le calendrier de modifications de la console d’administration afin que les administrateurs sachent quand les chemins de messagerie sont ajustés.
• Utilisez des rapports et des outils de surveillance pour valider les changements et résoudre les erreurs de manière proactive.

Cartographiez vos expéditeurs : Google, plateformes tierces et sources réseau

Avant de configurer SPF, recensez tous les systèmes qui envoient en utilisant votre domaine. Il s’agit d’un élément central de la gestion du domaine, qui réduit les dérives à mesure que les applications et intégrations évoluent.

En interne : Google et votre réseau

• Services Gmail et Google Workspace : autorisez-les avec include:_spf.google.com.

Les services Google qui envoient via Apps Script ou un flux de travail d’application cloud s’authentifient également grâce à l’infrastructure SPF de Google lorsqu’ils sont correctement acheminés.

• Sortie de votre réseau : si des appareils ou des relais envoient directement, ajoutez des mécanismes ip4/ip6. Documentez la responsabilité de la gestion des appareils afin que la gestion des utilisateurs et le service informatique sachent qui maintient ces adresses IP.

Applications et intégrations tierces

De nombreuses applications tierces envoient des e-mails système, des alertes ou des notifications en votre nom. On peut citer 15Five, 4me, Adaptive Insights, Adobe Acrobat Sign, Aha!, Amazon Business, des services sur Amazon Web Services, AppDynamics, Asana, Atlassian Cloud, Automox, BambooHR, Betterworks, et bien d’autres. Pour chacune :

• Vérifiez si elles fournissent un include SPF (à privilégier) ou si elles nécessitent des adresses IP dédiées.
• Dans l’administration de Marketplace, gérez les applications Marketplace et suivez les applications installées par l’administrateur, les demandes d’accès des applications et le statut des applications tierces vérifiées.
• Appliquez les pratiques d’OAuth 2.0 et de SSO — SAML, SSO basé sur SAML, applications SAML intégrées ou application SAML personnalisée via un IdP tiers — pour autoriser l’accès et contrôler l’accès des applications. Maintenez les certificats SAML, ajustez les paramètres SSO et surveillez le flux de connexion SSO.
• Configurez les applications tierces avec une liste d’autorisation d’applications, examinez régulièrement l’accès des applications et activez la révocation automatique des jetons lorsque cela est pris en charge, afin de gérer l’accès aux données de manière responsable.

Selon un rapport Egress de 2025, 94 % des organisations ont subi des incidents de sécurité liés à la messagerie au cours des 12 derniers mois, dont beaucoup imputables à des enregistrements SPF mal configurés ou manquants pour des expéditeurs tiers ajoutés sans mise à jour du DNS.

Liste de contrôle de la gouvernance des intégrations

• Cartographiez les attributs personnalisés et le schéma utilisateur afin de garantir l’identité d’expéditeur correcte dans les notifications.
• Vérifiez que les applications web privées ou les applications internes n’envoient pas de courrier externe, sauf autorisation explicite.
• Documentez les politiques dans des guides de formation pour une administration cohérente et un support et un dépannage plus rapides.

Localisez votre hébergeur DNS et accédez-y : prérequis et autorisations

Votre enregistrement SPF réside dans le DNS. Assurez-vous de savoir où est hébergée la zone de votre domaine et qui dispose des droits pour la modifier.

Identifiez le fournisseur DNS et la zone d’autorité

• Consultez le tableau de bord de votre registraire ou de votre hébergeur, ou interrogez les enregistrements NS pour déterminer où le DNS est géré. De nombreuses organisations utilisent des services DNS cloud tels que ceux proposés sur Amazon Web Services.
• Évaluez séparément les besoins en sous-domaines (marketing.example.com par rapport à example.com) et assurez une gestion cohérente du domaine entre les unités opérationnelles.
• Si des fournisseurs provisionnent des sous-domaines ou des CNAME, coordonnez-vous avec eux pour éviter la fragmentation du SPF.

Confirmez les rôles, les accès et le contrôle des changements

• Assurez-vous qu’un super-administrateur et des administrateurs désignés disposent d’un contrôle d’accès à la fois au portail DNS et à la console d’administration.
• Alignez la propriété de la facturation et des abonnements afin que les changements ne soient pas bloqués lors des renouvellements.
• Utilisez une vue d’ensemble de la mise en œuvre et un ticket de changement, planifiez une fenêtre de maintenance et prévoyez une surveillance de la propagation.

Hygiène des processus et observabilité

• Consignez chaque changement DNS ; capturez les valeurs de l’enregistrement SPF avant et après.
• Utilisez des rapports et la surveillance pour vérifier les résultats d’authentification dans Gmail après le changement.
• Le cas échéant, validez les impacts sur la synchronisation des données si des intégrations réécrivent le MAIL FROM ou acheminent le courrier via différentes passerelles.

Construisez l’enregistrement de base pour Google Workspace

Le point de départ le plus sûr pour la plupart des locataires Google Workspace consiste à publier l’include de Google et le softfail. Si vous débutez, notre guide sur comment créer un enregistrement SPF couvre les bases. Cela autorise Gmail et les principaux expéditeurs Google, tout en vous permettant d’identifier les retardataires :

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

Une fois que vous avez cartographié tous les expéditeurs tiers et confirmé leurs includes SPF, ajoutez-les à l’enregistrement. Si vous dépassez la limite de 10 requêtes, envisagez l’aplatissement SPF pour résoudre les includes imbriqués en adresses IP — ou utilisez AutoSPF pour automatiser l’aplatissement et maintenir votre enregistrement conforme sans gestion manuelle du DNS.