Un message envoyé depuis Gmail peut être bien rédigé et pourtant finir dans les indésirables. La cause se trouve parfois dans le DNS de messagerie : le serveur destinataire ne peut pas confirmer que Google est autorisé à envoyer au nom de votre domaine.
Une configuration SPF Google correctement publiée clarifie cette autorisation d’envoi d’e-mails et contribue à la sécurité des e-mails. Elle ne garantit pas, à elle seule, la livraison en boîte de réception, mais elle constitue une vérification essentielle avant d’ajuster vos campagnes.
À retenir :
- Autorisation explicite des serveurs de messagerie Google pour votre domaine
- Un seul enregistrement SPF publié en TXT dans la zone DNS
- Prise en compte des expéditeurs tiers et des recherches DNS
- Validation SPF avant tout diagnostic approfondi de délivrabilité
Configuration SPF Google Workspace dans le DNS
Pour commencer simplement, vérifiez où votre domaine est hébergé et qui peut modifier sa zone DNS. Selon Google Workspace, le point de départ pour un domaine utilisant les services Google est un enregistrement TXT contenant v=spf1 include:_spf.google.com ~all.
Publier l’enregistrement SPF à la racine du domaine
Dans le panneau DNS, créez un enregistrement TXT au nom de domaine racine, souvent désigné par « @ ». Selon Google, cet enregistrement autorise les serveurs de messagerie Google à envoyer des messages pour votre domaine.
Le champ TTL peut rester sur sa valeur par défaut, ou être réglé à 3 600 secondes si votre fournisseur le permet. La propagation dépend du service DNS : attendez que la modification soit visible publiquement avant d’évaluer son effet.
Les champs courants à vérifier lors de la saisie :
- Type : TXT, et non un ancien type SPF distinct
- Nom : racine du domaine, généralement « @ »
- Valeur : chaîne SPF officielle de Google, sans modification
- TTL : valeur par défaut ou 3 600 secondes si disponible
Champ DNS
Valeur de départ
À vérifier
Type
TXT
Un enregistrement de politique SPF
Nom
@
Le domaine racine concerné
Contenu
v=spf1 include:_spf.google.com ~all
La chaîne exacte, sans doublon
TTL
Valeur par défaut ou 3 600 secondes
Le réglage proposé par l’hébergeur
Plusieurs expéditeurs et limites de l’enregistrement SPF
Une fois Google autorisé, l’inventaire des autres expéditeurs devient déterminant. Un CRM, une plateforme de publipostage ou un outil de facturation peut envoyer depuis une infrastructure différente et nécessiter sa propre autorisation.
Fusionner les services autorisés dans une seule politique
Selon la RFC 7208, un domaine ne doit pas publier plusieurs enregistrements SPF distincts, et l’évaluation est limitée à dix recherches DNS. Ajoutez les mécanismes demandés par chaque fournisseur dans l’entrée existante, après vérification de sa documentation.
Cette règle évite une erreur fréquente : copier la configuration d’un nouvel outil comme un deuxième enregistrement TXT. Par exemple, Google et un prestataire tiers doivent figurer dans une politique combinée, sans dépasser la limite de recherches.
Exemples de structure, à adapter aux valeurs publiées par chaque fournisseur :
Usage
Structure SPF
Google Workspace seul
v=spf1 include:_spf.google.com ~all
Google et un tiers
v=spf1 include:_spf.google.com include:spf.fournisseur.example ~all
Google et deux tiers
v=spf1 include:_spf.google.com include:spf.service-a.example include:spf.service-b.example ~all
Service abandonné
Retirer son mécanisme après confirmation qu’il n’envoie plus
Avant chaque changement, recensez les services réellement actifs :
- Messagerie Google Workspace et applications connectées
- Outils marketing, CRM et services de support
- Facturation, formulaires et notifications automatisées
- Expéditeurs supprimés ou remplacés dans votre organisation
Validation SPF, dépannage et sécurité des e-mails
Après la publication, la validation SPF permet de distinguer une erreur DNS d’un problème lié au contenu ou à la réputation d’envoi. Cette vérification est particulièrement utile lorsqu’un message part normalement, mais que certains destinataires le filtrent.
Contrôler le DNS puis tester un message réel
Interrogez un validateur SPF reconnu pour vérifier qu’un seul enregistrement est détecté, que sa syntaxe est lisible et que les recherches restent dans la limite prévue. Selon Google, l’authentification doit également être examinée dans le contexte des exigences applicables aux expéditeurs.
Envoyez ensuite un courriel de test vers une boîte Gmail accessible et consultez l’option « Afficher l’original ». Le résultat SPF indique si le chemin d’envoi réel correspond à la politique publiée ; DKIM et DMARC apportent des contrôles complémentaires.
Un ordre de diagnostic réduit les changements inutiles :
- Rechercher d’abord les enregistrements SPF en double
- Comparer la valeur TXT au texte attendu
- Recenser les expéditeurs et leurs mécanismes DNS
- Examiner les recherches et retirer les services obsolètes
Renforcer la prévention de l’usurpation d’adresse
SPF contribue à la prévention de l’usurpation d’adresse en déclarant les expéditeurs autorisés, mais il ne signe pas le contenu du message. DKIM ajoute une signature, tandis que DMARC aide à définir la conduite à tenir lorsque les contrôles échouent.
Pour une équipe utilisant plusieurs plateformes, documenter chaque modification facilite la gestion des enregistrements DNS et le suivi des incidents. Un sous-domaine dédié à un flux d’envoi distinct peut aussi aider à séparer les politiques, si les fournisseurs le prennent en charge.
Source : Google, « Configurer SPF », Aide Google Workspace ; IETF, « RFC 7208 : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 ».