Google Workspace ne gère-t-il pas déjà l'authentification tout seul ?

Partiellement seulement. Google signe bien vos messages, mais avec sa propre clé générique tant que vous n'avez pas activé la signature à votre domaine dans la console d'administration. Et Google ne peut rien publier à votre place dans votre zone DNS : SPF et DMARC restent à créer chez votre registraire. Une messagerie Google sans configuration reste un domaine non authentifié.

Où se créent réellement les enregistrements ?

Chez le gestionnaire de votre nom de domaine, pas chez Google sauf si le domaine a été acheté via Google. La console d'administration Google génère la valeur DKIM et vous indique quoi publier, mais c'est vous qui créez l'entrée dans la zone DNS du domaine.

J'ai plusieurs domaines dans mon compte Google. Faut-il tout refaire ?

Oui, pour chacun. L'authentification s'applique à un domaine, pas à un compte : chaque domaine et chaque alias d'envoi a besoin de ses propres enregistrements SPF, DKIM et DMARC. C'est l'oubli le plus fréquent sur les comptes qui gèrent plusieurs marques.

Configurer SPF, DKIM et DMARC avec Google Workspace

Google Workspace est probablement la configuration la plus répandue, et l'une des plus souvent mal authentifiées précisément parce qu'elle fonctionne très bien sans être configurée. Vos messages partent, ils arrivent, tout semble normal. Jusqu'au jour où un destinataire un peu strict les classe en indésirables.

Si vous ne savez pas encore à quoi servent ces trois enregistrements, l'explication est ici. Sinon, voici l'essentiel.

Où travailler : deux endroits, pas un

C'est ce qui déroute au départ. La configuration se fait à deux endroits :

La console d'administration Google : c'est là que vous activez la signature DKIM et que Google vous donne la valeur à publier.
La zone DNS de votre domaine, chez votre registraire OVH, Gandi, IONOS, Cloudflare ou autre : c'est là que vous créez les trois entrées.

Google ne peut rien publier à votre place : il ne gère pas votre domaine.

Étape 1 : l'enregistrement SPF

Dans la zone DNS de votre domaine, cherchez d'abord un enregistrement existant dont la valeur commence par v=spf1. Il ne peut y en avoir qu'un seul : s'il existe, modifiez-le au lieu d'en créer un second.

Type : TXT
Nom / sous-domaine : vide, ou @ selon l'interface (le domaine racine)
Valeur :

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

Si d'autres services envoient aussi en votre nom outil d'infolettre, logiciel de facturation, formulaire du site ajoutez leurs inclusions dans ce même enregistrement :

v=spf1 include:_spf.google.com include:le-service.example ~all

Passez de ~all à -all quand vous êtes certain que la liste est complète : -all est plus strict et plus protecteur, mais il rejette aussi ce que vous auriez oublié.

Étape 2 : DKIM, dans la console Google

C'est l'étape qui manque dans la majorité des configurations que nous auditons.

Par défaut, Google signe vos messages avec une clé générique, partagée. Pour signer à votre domaine ce qui est la condition de l'alignement DMARC, il faut l'activer explicitement :

Dans la console d'administration, allez dans les applications, puis Google Workspace, puis Gmail.
Ouvrez la section d'authentification du courrier.
Générez la clé pour le domaine concerné. Google affiche alors un nom d'entrée (généralement google._domainkey) et une longue valeur.
Créez cette entrée TXT dans votre zone DNS, en recopiant la valeur exactement.
Revenez dans la console et démarrez l'authentification.

L'ordre compte : si vous démarrez l'authentification avant que l'entrée DNS soit propagée, Google refuse et il faut recommencer.

Étape 3 : DMARC

Toujours dans la zone DNS de votre domaine :

Type : TXT
Nom / sous-domaine : _dmarc
Valeur :

v=DMARC1; p=none; rua=mailto:rapports@votredomaine.fr; fo=1

Commencez toujours par p=none : vous recevez les rapports sans rien bloquer, le temps de découvrir quels services envoient en votre nom. Le durcissement vient ensuite, et se fait par étapes c'est le sujet de quelle politique DMARC choisir.

Vérifier

Attendez la propagation, puis testez votre domaine avec notre outil SPF et DMARC.

Vérification complémentaire, très parlante : envoyez un message depuis votre adresse Google vers une autre adresse Gmail, ouvrez-le, et affichez les détails du message. Vous y lisez explicitement les résultats de l'authentification. Le domaine indiqué pour la signature doit être le vôtre, pas celui de Google : c'est la preuve que l'étape 2 a bien été faite.

Les trois pièges spécifiques à Google Workspace

La signature générique. Sans activation dans la console, DKIM réussit techniquement mais pour le domaine de Google, ce qui fait échouer l'alignement DMARC. C'est le piège numéro un.

Les alias d'envoi. Une adresse d'un autre domaine configurée pour envoyer depuis Gmail a besoin de la configuration complète de son domaine. L'authentification suit le domaine affiché à l'expéditeur, pas le compte utilisé.

Les redirections automatiques. Une règle de transfert automatique casse SPF à coup sûr, puisque le serveur qui retransmet n'est pas dans votre liste. C'est DKIM qui sauve la situation dans ce cas une raison de plus de l'activer correctement.

Chez un autre hébergeur

La démarche est la même partout, seule l'inclusion SPF change. Voir les guides pour OVH et Microsoft 365.

Et si vos messages finissent malgré tout en indésirables, la cause est peut-être ailleurs dans la chaîne : les sept causes, dans l'ordre à vérifier.

Une messagerie qui fonctionne n'est pas une messagerie authentifiée. Les deux se vérifient séparément.