SPF, DKIM et DMARC pour Google Workspace.
Authentifier Google Workspace, c'est prouver que les serveurs Gmail qui envoient au nom de votre domaine sont bien les vôtres. Tout se résume à trois enregistrements DNS, plus un commutateur à activer dans la console d'administration : un enregistrement SPF TXT qui ajoute l'include partagé de Google, une clé DKIM que vous générez dans la console et publiez sous forme d'enregistrement TXT (puis activez avec « Démarrer l'authentification »), et un enregistrement de politique DMARC. Google Workspace est l'un des rares expéditeurs qui est aussi destinataire ; c'est donc l'alignement de ces trois éléments qui fait atterrir votre courrier dans les boîtes de réception Gmail plutôt que d'y afficher une mention « via » ou de le faire glisser vers les spams.
Pourquoi authentifier Google Workspace ?
Le courrier Google Workspace transite déjà par l'infrastructure de Google, mais tant que vous ne l'authentifiez pas, il n'est que faiblement attribuable à votre domaine — Gmail peut afficher une mention « via », DMARC ne peut pas passer et votre adresse d'expéditeur (From) ne vous appartient pas cryptographiquement. Depuis février 2024, les propres consignes de Google pour les expéditeurs exigent que chaque expéditeur passe SPF ou DKIM, et que chaque expéditeur de masse (environ 5 000 messages ou plus par jour vers Gmail) publie en outre une politique DMARC d'au moins p=none, avec alignement. Yahoo a adopté les mêmes règles le même mois et Microsoft a commencé à les appliquer en 2025. Comme Google évalue ici le courrier au regard de ses propres consignes, un domaine Workspace non authentifié est le chemin le plus rapide vers le dossier spam ou un rejet pur et simple. Mettre en place correctement SPF + DKIM + DMARC aligne les deux mécanismes sur votre domaine, supprime la mention « via », permet à DMARC de passer et bâtit votre réputation d'expédition sous votre propre nom.
La réalité SPF pour Google Workspace
Google Workspace est un véritable fournisseur « include » : vous ajoutez un seul mécanisme partagé, include:_spf.google.com, à l'unique enregistrement SPF TXT de votre domaine racine — l'enregistrement complet est v=spf1 include:_spf.google.com ~all. Il s'agit d'un vrai include partagé (chaque client Workspace utilise le même), contrairement aux fournisseurs qui délèguent par CNAME. Cela compte davantage ici que pour la plupart des expéditeurs, car le courrier que vous envoyez via Google utilise une adresse d'enveloppe sur votre propre domaine ; SPF s'aligne donc réellement sur votre domaine organisationnel et contribue à un passage DMARC (pas seulement DKIM). Une mise à jour importante : include:_spf.google.com est désormais un unique enregistrement SPF à plat ne contenant que des mécanismes ip4:/ip6: — il n'imbrique plus l'ancienne chaîne include:_netblocks.google.com / _netblocks2 / _netblocks3. Cela signifie qu'il ne coûte qu'une seule requête DNS au regard de la limite de 10 fixée par la RFC 7208, et non les trois à quatre que rapportent encore certains guides plus anciens et certains vérificateurs SPF en cache. Google recommande de terminer par ~all (softfail) plutôt que par -all, car les utilisateurs de Workspace envoient aussi souvent, de façon légitime, via d'autres outils ; ne durcissez vers -all qu'une fois certain que chaque expéditeur est bien répertorié. Et il ne doit y avoir qu'un seul enregistrement SPF TXT sur le domaine — si vous utilisez aussi SendGrid, Mailchimp, Microsoft 365, etc., fusionnez tous les mécanismes dans cette unique ligne v=spf1 au lieu de publier un second enregistrement SPF (deux enregistrements SPF entraînent une PermError).
Étape par étape
- 1
Ouvrir Authentifier les e-mails
Connectez-vous à admin.google.com en tant que super-administrateur, puis allez dans Menu (☰) → Applications → Google Workspace → Gmail → Authentifier les e-mails. C'est la page DKIM ; SPF et DMARC s'ajoutent directement chez votre hébergeur DNS, pas ici.
- 2
Sélectionner le bon domaine
Si vous gérez plusieurs domaines, choisissez le domaine expéditeur dans le menu déroulant en haut de la page Authentifier les e-mails. Chaque domaine principal, domaine secondaire et alias de domaine s'authentifie séparément.
- 3
Générer la clé DKIM
Cliquez sur Générer un nouvel enregistrement. Définissez la longueur de clé sur 2048 bits (recommandation de Google ; ne revenez à 1024 bits que si votre hébergeur DNS ne peut pas stocker une longue valeur TXT) et laissez le préfixe de sélecteur sur la valeur par défaut google. Cliquez sur Générer.
- 4
Copier l'enregistrement DKIM
Google affiche un enregistrement TXT : l'hôte/le nom est google._domainkey et la valeur commence par v=DKIM1; k=rsa; p=… suivi d'une longue clé publique. Copiez les deux. Laissez cet onglet ouvert — vous y reviendrez pour cliquer sur Démarrer l'authentification.
- 5
Publier l'enregistrement DKIM TXT
Chez votre hébergeur DNS, ajoutez un enregistrement TXT avec l'hôte google._domainkey et la valeur fournie par Google. Une clé de 2048 bits dépasse la limite de 255 caractères par chaîne TXT ; certains hébergeurs vous obligent donc à la conserver en plusieurs morceaux entre guillemets dans un même enregistrement — la plupart des panneaux le gèrent automatiquement ; sinon, collez la valeur fractionnée exactement telle qu'affichée.
- 6
Ajouter ou fusionner l'enregistrement SPF
Ajoutez un enregistrement TXT sur le domaine racine (hôte @ ou vide) avec v=spf1 include:_spf.google.com ~all. Si un enregistrement SPF existe déjà, n'en créez pas un second — fusionnez include:_spf.google.com dans la ligne v=spf1 existante, aux côtés de tout autre expéditeur.
- 7
Publier l'enregistrement DMARC
Ajoutez un enregistrement TXT à l'hôte _dmarc avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Commencez par p=none (surveillance seule) pour que rien ne soit affecté pendant que vous confirmez l'alignement ; vous le durcirez plus tard.
- 8
Cliquer sur Démarrer l'authentification
De retour sur la page Authentifier les e-mails, attendez que l'enregistrement DKIM TXT se soit propagé, puis cliquez sur Démarrer l'authentification. C'est l'étape que les gens oublient — générer la clé ne fait rien tant que vous ne démarrez pas l'authentification, après quoi le statut indique « Authentification des e-mails pour ce domaine ».
- 9
Envoyer un test et vérifier les en-têtes
Envoyez un message depuis une adresse Workspace, ouvrez-le dans un autre compte Gmail et utilisez ⋮ → Afficher l'original. Confirmez SPF : PASS, DKIM : PASS avec « signed-by: yourdomain.com » (sélecteur google) et DMARC : PASS — le tout aligné sur votre domaine, et non sur google.com.
- 10
Répéter pour les autres domaines et alias
DKIM et l'étape Démarrer l'authentification doivent être répétés pour chaque domaine secondaire et alias de domaine depuis lesquels vous envoyez. Les enregistrements SPF et DMARC doivent aussi exister sur chacun de ces domaines, sinon leur courrier ne s'authentifiera pas.
Enregistrements à ajouter
Google Workspace génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.google.com ~allSPF racine — ne conservez qu'un seul enregistrement SPF ; fusionnez les autres expéditeurs dans cette ligne. include:_spf.google.com ne coûte désormais qu'1 requête DNS. |
| TXT | google._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(2048-bit public key from the Admin console)À titre indicatif — la clé réelle est générée par domaine sous Applications → Google Workspace → Gmail → Authentifier les e-mails. Les clés de 2048 bits peuvent devoir être publiées sous forme de chaînes fractionnées entre guillemets. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comUn seul enregistrement DMARC par domaine. Commencez par p=none, puis durcissez vers quarantine/reject. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Google Workspace sur ce budget.
Google Workspace utilise 1 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
La clé DKIM de Google Workspace se génère dans la console d'administration ; elle n'est pas copiée depuis une valeur figée. Rendez-vous dans Applications → Google Workspace → Gmail → Authentifier les e-mails, sélectionnez le domaine, cliquez sur Générer un nouvel enregistrement et choisissez 2048 bits avec le préfixe de sélecteur par défaut google. Google affiche alors un enregistrement TXT dont l'hôte est google._domainkey.yourdomain.com et dont la valeur est v=DKIM1; k=rsa; p=<votre clé publique>. Vous publiez cet enregistrement TXT chez votre hébergeur DNS — Google conserve la clé privée correspondante et signe le courrier sortant avec elle. Deux points rendent le DKIM de Workspace différent de la plupart des fournisseurs. Premièrement, publier l'enregistrement ne suffit pas : vous devez retourner sur la page Authentifier les e-mails et cliquer sur Démarrer l'authentification, sans quoi Google ne commence jamais réellement à signer avec votre clé (c'est la raison la plus fréquente pour laquelle un enregistrement correctement publié n'affiche toujours aucun passage DKIM). Deuxièmement, une clé publique de 2048 bits dépasse la limite de 255 caractères d'une seule chaîne TXT ; de nombreux hébergeurs DNS la stockent donc en plusieurs morceaux entre guillemets au sein d'un même enregistrement. La console d'administration affiche la valeur déjà mise en forme, et la plupart des panneaux (GoDaddy, Cloudflare, Namecheap, etc.) la réassemblent correctement — si Gmail signale plus tard la clé comme non valide, une concaténation rompue en est généralement la cause. Le sélecteur google peut tout à fait être conservé ; vous ne le changeriez que s'il est déjà utilisé par un autre service sur le domaine. Abandonnez toute clé héritée de 1024 bits dès que possible, et rappelez-vous que DKIM s'active par domaine et par alias, pas une seule fois pour tout le compte.
DMARC
DMARC est un enregistrement de politique distinct que vous publiez vous-même — Google ne le crée pas à votre place. Ajoutez un enregistrement TXT à _dmarc.yourdomain.com avec v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est en mode surveillance seule : cela ne change rien à la délivrabilité, mais indique aux destinataires de vous envoyer des rapports agrégés afin que vous puissiez confirmer que le courrier Google Workspace passe bien SPF et DKIM alignés sur votre domaine. Comme Workspace aligne les deux mécanismes (SPF via votre propre domaine d'enveloppe, DKIM via le sélecteur google sur votre domaine), vous devriez constater rapidement des passages sans faute. Surveillez les rapports rua pendant une ou deux semaines, assurez-vous que chaque expéditeur légitime — Workspace ainsi que tout outil tiers — s'authentifie, puis durcissez la politique vers p=quarantine et, à terme, p=reject. Conservez exactement un seul enregistrement _dmarc pour l'ensemble du domaine, quel que soit le nombre d'expéditeurs que vous utilisez ; n'ajoutez jamais un second enregistrement DMARC spécifiquement pour Google. Notez que la propre règle de Google pour les expéditeurs de masse n'impose que p=none comme plancher, mais c'est p=reject qui protège réellement votre domaine contre l'usurpation.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul statut de la console d'administration — il peut accuser du retard et continuer d'afficher « jusqu'à 48 heures » alors que le DNS est déjà actif. Vérifiez sur un vrai message : envoyez depuis une adresse Workspace vers une autre boîte, ouvrez-le dans Gmail et choisissez ⋮ → Afficher l'original. Vous voulez SPF : PASS, DKIM : PASS et DMARC : PASS, avec les domaines « signed-by » de DKIM et SPF affichant tous deux yourdomain.com (sélecteur google) plutôt que google.com. Google publie aussi son propre outil de diagnostic, l'outil CheckMX de la Admin Toolbox (toolbox.googleapps.com/apps/checkmx), qui signale les enregistrements SPF/DKIM/DMARC et MX manquants ou mal formés. Vous pouvez contrôler ponctuellement les enregistrements bruts avec dig TXT google._domainkey.yourdomain.com et dig TXT _dmarc.yourdomain.com. Enfin, passez le domaine dans la vérification de l'état du domaine de Qualisend pour confirmer que chaque enregistrement se résout et que le SPF reste sous la limite de 10 requêtes ; et dès que les rapports agrégés DMARC commencent à arriver, déposez-en un dans l'analyseur de rapports DMARC — Google devrait y apparaître comme une source alignée qui passe entièrement.
Pièges courants
- Casse l'authentification
Générer la clé DKIM ne fait rien tant que vous ne cliquez pas sur Démarrer l'authentification sur la page Authentifier les e-mails. Un enregistrement google._domainkey publié dont la signature n'a jamais été démarrée est la cause n°1 d'un DKIM qui échoue encore à une vérification.
- Casse l'authentification
Les clés DKIM de 2048 bits sont plus longues qu'une seule chaîne TXT de 255 caractères ; elles sont donc stockées en plusieurs morceaux entre guillemets. Si Gmail signale la clé comme non valide après publication, une concaténation malmenée (ou votre panneau qui perd le fractionnement) en est presque toujours la cause.
- Casse l'authentification
La console d'administration peut continuer d'afficher « non authentifié » ou « jusqu'à 48 heures » même après que votre DNS est correct — le statut se revérifie avec du délai. Fiez-vous à Afficher l'original / à l'Admin Toolbox plutôt qu'au bandeau de la console.
- Couverture
DKIM doit être configuré séparément pour chaque domaine secondaire et alias de domaine, et chacun de ces domaines a aussi besoin de ses propres enregistrements SPF et DMARC. Authentifier le domaine principal ne couvre pas les autres.
- Casse l'authentification
Conservez exactement un seul enregistrement SPF TXT sur la racine. Si vous envoyez aussi via SendGrid, Mailchimp, Microsoft 365, etc., fusionnez include:_spf.google.com dans l'unique ligne v=spf1 — deux enregistrements SPF entraînent une PermError.
- Configuration DNS
include:_spf.google.com est désormais un unique enregistrement à plat (1 requête), mais des guides plus anciens et certains vérificateurs SPF en cache le comptent encore comme 3–4 — ne surdimensionnez pas et ne vous précipitez pas pour l'aplatir sur la base de chiffres périmés.
- Couverture
Utilisez ~all, pas -all. Google recommande le softfail parce que les utilisateurs de Workspace envoient fréquemment, de façon légitime, via d'autres services ; un -all prématuré peut faire échouer durement du courrier que vous auriez oublié de répertorier.
- Couverture
Le courrier envoyé via un relais tiers, un SMTP externe « Envoyer des e-mails en tant que » de Gmail, ou une plateforme marketing n'est pas signé DKIM par Google — ces chemins ont besoin de leur propre authentification et ne s'aligneront pas du simple fait que le DKIM de Workspace est activé.
Construisez votre enregistrement SPF
Google Workspace est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Google Workspace — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.