Dernière mise à jour : juillet 2026

En bref : après ce guide, ton domaine publie un enregistrement SPF correct pour Google Workspace — enregistrements combinés inclus pour les services de newsletter et les CRM.

Prérequis

  • Un compte Google Workspace avec ton propre domaine
  • L’accès à la gestion DNS de ton domaine — qui n’est pas chez Google, mais chez ton hébergeur de domaine

Qu’est-ce que SPF ?

SPF (Sender Policy Framework) est un enregistrement TXT dans le DNS de ton domaine. Il liste les serveurs de messagerie autorisés à envoyer des e-mails avec ton domaine comme expéditeur. Les serveurs destinataires utilisent l’entrée pour vérifier si un message provient d’un serveur autorisé. Sans SPF, n’importe quel serveur peut envoyer des e-mails en ton nom — et tes e-mails légitimes finissent plus vite dans les spams.

Google en fait désormais une exigence stricte : les expéditeurs d’e-mails en masse (plus de 5 000 messages par jour) doivent avoir configuré SPF, DKIM et DMARC, faute de quoi Gmail n’accepte plus leurs e-mails de façon fiable.

Le point de départ chez Google Workspace

Comme pour Microsoft 365 : il n’y a rien à faire pour SPF dans la console d’administration Google. L’enregistrement se saisit chez l’hébergeur du domaine — c’est-à-dire là où vit ta zone DNS. La manière de procéder dans chaque cas est montrée dans nos guides pour IONOS, Strato, All-Inkl, Netcup et Hetzner DNS.

Deux remarques issues de la documentation de Google : SPF peut être déjà configuré pour ton domaine (par ex. si tu as enregistré le domaine via un partenaire Google) — vérifie donc d’abord, puis modifie. Et l’enregistrement doit contenir tous les serveurs qui envoient pour ton organisation, pas seulement Google.

Guide étape par étape

1. Vérifier si SPF est déjà actif

Le plus rapide, via le terminal :

dig TXT example.com +short | grep spf1

Autre possibilité : entre ton domaine dans le scanner MXAudit gratuit — il vérifie en même temps la syntaxe de l’enregistrement et les limites de lookups.

2. Déterminer l’enregistrement

Seul Google Workspace envoie (le cas normal) :

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

L’include pointe désormais vers une liste plate de plages IP Google (IPv4 + IPv6) et coûte exactement un lookup DNS. D’anciens guides font encore circuler les includes imbriqués _netblocks — tu n’as plus besoin de les saisir.

D’autres services envoient-ils aussi ? Google documente lui-même la combinaison, toutes les sources dans un seul enregistrement — par ex. avec Mailchimp :

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Avec Salesforce :

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

Ou en parallèle avec Microsoft 365 :

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

3. Saisir l’enregistrement chez l’hébergeur du domaine

Connecte-toi chez ton hébergeur de domaine et crée la valeur sous forme d’enregistrement TXT sur le domaine principal (hôte @) — ou mets à jour l’entrée v=spf1 existante. Il ne peut y avoir qu’un seul enregistrement SPF par domaine.

4. Penser aux sous-domaines

Selon Google, chaque sous-domaine qui envoie a besoin de sa propre entrée SPF — l’enregistrement du domaine principal ne s’applique pas automatiquement.

5. Attendre que la modification soit en ligne

Les modifications DNS prennent du temps : selon le TTL et la mise en cache, il peut s’écouler quelques heures avant que chaque serveur dans le monde voie le nouvel enregistrement.

Les composants en détail

ComposantSignification
v=spf1identifiant de version, toujours au début
include:_spf.google.comautorise l’infrastructure d’envoi Google (liste plate IPv4/IPv6, 1 lookup)
include: (supplémentaire)autorise les services externes — 1 lookup DNS supplémentaire chacun
~allsoftfail : la recommandation par défaut de Google dans l’enregistrement d’exemple

Un contraste intéressant : Google montre ~all dans tous ses exemples, tandis que Microsoft recommande -all pour les domaines 365. Les deux sont défendables — avec un DKIM et un DMARC propres (que Google exige de toute façon pour les gros expéditeurs), le choix du all importe moins, car DMARC prend en charge l’application.

Vérifier le résultat

Vérifie ta configuration avec le scanner MXAudit gratuit — il montre immédiatement si ton enregistrement SPF est syntaxiquement correct et combien de lookups DNS il consomme (la limite est de 10).

Ou directement dans le terminal :

dig TXT example.com +short | grep spf1

La sortie doit contenir exactement un enregistrement avec v=spf1.

Erreurs fréquentes

Un second enregistrement SPF créé au lieu d’étendre l’existant. Beaucoup de domaines ont déjà un enregistrement d’hébergeur. L’include Google doit y être ajouté — deux entrées v=spf1 provoquent un permerror.

Tous les expéditeurs ne sont pas capturés. La documentation de Google est claire : l’enregistrement doit contenir les serveurs de tous les systèmes d’envoi — CRM, outil de facturation, système de ticketing. Tout ce qui manque est écarté chez le destinataire.

Includes _netblocks obsolètes. D’anciens guides listent individuellement les enregistrements netblock internes de Google. Inutile : include:_spf.google.com suffit et reste à jour quand Google modifie ses plages IP.

Sous-domaines oubliés. Chaque sous-domaine qui envoie a besoin de sa propre entrée SPF.

+all à la fin. Un +all autorise n’importe quel serveur à envoyer et rend tout l’enregistrement inutile — ne le copie pas.

Le transfert échoue. Si un destinataire fait suivre automatiquement ton e-mail, SPF échoue souvent chez le destinataire final — le serveur de transfert ne figure pas dans ton enregistrement. C’est une faiblesse de conception de SPF, pas une erreur de configuration ; DKIM et DMARC couvrent ce cas.

Pour aller plus loin