Enregistrement SPF Gmail : Votre guide étape par étape pour 2026

Vous lancez une mise à jour client, un e-mail de recrutement ou une séquence de vente depuis Gmail. Le texte est solide. La liste est propre. Puis, les réponses ralentissent considérablement ou, pire, quelqu’un vous signale que votre message a atterri dans les spams.

Dans les petites équipes, cela pousse généralement à examiner en premier lieu les objets, les modèles et le volume d’envoi. C’est logique. Mais l’une des causes les plus fréquentes se situe en dehors de Gmail, dans vos paramètres DNS. Votre enregistrement SPF décide si les serveurs de messagerie destinataires traitent Gmail comme un expéditeur approuvé pour votre domaine.

Cela compte encore plus si vous recherchez des outils pour vos campagnes basées sur Gmail. Soyez prudent avec les noms de produits qui semblent génériques, en particulier Mail Merge for Gmail. L’expression décrit une catégorie autant qu’un produit spécifique, il est donc facile de lire des conseils de configuration destinés à un autre outil de publipostage et de les appliquer au mauvais système.

Pourquoi votre enregistrement SPF Gmail est important

Une façon utile de concevoir le SPF est de le voir comme une liste d’invités pour votre domaine. Lorsque votre e-mail atteint un autre serveur de messagerie, ce serveur vérifie si l’expéditeur figure sur la liste. Si Gmail y est, votre message a beaucoup plus de chances d’être traité comme légitime. Si Gmail n’y est pas, le destinataire a une raison de se méfier du message avant même que le destinataire ne lise l’objet.

Ce problème de confiance apparaît dans des situations professionnelles courantes. Un fondateur envoie des e-mails d’intégration. Un responsable RH envoie des invitations à des entretiens. Une école envoie des mises à jour d’événements aux parents. Tout semble correct dans Gmail, mais le serveur destinataire ne voit aucune autorisation claire pour votre domaine et commence à traiter ces messages avec plus de prudence.

Ce que le SPF protège

Le SPF remplit deux fonctions à la fois :

• Protection de la délivrabilité : Il aide les serveurs destinataires à reconnaître que Google est autorisé à envoyer des e-mails au nom de votre domaine.
• Protection de la marque : Il rend plus difficile pour quelqu’un d’autre d’usurper votre domaine dans les e-mails sortants.

Le SPF indique au monde extérieur quels systèmes d’envoi parlent au nom de votre domaine et lesquels ne le font pas.

Si vous essayez d’ améliorer le succès de votre marketing par e-mail, c’est l’une des premières vérifications techniques à effectuer. Un meilleur texte ne peut pas compenser un domaine qui n’est pas correctement authentifié.

Pourquoi les petites erreurs causent des problèmes disproportionnés

La partie frustrante est que les problèmes de SPF ne ressemblent souvent pas à des problèmes de SPF. Les messages peuvent toujours être envoyés. Certains destinataires peuvent toujours les recevoir. D’autres peuvent constater un placement en spam, des avertissements ou un filtrage silencieux. Cette incohérence est ce qui déroute les gens.

Si vos e-mails dérivent déjà vers les dossiers de courrier indésirable, il est utile d’associer ce guide de configuration à une procédure pratique sur comment empêcher les e-mails d’aller dans les spams. Le SPF ne résume pas toute l’histoire de la délivrabilité, mais c’est l’une des rares corrections qui améliore directement la confiance au niveau du domaine au lieu de modifier le contenu en espérant le meilleur.

Création de votre enregistrement SPF Gmail principal

Si votre domaine envoie des e-mails uniquement via Gmail ou Google Workspace, la configuration est simple. L’enregistrement SPF officiel de Google est la chaîne exacte documentée dans l’aide de l’administrateur Google Workspace :

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

Cette valeur doit être publiée en tant qu’un seul enregistrement TXT à la racine de votre domaine. Dans la plupart des tableaux de bord DNS, l’hôte est @. Google recommande également un TTL de 3600 secondes (1 heure), et les modifications DNS peuvent prendre jusqu’à 48 heures pour se propager complètement selon votre fournisseur, conformément à cette même documentation Google Workspace.

Que saisir dans le DNS

Que votre DNS soit géré dans GoDaddy, Cloudflare, Namecheap ou un autre fournisseur, les champs correspondent généralement à ceci :

1. Type : TXT
2. Hôte ou Nom : @
3. Valeur ou Contenu : la chaîne SPF ci-dessus
4. TTL : 3600 si votre fournisseur vous permet de le définir manuellement

L’erreur la plus courante ici est de trop réfléchir au type d’enregistrement. De nombreux panneaux DNS ne proposent plus de type d’enregistrement SPF distinct. C’est normal. Vous voulez un enregistrement TXT.

Une visite visuelle rapide peut aider si c’est la première fois que vous modifiez le DNS :

Ce qui fonctionne et ce qui ne fonctionne pas

Voici la version pratique.

• Fonctionne : ajouter un enregistrement TXT à la racine du domaine avec la valeur SPF Gmail exacte.
• Ne fonctionne pas : ajouter des espaces supplémentaires, diviser la valeur en enregistrements SPF distincts ou le publier sous le mauvais hôte, tel qu’un sous-domaine, alors que votre courrier est envoyé depuis le domaine principal.

Règle pratique : Copiez la valeur SPF exactement, publiez-la une fois et résistez à l’envie de créer un deuxième enregistrement SPF plus tard lorsque vous ajoutez un autre expéditeur.

Si vous êtes dans un environnement simple utilisant uniquement Gmail, cela suffit généralement pour effectuer correctement la configuration de votre enregistrement SPF Gmail de base. Enregistrez l’enregistrement, attendez la propagation et vérifiez-le avant de modifier quoi que ce soit d’autre.

Gestion de plusieurs expéditeurs d’e-mails et publipostage

Une configuration courante pour les petites entreprises ressemble à ceci. Le personnel envoie du courrier régulier depuis Google Workspace, le marketing mène des campagnes depuis un outil de publipostage, et un CRM ou un service d’assistance envoie des messages automatisés depuis le même domaine. Le SPF doit couvrir chacun d’entre eux, sinon l’un de ces systèmes commence à échouer à l’authentification.

C’est là que de nombreuses configurations SPF Gmail échouent. L’enregistrement Google de base est facile. La complexité commence lorsque chaque nouvel outil vous demande d’ajouter une autre entrée include: et que personne ne vérifie ce que ces ajouts font à l’enregistrement complet.

Les deux règles les plus importantes

Règle un : publiez un seul enregistrement TXT SPF pour le domaine.

Règle deux : maintenez l’évaluation SPF complète en dessous de 10 recherches DNS. Cette limite inclut les recherches imbriquées à l’intérieur de chaque include:. Un enregistrement peut sembler court dans votre panneau DNS et échouer quand même parce que l’enregistrement SPF d’un fournisseur se développe en plusieurs vérifications supplémentaires. Cette analyse de DMARC Report explique pourquoi le nombre de recherches compte dans la configuration SPF de Gmail.

Les environnements multi-expéditeurs atteignent cette limite plus rapidement que prévu. Google Workspace plus un expéditeur de publipostage, un CRM et une plateforme de support peuvent vous mettre en difficulté même si les instructions de chaque fournisseur sont techniquement correctes individuellement. L’erreur consiste à traiter chaque expéditeur comme un projet DNS distinct au lieu d’une politique d’autorisation combinée.

À quoi ressemble une fusion appropriée

Si Gmail et un autre service approuvé envoient tous deux du courrier pour votre domaine, ajoutez les deux expéditeurs au même enregistrement SPF.

Scénario	Enregistrement SPF fusionné correct
Gmail uniquement	v=spf1 include:_spf.google.com ~all
Gmail plus un expéditeur tiers	v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all
Gmail plus plusieurs expéditeurs	v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all

Ces exemples montrent la structure. Vos valeurs tierces réelles doivent provenir de la documentation de chaque fournisseur. Le point pratique reste inchangé. Un domaine obtient un enregistrement SPF.

Ce qui échoue généralement dans la réalité

Je vois généralement trois modèles d’échec.

• Un deuxième enregistrement SPF est publié. Quelqu’un ajoute une nouvelle entrée TXT commençant par v=spf1 au lieu de modifier celle existante.
• Les anciens services restent autorisés pour toujours. Une entreprise cesse d’utiliser un outil, mais son include: reste dans le DNS et continue de consommer des recherches.
• Le publipostage est traité comme “juste Gmail”. Certains outils envoient via l’infrastructure de Google, tandis que d’autres envoient via leurs propres serveurs ou un fournisseur connecté. Cette différence change la nécessité ou non pour le SPF d’inclure un autre include.

Le troisième point est souvent manqué. Si votre équipe utilise un flux de travail basé sur Sheets, confirmez comment cet outil envoie du courrier avant de toucher au DNS. Un guide sur le publipostage depuis Google Sheets peut vous aider à cartographier le flux de travail, mais le SPF dépend toujours de l’infrastructure d’envoi derrière ce flux de travail.

Comment rester en dessous de la limite de 10 recherches

Commencez par un inventaire des expéditeurs. Listez chaque système autorisé à envoyer du courrier en tant que votre domaine. Incluez les plateformes marketing, les CRM, les outils de support, les applications de facturation, les formulaires de site Web et tout produit de publipostage.

Ensuite, réduisez drastiquement.

Supprimez les expéditeurs que vous n’utilisez plus. Vérifiez si deux outils envoient via le même fournisseur, ce qui peut rendre un include inutile. Si un fournisseur propose plus d’une option SPF, choisissez celle qu’il documente pour votre cas d’utilisation plutôt que de coller chaque enregistrement que vous pouvez trouver.

Si l’enregistrement est toujours trop volumineux, la réponse n’est pas un deuxième enregistrement SPF. La réponse est de réduire le nombre de chemins d’envoi autorisés, ou dans certains cas, d’utiliser un sous-domaine pour un flux de courrier distinct afin que l’enregistrement SPF du domaine principal reste gérable.

Si vous ajoutez un nouvel expéditeur, traitez-le comme une révision de changement DNS. Confirmez que l’expéditeur est toujours nécessaire, mettez à jour l’enregistrement SPF unique et vérifiez le nombre de recherches avant d’enregistrer.

Comment vérifier que votre enregistrement SPF fonctionne

Une fois que vous avez enregistré l’enregistrement, ne supposez pas que vous avez terminé. La vérification est l’endroit où vous attrapez les erreurs silencieuses, surtout si votre panneau DNS a accepté l’entrée mais que la syntaxe ou le nombre de recherches est toujours incorrect.

Utilisez d’abord un validateur

Commencez par un vérificateur SPF public tel que MxToolbox ou dmarcian SPF Surveyor. Ils sont utiles car ils ne se contentent pas de confirmer qu’un enregistrement TXT existe. Ils inspectent également la structure et, dans le cas de recherches plus avancées, vous aident à voir si vos includes créent trop de recherches DNS.

Entrez votre nom de domaine et examinez attentivement le résultat. Vous recherchez trois choses :

• L’enregistrement est trouvé : l’outil peut voir votre enregistrement TXT SPF dans le DNS public.
• La syntaxe est valide : aucun mécanisme mal formé, espaces parasites ou entrées SPF en double.
• La chaîne est gérable : les includes ne se développent pas en un résultat cassé.

À quoi ressemble un bon résultat

Une vérification saine semble généralement ennuyeuse, et c’est exactement ce que vous voulez. L’outil trouve un enregistrement SPF, l’analyse proprement et ne signale pas d’erreur permanente.

Un résultat d’échec tombe généralement dans l’une de ces catégories :

• Aucun enregistrement SPF trouvé : l’enregistrement ne s’est pas encore propagé, a été enregistré sous le mauvais hôte ou n’a jamais été publié.
• Plusieurs enregistrements SPF trouvés : vous avez ajouté un deuxième enregistrement TXT v=spf1 au lieu de modifier celui existant.
• Trop de recherches : votre liste combinée d’expéditeurs est trop grande ou trop imbriquée.

Vérifiez également un e-mail en direct

Les validateurs sont bons pour la structure. Un vrai message confirme le comportement.

Envoyez un e-mail de test vers une boîte de réception Gmail à laquelle vous avez accès. Ouvrez le message, utilisez l’option de Gmail pour afficher l’original du message et inspectez les résultats de l’authentification. Si le SPF réussit, c’est un signe fort que votre DNS public et votre chemin d’envoi réel sont alignés.

Les outils de validation vous disent si l’enregistrement DNS est publiable. Un test en direct vous dit si votre flux de courrier réel correspond à la politique DNS.

Si le validateur réussit mais que les messages en direct se comportent toujours mal, le problème peut se situer ailleurs dans votre pile d’authentification plutôt que dans le SPF seul.

Dépannage des erreurs courantes d’enregistrement SPF

Les problèmes de SPF deviennent généralement évidents juste après un changement. Une petite entreprise commence à envoyer des propositions depuis Google Workspace, ajoute un outil de publipostage, puis remarque que les réponses ralentissent ou que les messages atterrissent dans les spams. En pratique, le problème est souvent une erreur DNS, pas un problème de courrier complexe.

Plusieurs enregistrements SPF trouvés

Symptôme : votre validateur signale plusieurs enregistrements SPF, ou les serveurs destinataires renvoient une erreur SPF permanente.

Cause : votre domaine a plus d’un enregistrement TXT commençant par v=spf1. Je vois cela après qu’une entreprise ajoute un deuxième expéditeur, tel qu’un CRM ou une plateforme de prospection, et que le guide de configuration du nouveau fournisseur est suivi à la lettre. Le SPF ne fusionne pas ces enregistrements. Les destinataires voient le conflit et le traitent comme invalide.

Solution : gardez un enregistrement SPF pour le domaine et intégrez chaque expéditeur approuvé dans cette seule entrée TXT. Si vous avez déjà des enregistrements séparés, choisissez-en un comme maître, combinez les mécanismes nécessaires, puis supprimez les extras.

Trop de recherches DNS

Symptôme : l’enregistrement semble complet, mais le SPF échoue toujours avec une limite de recherche ou un résultat permerror.

Cause : les vérifications SPF ne peuvent suivre qu’un nombre limité de recherches DNS. C’est l’erreur que les guides SPF Gmail de base ignorent souvent. Elle apparaît dans des environnements réels où Google Workspace n’est qu’un expéditeur parmi plusieurs, surtout si vous utilisez également un logiciel de publipostage, un service d’assistance, un système de facturation et une plateforme marketing depuis le même domaine. Chaque include: peut entraîner plus d’includes en dessous, donc un enregistrement qui semble court peut toujours dépasser la limite.

Solution : réduisez la liste des expéditeurs avant d’essayer quoi que ce soit d’astucieux. Supprimez les services qui n’envoient plus de courrier pour votre domaine. Demandez à chaque fournisseur si tous ses includes publiés sont nécessaires pour votre cas d’utilisation. Si votre pile est toujours trop grande, divisez les flux de courrier par sous-domaine. Par exemple, gardez les e-mails réguliers du personnel sur votre domaine principal et déplacez la prospection ou le courrier en masse vers un sous-domaine avec sa propre politique SPF. Cette approche est souvent la correction la plus propre dans une configuration multi-expéditeurs car elle réduit la pression sur les recherches et empêche un enregistrement gonflé de tout casser.

Problèmes de syntaxe et enregistrements manquants

Symptôme : l’enregistrement existe dans le DNS, mais le validateur signale des erreurs de formatage, ou aucun enregistrement SPF n’est trouvé du tout.

Cause : cela provient généralement d’un mauvais copier-coller, d’une mauvaise valeur d’hôte ou de la publication de la chaîne SPF dans le mauvais champ. Dans cPanel, GoDaddy, Cloudflare et les remplaçants de Google Domains, les étiquettes diffèrent juste assez pour confondre les administrateurs novices. Un enregistrement destiné au domaine racine pourrait être saisi sous www, ou la valeur TXT pourrait être divisée incorrectement.

Solution : comparez la valeur TXT publiée avec l’enregistrement prévu caractère par caractère. Confirmez que l’hôte est correct pour le domaine que vous authentifiez et assurez-vous d’avoir créé un enregistrement TXT, et non un autre type d’enregistrement. Si la syntaxe est correcte mais que le courrier échoue toujours, passez en revue la configuration de l’authentification des e-mails pour les domaines personnalisés plus large, car l’enregistrement SPF peut être valide alors qu’un autre contrôle d’authentification cause le problème.

Un ordre de dépannage pratique

Utilisez cet ordre lorsque le SPF échoue :

1. Vérifiez les enregistrements SPF en double. C’est le problème le plus rapide à confirmer et à corriger.
2. Examinez attentivement le texte de l’enregistrement. Recherchez les fautes de frappe, les espaces manquants, les guillemets supplémentaires ou le mauvais hôte.
3. Cartographiez chaque service d’envoi. Incluez Google Workspace, les outils de publipostage, les CRM, les plateformes de support et tout ce qui envoie en tant que votre domaine.
4. Comptez les includes lourds en recherches. Si la liste est encombrée, simplifiez-la ou déplacez certains expéditeurs vers un sous-domaine.

Cet ordre permet de gagner du temps car il correspond à la façon dont le SPF échoue généralement sur le terrain. Les petites équipes supposent souvent que le nouvel outil a causé le problème, mais l’ancien encombrement DNS est tout aussi courant. Si vous souhaitez une liste de contrôle opérationnelle plus large pendant que vous nettoyez cela, le guide sur les meilleures pratiques de sécurité des e-mails de Simply Tech Today est une référence utile.

Au-delà du SPF : vos prochaines étapes dans l’authentification des e-mails

Une petite entreprise peut publier un enregistrement SPF correct et voir quand même ses messages atterrir dans les spams une fois que les factures, la prospection et les suivis commencent à partir de différents systèmes. Cela se produit généralement dans les configurations mixtes, surtout lorsque Google Workspace gère le courrier quotidien et qu’un autre outil envoie des campagnes ou du publipostage depuis le même domaine.

Le SPF ne couvre qu’une partie de la décision prise par un serveur de messagerie destinataire. Il vérifie si le serveur expéditeur est autorisé à utiliser votre domaine. Cela compte, mais cela ne prouve pas que le message a été signé correctement et ne dit pas au serveur destinataire quoi faire lorsque l’authentification échoue.

C’est là que DKIM et DMARC entrent en jeu, et ils comptent encore plus dans les environnements multi-expéditeurs.

DKIM ajoute une signature cryptographique au message afin que les serveurs destinataires puissent confirmer que le message est légitime et n’a pas été modifié après avoir quitté votre système. DMARC se place au-dessus du SPF et de DKIM et indique aux fournisseurs de messagerie comment évaluer ces vérifications pour votre domaine. Il vous donne également des rapports, qui sont souvent la première vue claire d’un expéditeur dont vous aviez oublié qu’il utilisait votre domaine.

C’est le point que de nombreux guides SPF de base manquent. Si vous utilisez Google Workspace, un outil de publipostage, un CRM et une plateforme de support, le SPF peut devenir difficile à maintenir en raison de la limite de 10 recherches. DKIM aide à réduire la dépendance au SPF seul, et DMARC vous donne une couche de politique afin que votre domaine ne soit pas jugé uniquement par un enregistrement TXT encombré.

Pour la prochaine étape technique après le SPF, consultez ce guide sur l’ authentification des e-mails pour les domaines personnalisés. Il donne le chemin de configuration pratique pour DKIM et DMARC une fois que votre enregistrement SPF est en place.

Si vous souhaitez une liste de contrôle opérationnelle plus large, le guide sur les meilleures pratiques de sécurité des e-mails de Simply Tech Today est une lecture complémentaire utile.

Le point pratique est simple. Le SPF met en place l’autorisation. DKIM prouve l’intégrité du message. DMARC vous donne le contrôle, la visibilité et un moyen plus sûr de gérer un domaine qui envoie du courrier depuis plus d’un système.