SPF, DKIM et DMARC sur Google Workspace : configuration, vérification et erreurs à éviter

La sécurité des emails professionnels commence par l'authentification du domaine.

Lorsqu'une entreprise utilise Google Workspace, trois mécanismes DNS jouent un rôle essentiel : SPF, DKIM et DMARC.

Ils permettent aux serveurs destinataires de vérifier l'origine des messages, de contrôler leur signature et d'appliquer une politique lorsqu'un email échoue aux vérifications d'authentification.

Une configuration incorrecte peut provoquer des refus de messages, des classements en spam ou faciliter certaines formes d'usurpation de domaine.

Dans ce guide, nous expliquons comment configurer SPF, DKIM et DMARC sur Google Workspace, vérifier leur fonctionnement et identifier les principales erreurs techniques.

En bref : SPF, DKIM et DMARC sur Google Workspace

Pour sécuriser l'authentification des emails Google Workspace, trois mécanismes doivent être configurés dans les DNS du domaine :

• SPF (Sender Policy Framework) indique quels serveurs sont autorisés à envoyer des emails pour un domaine utilisé dans le transport du message.
• DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique permettant de vérifier que certaines parties du message n'ont pas été modifiées et que la signature correspond au domaine déclaré.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) vérifie l'alignement du domaine visible dans l'adresse de l'expéditeur avec SPF ou DKIM, puis publie une politique de traitement des messages non authentifiés.

Pour Google Workspace, la configuration SPF de base est v=spf1 include:_spf.google.com ~all, lorsque Google est le seul service d'envoi autorisé.

DKIM doit être activé depuis la console d'administration Google, après publication de la clé DNS.

DMARC est généralement déployé progressivement, en commençant par p=none pour analyser les résultats, puis en renforçant la politique vers p=quarantine et p=reject après vérification des expéditeurs légitimes.

MOZAYK Workspace permet de centraliser la consultation des configurations MX, SPF, DKIM et DMARC dans son module Domaines.

Une configuration correcte améliore l'authentification du courrier électronique, mais ne garantit ni la délivrabilité ni l'absence de phishing.

1. SPF, DKIM et DMARC : quelles différences ?

Ces trois mécanismes sont complémentaires, mais ils ne réalisent pas les mêmes contrôles.

SPF : autoriser les serveurs de messagerie

SPF définit les serveurs autorisés à expédier des emails pour un domaine donné.

Lorsqu'un message arrive, le serveur destinataire peut comparer l'adresse IP de l'expéditeur avec les mécanismes SPF publiés dans les DNS.

Si l'adresse IP n'est pas autorisée, le contrôle SPF peut échouer.

SPF seul ne garantit toutefois pas que le domaine affiché à l'utilisateur dans le champ « De » est légitime.

C'est notamment pour cette raison que DMARC est nécessaire.

DKIM : signer les messages

DKIM repose sur une paire de clés cryptographiques.

La clé privée est utilisée par le service d'envoi pour signer certaines parties des messages.

La clé publique est publiée dans les enregistrements DNS du domaine.

Le serveur destinataire peut ainsi vérifier la signature sans connaître la clé privée.

Un message signé avec DKIM peut néanmoins être frauduleux si le domaine signataire appartient lui-même à un acteur malveillant. DKIM authentifie une signature, pas la fiabilité générale de son auteur.

DMARC : vérifier l'alignement du domaine

DMARC ajoute une vérification essentielle : l'alignement entre le domaine visible dans l'adresse de l'expéditeur et le domaine authentifié par SPF ou DKIM.

Pour réussir DMARC, un message doit disposer d'au moins un mécanisme SPF ou DKIM qui réussit et qui est aligné avec le domaine du champ « From ».

DMARC permet aussi au propriétaire du domaine de publier une politique :

• p=none : surveillance, sans demande de traitement particulier.
• p=quarantine : demande de mise en quarantaine des messages échouant à DMARC.
• p=reject : demande de rejet des messages échouant à DMARC.

L'application de la politique dépend du serveur destinataire et de ses règles locales.

2. Configurer SPF pour Google Workspace

SPF est publié sous la forme d'un enregistrement DNS TXT.

Étape 1 : identifier les services qui envoient des emails

Avant de modifier les DNS, nous recommandons de dresser la liste complète des services utilisant votre domaine pour envoyer des messages.

Par exemple :

• Gmail dans Google Workspace.
• Une application de gestion commerciale.
• Un outil d'emailing.
• Une plateforme de support.
• Un logiciel de facturation.
• Une application métier utilisant un service SMTP externe.

Cette étape est importante : oublier un expéditeur légitime peut provoquer des échecs d'authentification.

Étape 2 : ajouter l'enregistrement SPF

Si votre organisation envoie ses emails uniquement via les serveurs Google Workspace, la configuration de référence est :

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

Dans l'interface DNS de votre fournisseur de domaine, créez ou modifiez l'enregistrement :

Le symbole @ dépend de l'interface DNS utilisée.

Cette configuration n'est pas universelle : elle doit être adaptée si d'autres services envoient des emails avec des identités relevant de votre domaine.

Étape 3 : intégrer les autres expéditeurs

Une organisation utilisant Google Workspace et une plateforme d'envoi tierce peut avoir besoin d'autoriser les deux infrastructures.

Exemple fictif :

v=spf1 include:_spf.google.com include:spf.exemple-service.test ~all

L'adresse spf.exemple-service.test est illustrative et ne doit pas être copiée telle quelle.

Utilisez toujours les instructions SPF officielles du fournisseur concerné.

Attention également : certains prestataires utilisent un domaine de retour technique distinct. Dans ce cas, leur authentification SPF peut être configurée sur ce domaine, tandis que l'alignement DMARC repose sur DKIM.

Étape 4 : respecter la limite des dix consultations DNS

La norme SPF impose une limite de dix mécanismes ou modificateurs entraînant des consultations DNS pendant son évaluation.

Cela concerne notamment :

• include
• a
• mx
• ptr
• exists
• redirect

Les mécanismes ip4 et ip6 n'entraînent pas ces consultations.

Les recherches effectuées indirectement à travers des include comptent également dans cette limite.

En cas de dépassement, l'évaluation SPF peut produire une erreur permanente (permerror).

Il ne suffit donc pas de compter uniquement les mécanismes visibles dans l'enregistrement principal.

Erreur fréquente : publier plusieurs SPF

Un domaine ne doit pas publier plusieurs enregistrements SPF distincts correspondant au même nom DNS.

Configuration incorrecte :

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.exemple-service.test ~all

La bonne approche consiste à construire un seul enregistrement SPF cohérent.

3. Configurer DKIM dans Google Workspace

DKIM permet à Google Workspace de signer les messages sortants avec une clé associée à votre domaine.

Étape 1 : ouvrir la console d'administration

Connectez-vous à :

https://admin.google.com

Puis ouvrez :

Applications > Google Workspace > Gmail > Authentifier les e-mails

Le libellé exact peut varier légèrement selon la langue et l'évolution de la console.

Sélectionnez le domaine concerné.

Étape 2 : générer la clé DKIM

Cliquez sur l'option de génération d'un nouvel enregistrement.

Lorsque cette option est disponible, nous recommandons une clé RSA de 2 048 bits.

Cette longueur offre une meilleure robustesse que les anciennes clés de 1 024 bits.

Le fournisseur DNS doit accepter la longueur de l'enregistrement TXT correspondant.

Google vous fournit notamment :

• Un sélecteur DKIM.
• Un nom d'enregistrement DNS.
• Une valeur contenant la clé publique.

Étape 3 : publier la clé DKIM

Exemple de structure :

Nom : google._domainkey
Type : TXT
Valeur : v=DKIM1; k=rsa; p=CLE_PUBLIQUE_FOURNIE_PAR_GOOGLE

La clé publique réelle est générée par Google Workspace.

Ne copiez pas la valeur illustrative ci-dessus.

Selon le fournisseur DNS, le nom doit être renseigné avec ou sans le domaine complet.

Étape 4 : démarrer l'authentification

Après publication et propagation de l'enregistrement DNS, retournez dans la console d'administration Google.

Cliquez sur Démarrer l'authentification.

Cette étape est indispensable.

La simple publication de la clé DNS ne signifie pas que Google Workspace signe déjà les messages pour ce domaine.

Étape 5 : vérifier DKIM

Envoyez un email de test vers une boîte externe, par exemple Gmail.

Dans Gmail, ouvrez le message, cliquez sur le menu du message, puis sélectionnez l'option d'affichage de l'original.

Recherchez notamment :

dkim=pass

Ce résultat indique qu'une signature DKIM a été validée.

Vérifiez également le domaine signataire (header.d) pour confirmer qu'il correspond à votre configuration et qu'il est correctement aligné pour DMARC.

4. Configurer DMARC pour Google Workspace

DMARC utilise un enregistrement DNS TXT publié sous le sous-domaine _dmarc.

Nous recommandons une approche progressive, particulièrement lorsque plusieurs applications envoient des messages avec le domaine de l'entreprise.

Étape 1 : commencer par une politique de surveillance

Exemple :

v=DMARC1; p=none; rua=mailto:dmarc@exemple.com

Utilisez une adresse réellement opérationnelle pour les rapports DMARC.

Ces rapports sont généralement au format XML et peuvent nécessiter un outil d'analyse.

Une politique p=none n'impose pas la mise en quarantaine ou le rejet des messages échouant à DMARC.

Elle constitue une étape d'observation, pas une protection complète contre l'usurpation.

Étape 2 : analyser les expéditeurs légitimes

Avant de renforcer la politique, identifiez les infrastructures qui envoient réellement des messages au nom de votre organisation.

Vérifiez notamment :

• Les emails envoyés depuis Gmail.
• Les plateformes marketing.
• Les applications de facturation.
• Les outils de ticketing.
• Les services de messagerie transactionnelle.
• Les applications connectées via SMTP ou API.

Contrôlez leur authentification SPF, leur signature DKIM et surtout leur alignement DMARC.

Un SPF valide ne suffit pas à réussir DMARC si le domaine SPF n'est pas aligné avec le domaine visible.

Étape 3 : passer à la quarantaine

Lorsque les flux légitimes sont identifiés et correctement authentifiés, vous pouvez envisager :

v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.com

Cette politique demande aux serveurs destinataires de traiter avec suspicion les messages échouant à DMARC, généralement en les plaçant en spam ou en quarantaine.

Surveillez ensuite les résultats et les éventuels incidents de réception.

Étape 4 : renforcer vers le rejet

Lorsque la configuration est maîtrisée, vous pouvez envisager :

v=DMARC1; p=reject; rua=mailto:dmarc@exemple.com

Cette politique demande le rejet des messages échouant à DMARC.

Elle peut renforcer la protection contre certaines formes d'usurpation de votre domaine, mais une configuration incomplète peut également entraîner le rejet de messages légitimes.

Le passage à p=reject doit donc être précédé d'une vérification des services d'envoi et d'une surveillance des résultats.

Qu'en est-il des sous-domaines ?

DMARC dispose notamment du paramètre sp, permettant de définir une politique pour les sous-domaines lorsque ceux-ci ne publient pas de politique DMARC propre.

Exemple :

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@exemple.com

Ce paramètre peut être utile lorsque l'organisation possède plusieurs sous-domaines.

Il doit toutefois être défini en tenant compte des usages de messagerie réels de chacun d'eux.

5. Pourquoi SPF et DKIM peuvent réussir alors que DMARC échoue

C'est l'une des principales difficultés rencontrées par les administrateurs.

Prenons un exemple.

Un outil externe envoie un message affichant :

From: contact@entreprise.fr

Mais les informations d'authentification indiquent :

spf=pass smtp.mailfrom=service-externe.test
dkim=pass header.d=service-externe.test
dmarc=fail header.from=entreprise.fr

SPF et DKIM réussissent.

Pourtant, DMARC échoue.

Pourquoi ?

Parce que les domaines authentifiés ne sont pas alignés avec le domaine visible entreprise.fr.

Pour corriger cette situation, il peut être nécessaire de configurer un domaine d'envoi personnalisé ou une signature DKIM alignée dans l'application tierce.

Un résultat spf=pass ou dkim=pass ne garantit donc pas, à lui seul, un résultat dmarc=pass.

6. Les erreurs SPF, DKIM et DMARC les plus fréquentes

Plusieurs enregistrements SPF

Deux enregistrements SPF distincts pour un même domaine peuvent provoquer une erreur permanente.

Correction : fusionner les autorisations nécessaires dans un seul enregistrement valide.

Trop de consultations DNS dans SPF

L'accumulation de mécanismes include peut entraîner un dépassement de la limite de dix consultations.

Correction : revoir les services autorisés et simplifier l'enregistrement, sans supprimer arbitrairement des expéditeurs légitimes.

DKIM publié, mais non activé

Une clé DKIM peut être présente dans les DNS alors que la signature n'est pas activée dans Google Workspace.

Correction : vérifier l'état de l'authentification dans la console Google Admin.

Mauvais sélecteur DKIM

Le sélecteur utilisé dans la signature ne correspond pas au nom DNS publié.

Correction : comparer le champ s= de la signature DKIM avec le nom de l'enregistrement.

Politique DMARC trop restrictive

Une entreprise active p=reject sans avoir identifié tous ses expéditeurs.

Conséquence possible : certains messages légitimes sont rejetés.

Correction : reprendre l'analyse des flux et mettre en place une progression adaptée.

Authentification non alignée

SPF ou DKIM réussit, mais sur un domaine différent de celui visible dans l'adresse de l'expéditeur.

Correction : configurer l'alignement SPF ou DKIM en tenant compte du fournisseur concerné.

Rapports DMARC non exploités

Une adresse rua reçoit des rapports, mais personne ne les examine.

Correction : mettre en place une procédure d'analyse périodique et identifier les changements d'infrastructure d'envoi.

7. Faut-il aussi vérifier les enregistrements MX ?

Oui, même si les enregistrements MX ont un rôle différent.

Les MX indiquent quels serveurs doivent recevoir les emails destinés à un domaine.

SPF, DKIM et DMARC concernent principalement l'authentification des messages envoyés.

Pour une configuration Google Workspace récente, Google documente notamment l'enregistrement MX :

SMTP.GOOGLE.COM

avec une priorité de 1.

Les environnements plus anciens peuvent encore utiliser les enregistrements MX historiques de Google, qui restent pris en charge.

Il ne faut pas remplacer des MX existants sans vérifier le système de réception réellement utilisé.

Une mauvaise modification peut interrompre la réception des emails.

La vérification des MX doit donc faire partie d'un contrôle global de configuration du domaine, sans les confondre avec les mécanismes d'authentification des messages sortants.

8. Vérifier SPF, DKIM, DMARC et MX avec MOZAYK Workspace

Sur un environnement Google Workspace, la configuration DNS est souvent répartie entre plusieurs interfaces.

L'administrateur doit consulter la console Google, le fournisseur DNS et parfois différents outils de vérification.

MOZAYK Workspace centralise les informations utiles au contrôle des domaines Google Workspace.

Son module Domaines permet notamment de consulter l'état des principaux enregistrements liés à la messagerie :

• MX : configuration des serveurs de réception.
• SPF : informations sur la configuration d'autorisation des expéditeurs.
• DKIM : éléments de configuration de l'authentification par signature.
• DMARC : présence et paramètres de la politique publiée.

Cette vue centralisée facilite les vérifications de configuration et permet aux administrateurs de repérer les points nécessitant une analyse complémentaire.

Pourquoi centraliser les contrôles DNS ?

Pour un administrateur IT ou un DSI, la difficulté ne réside pas uniquement dans la configuration initiale.

Il faut également maintenir une visibilité sur l'environnement après les changements.

L'ajout d'un outil marketing, la migration vers une nouvelle plateforme ou la modification d'un fournisseur DNS peuvent nécessiter de nouveaux contrôles.

Une interface de consultation centralisée réduit les allers-retours entre plusieurs outils et simplifie les revues techniques.

Une vérification DNS ne remplace pas un audit de délivrabilité

Il est important de distinguer plusieurs niveaux de contrôle.

Un enregistrement SPF correctement publié ne prouve pas que tous les messages de l'entreprise réussissent SPF.

Une clé DKIM présente ne garantit pas que chaque application signe les messages avec un domaine aligné.

Une politique DMARC valide ne permet pas, à elle seule, de connaître les résultats d'authentification de tous les messages envoyés.

Pour confirmer le fonctionnement réel, nous recommandons de compléter les contrôles DNS avec :

• Des envois de messages de test.
• L'analyse des en-têtes Authentication-Results.
• L'examen des rapports DMARC.
• La consultation de Google Postmaster Tools lorsque les données sont disponibles.

MOZAYK Workspace contribue au contrôle de la configuration, tandis que l'analyse des flux permet de vérifier le comportement réel des emails.

9. Les bonnes pratiques pour maintenir l'authentification des emails

Une configuration initialement correcte peut devenir inadaptée au fil des évolutions de l'entreprise.

Nous recommandons les pratiques suivantes :

1. Documenter tous les services autorisés à envoyer des emails.
2. Maintenir un unique enregistrement SPF par nom DNS.
3. Vérifier le nombre de consultations DNS nécessaires à SPF.
4. Utiliser des clés DKIM de 2 048 bits lorsque cela est pris en charge.
5. Activer DKIM sur les domaines qui envoient des messages.
6. Vérifier l'alignement DMARC des expéditeurs légitimes.
7. Analyser les rapports DMARC avant de renforcer la politique.
8. Contrôler les configurations après l'ajout ou la suppression d'un service.
9. Réaliser des vérifications périodiques des domaines.
10. Documenter les modifications DNS et leur validation.

Ces contrôles contribuent à maintenir une configuration cohérente et à réduire les risques de défaillance de l'authentification.

10. SPF, DKIM et DMARC suffisent-ils à sécuriser la messagerie ?

Non.

Ces mécanismes contribuent à l'authentification des emails et à la protection contre certaines formes d'usurpation de domaine.

Ils ne remplacent pas :

• L'authentification multifacteur des comptes (voir la validation en deux étapes et l'audit de sécurité).
• La protection contre le phishing et les logiciels malveillants.
• La sécurisation des accès administratifs et la gestion des comptes utilisateurs.
• Le contrôle des applications tierces.
• Les politiques de partage des données (voir la protection des données).
• La sensibilisation des collaborateurs.

Un attaquant peut notamment envoyer des messages authentifiés depuis son propre domaine ou utiliser un compte professionnel compromis.

La sécurité de la messagerie doit donc s'intégrer dans une stratégie plus large de protection de Google Workspace.

Questions fréquentes

Quel SPF utiliser pour Google Workspace ?

Lorsque Google Workspace est le seul service d'envoi autorisé, l'enregistrement de référence est v=spf1 include:_spf.google.com ~all. Il doit être adapté si d'autres plateformes envoient des emails pour le domaine.

Comment activer DKIM dans Google Workspace ?

Dans la console Google Admin, ouvrez les paramètres Gmail d'authentification des emails, générez une clé DKIM, publiez l'enregistrement TXT dans les DNS, puis cliquez sur « Démarrer l'authentification ».

Faut-il choisir une clé DKIM de 1 024 ou 2 048 bits ?

Nous recommandons 2 048 bits lorsque Google Workspace et le fournisseur DNS prennent en charge cette longueur. Elle offre une meilleure robustesse cryptographique.

Quelle politique DMARC choisir au départ ?

Pour un domaine dont les flux d'envoi ne sont pas encore complètement maîtrisés, p=none permet généralement de commencer par l'observation et l'analyse des rapports. Le renforcement doit être effectué après vérification des messages légitimes.

Quelle est la différence entre p=none, p=quarantine et p=reject ?

p=none sert à surveiller sans demander de traitement particulier, p=quarantine demande la mise en quarantaine des messages échouant à DMARC et p=reject demande leur rejet. Les serveurs destinataires conservent leurs propres règles de traitement.

Pourquoi DMARC échoue alors que SPF et DKIM réussissent ?

SPF et DKIM peuvent réussir sur des domaines qui ne sont pas alignés avec le domaine visible dans l'adresse de l'expéditeur. DMARC exige au moins un mécanisme valide et aligné.

Peut-on avoir plusieurs enregistrements SPF ?

Non, plusieurs enregistrements SPF distincts au même nom DNS peuvent provoquer une erreur permanente. Les autorisations doivent être regroupées dans un enregistrement valide.

Pourquoi Google Workspace indique-t-il que DKIM n'est pas activé ?

La clé peut être absente, incorrecte, non propagée ou l'authentification peut ne pas avoir été démarrée dans la console Admin. Il faut vérifier les DNS et l'état de signature.

Peut-on configurer DMARC sans SPF ou DKIM ?

Un enregistrement DMARC peut être publié, mais son fonctionnement dépend de l'authentification et de l'alignement SPF ou DKIM. Il est recommandé de configurer les mécanismes d'authentification avant de déployer une politique restrictive.

Les MX sont-ils nécessaires pour SPF, DKIM et DMARC ?

Les MX ne sont pas nécessaires au fonctionnement de DKIM ou de DMARC et ne remplacent pas SPF. Ils servent principalement à orienter les emails entrants vers les serveurs de réception.

MOZAYK Workspace peut-il vérifier la configuration DNS Google Workspace ?

Oui. Le module Domaines de MOZAYK Workspace centralise les informations de configuration MX, SPF, DKIM et DMARC afin de faciliter les contrôles techniques des administrateurs.

SPF, DKIM et DMARC empêchent-ils tous les emails frauduleux ?

Non. Ils réduisent certains risques d'usurpation de domaine, mais ne bloquent pas toutes les formes de phishing, les domaines ressemblants ou les messages envoyés depuis des comptes compromis.

Conclusion : une authentification email à vérifier régulièrement

SPF, DKIM et DMARC constituent des mécanismes essentiels pour l'authentification des emails professionnels.

Leur efficacité dépend de la cohérence des configurations DNS, de la prise en compte des services d'envoi et du contrôle de l'alignement des domaines.

Pour les administrateurs Google Workspace, le travail ne s'arrête donc pas à la publication des enregistrements.

Il faut également vérifier leur état, analyser les résultats et tenir compte des évolutions de l'environnement informatique.

MOZAYK Workspace facilite cette démarche grâce à une vue centralisée des paramètres MX, SPF, DKIM et DMARC.

Vérifiez vos domaines Google Workspace avec MOZAYK Workspace

Retrouvez les informations essentielles de configuration des domaines Google Workspace dans une interface dédiée à l'administration et à la sécurité.

Démarrer l'essai gratuit de 30 jours

Sans carte bancaire. Découvrez aussi le module Domaines et DNS sur la page de présentation.

Sources et documentation officielle

• Google : configurer SPF
• Google : configurer DKIM
• Google : configurer DMARC
• Google : configuration des enregistrements MX
• Google : consignes relatives aux expéditeurs Gmail
• RFC 7208 : Sender Policy Framework
• RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance