SPF, DKIM et DMARC pour le cold emailing

La configuration DMARC vient après SPF et DKIM, parce que DMARC ne fait qu'évaluer leurs résultats. Publiez un seul enregistrement TXT sur _dmarc.votredomaine, par exemple v=DMARC1; p=none; rua=mailto:dmarc-reports@votredomaine. Lisez les rapports agrégés jusqu'à ce que chaque expéditeur légitime affiche un DKIM aligné, puis passez à p=quarantine et enfin à p=reject. La suite de cet article explique ce que vérifie chacun des trois enregistrements SPF, DKIM et DMARC, dans quel ordre les publier, et quels échecs apparaissent quand un domaine envoie à la fois via Google Workspace et via Brevo.

DKIM, SPF ou DMARC : que vérifie concrètement chacun ?

On traite souvent SPF, DKIM et DMARC comme une seule case à cocher. Ce sont en réalité trois tests distincts, et chacun regarde une partie différente du message. SPF examine l'expéditeur d'enveloppe, l'adresse MAIL FROM que le serveur destinataire voit pendant la conversation SMTP. Il ne regarde pas la ligne From que lit votre destinataire. DKIM vérifie une signature cryptographique placée dans l'en-tête du message à l'aide d'une clé publique publiée sous un sélecteur. DMARC est le seul des trois à relier le résultat au domaine From visible, et il indique au serveur destinataire quoi faire quand ce lien manque.

• SPF : un enregistrement TXT à la racine du domaine, qui commence par v=spf1. Il passe quand l'IP qui se connecte y figure. La spécification SPF plafonne le nombre de requêtes DNS qu'une seule évaluation peut déclencher : les longues chaînes d'include le cassent.
• DKIM : un enregistrement TXT sur selecteur._domainkey.votredomaine. Il passe quand la signature est vérifiée, c'est-à-dire que les en-têtes signés et le corps n'ont pas été modifiés en transit.
• DMARC : un enregistrement TXT sur _dmarc.votredomaine. Il passe quand SPF ou DKIM passe et que ce domaine est aligné sur le domaine From.
• Rapports : la balise rua de DMARC envoie des rapports XML agrégés à l'adresse de votre choix. SPF et DKIM n'ont aucun mécanisme de rapport propre.

Ce qui ne marche pas : se reposer uniquement sur SPF. Un transfert change l'IP qui se connecte, donc SPF échoue, alors qu'une signature DKIM survit généralement au transfert.

Comment SPF, DKIM et DMARC fonctionnent-ils ensemble lors d'une vérification ?

Le serveur destinataire exécute d'abord SPF et DKIM, puis transmet les deux résultats à DMARC. En alignement relâché, que la spécification DMARC définit comme valeur par défaut (aspf=r et adkim=r), le domaine authentifié doit seulement partager le domaine organisationnel avec l'adresse From. Avec un From anna@example.com, une signature DKIM en d=mail.example.com est alignée. Une signature en d=brevo-owned-domain.com passe DKIM mais échoue à l'alignement : elle n'aide donc en rien DMARC. C'est la surprise la plus fréquente pour qui envoie via une plateforme tierce : chaque vérification affiche « pass » dans les en-têtes, et DMARC échoue quand même. L'alignement strict (adkim=s) exige une correspondance exacte du domaine, ce qui en vaut rarement la peine pour un domaine de prospection à froid. La règle pratique : au moins un des deux mécanismes doit passer sous votre propre domaine. DKIM est le meilleur candidat, car il survit au transfert et ne dépend pas de l'adresse de rebond utilisée par la plateforme. Les trois résultats apparaissent dans l'en-tête Authentication-Results d'un message de test, sous la forme spf=, dkim= et dmarc=.

SPF, DKIM et DMARC dans Google Workspace : pourquoi les mails Brevo ne réutilisent-ils pas les enregistrements de Google ?

Google Workspace n'authentifie que les mails qui sortent des serveurs de Google. Son include SPF est include:_spf.google.com. Sa clé DKIM se génère dans la console d'administration, sous Applications, Google Workspace, Gmail, Authentifier les e-mails, avec google comme sélecteur par défaut ; l'aide Google Workspace Admin recommande la plus longue des longueurs de clé proposées si votre hébergeur DNS la prend en charge. Une fois l'enregistrement publié, la même page d'aide précise que la propagation DNS peut prendre un certain temps avant de cliquer sur Démarrer l'authentification. Rien de tout cela ne couvre les mails que Brevo envoie pour votre domaine. Brevo signe avec sa propre clé sous son propre sélecteur : vous vous retrouvez donc avec deux enregistrements DKIM côte à côte, et c'est normal, car les sélecteurs n'entrent pas en conflit. Pour SPF, c'est différent. La spécification SPF n'autorise qu'un seul enregistrement v=spf1 par domaine : l'include de Google et celui que Brevo affiche dans son écran d'authentification de domaine doivent donc tenir sur la même ligne. Si vous publiez deux enregistrements SPF séparés, le résultat est un permerror, qui n'est pas traité comme un pass. L'ensemble des enregistrements DNS Google Workspace (MX, SPF, DKIM) fait l'objet d'un guide dédié, et la clé côté Google ainsi que le découpage d'une clé longue en plusieurs chaînes sont traités dans notre guide G Suite DKIM avec Brevo.

Comment configurer SPF, DKIM et DMARC, étape par étape ?

L'ordre compte. DMARC évalue les deux autres, donc on le publie en dernier. Commencez par un enregistrement qui se contente de collecter des rapports, et ne le durcissez qu'une fois les rapports propres.

1. 1 Listez chaque service qui envoie au nom de votre domaine : Google Workspace, Brevo, votre CRM, votre outil de facturation. Chacun a besoin soit d'une entrée SPF, soit de sa propre clé DKIM.
2. 2 Publiez un seul enregistrement TXT SPF à la racine, par exemple v=spf1 include:_spf.google.com plus l'include Brevo, terminé par ~all. Comptez les mécanismes qui déclenchent une requête DNS, includes imbriqués compris, et restez dans la limite de requêtes fixée par la spécification SPF.
3. 3 Générez les clés DKIM dans chaque service et publiez-les en TXT (ou en CNAME si le fournisseur le demande) sur selecteur._domainkey. Cliquez ensuite sur vérifier dans chaque service.
4. 4 Publiez DMARC sur _dmarc avec v=DMARC1; p=none; rua=mailto:votre-adresse-de-rapport. La politique p=none demande aux destinataires de ne rien faire en cas d'échec : elle sert uniquement à collecter des données.
5. 5 Envoyez un test vers une adresse Gmail, ouvrez Afficher l'original et vérifiez que SPF, DKIM et DMARC affichent chacun PASS.
6. 6 Lisez les rapports agrégés pendant plusieurs semaines avant de passer à p=quarantine.

Chez GoDaddy, le champ Hôte ajoute automatiquement votre domaine. Si vous saisissez le nom complet, vous obtenez selecteur._domainkey.example.com.example.com, comme expliqué dans notre guide sur la configuration DKIM GoDaddy pour Brevo.

Pourquoi SPF, DKIM ou DMARC échouent-ils même après configuration ?

La plupart des échecs viennent d'erreurs DNS ou de domaines non alignés, pas des protocoles eux-mêmes. Voici ceux que nous rencontrons le plus souvent, avec leurs causes :

• SPF permerror : deux enregistrements v=spf1 sur le même domaine, ou plus de termes déclenchant une requête DNS (include, a, mx, ptr, exists, redirect, comptés récursivement) que la limite de la spécification SPF ne l'autorise. Trop de requêtes qui reviennent vides aboutissent aussi à un permerror.
• DKIM body hash mismatch : quelque chose a réécrit le message après la signature, par exemple un pied de page ajouté par une passerelle ou une liste de diffusion.
• Clé DKIM introuvable : le nom du sélecteur est faux, le nom d'hôte a été doublé par l'interface DNS, ou l'enregistrement ne s'est pas encore propagé.
• Clé longue tronquée : une chaîne TXT unique a une longueur maximale dans le DNS, donc une clé DKIM longue doit être découpée en plusieurs chaînes entre guillemets. Certaines interfaces coupent la clé au lieu de la découper.
• DMARC en échec malgré deux pass : SPF et DKIM sont passés sous le domaine de la plateforme, pas sous le vôtre, donc aucun des deux n'est aligné sur le From.
• DMARC totalement absent : les consignes d'expédition de Google (Email sender guidelines) exigent un enregistrement DMARC des expéditeurs en masse vers des comptes Gmail personnels ; un mail sans DMARC y part donc désavantagé.

Vous pouvez contrôler chaque enregistrement avec dig TXT suivi du nom d'hôte (_dmarc.example.com ou selecteur._domainkey.example.com) avant d'incriminer le contenu.

Quelle politique DMARC choisir pour démarrer un domaine de prospection ?

Commencez par p=none. C'est le minimum que les consignes d'expédition de Google acceptent des expéditeurs en masse (aide Google Workspace Admin, état octobre 2026). Cette politique demande aux destinataires de ne rien faire des mails en échec : un outil oublié qui envoie au nom de votre domaine apparaît donc dans les rapports au lieu d'être mis en quarantaine. Quand les rapports agrégés ne listent plus que des sources que vous reconnaissez, toutes alignées, passez à p=quarantine. Pour durcir progressivement, la balise pct applique la politique à un pourcentage seulement des mails en échec ; sans cette balise, la politique s'applique à tous. p=reject est l'état final. Ce qui ne marche pas : passer directement à reject sur un domaine dont vous n'avez pas inventorié les expéditeurs. Invitations d'agenda, factures ou un formulaire oublié peuvent cesser d'arriver sans bruit. La syntaxe de l'enregistrement et le déploiement par paliers sont détaillés dans notre guide sur le déploiement d'un enregistrement DMARC Google Workspace. Gardez aussi en tête que DMARC ne fait pas le warm-up à votre place. Un nouveau domaine aux enregistrements corrects n'a toujours aucun historique d'envoi, et les destinataires jugent séparément le volume et le taux de plaintes ; les consignes d'expédition de Google fixent un seuil de taux de spam mesuré dans Postmaster Tools. Planifiez la montée en volume en parallèle du travail DNS, comme décrit dans notre guide sur le warm-up : volumes quotidiens et configuration DNS.

Exemple de configuration DMARC : un domaine de prospection Workspace plus Brevo

Prenons un domaine example.com. Les équipes écrivent depuis Google Workspace, et la prospection à froid part via le compte Brevo de ce même domaine. Voici l'enregistrement DMARC que nous publierions en premier, en TXT sur l'hôte _dmarc (pour les interfaces qui ajoutent le domaine) ou sur _dmarc.example.com (pour celles qui ne l'ajoutent pas) :

• v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r
• v=DMARC1 doit être la première balise. Un enregistrement qui commence autrement n'est pas lu comme un enregistrement DMARC.
• adkim=r et aspf=r ne font qu'expliciter les valeurs par défaut. Ainsi, quiconque modifiera l'enregistrement plus tard verra que l'alignement relâché est en place.
• sp= est volontairement omis. Sans lui, les sous-domaines héritent de p. N'ajoutez sp= que si un sous-domaine comme mail.example.com a besoin de sa propre politique.
• Publiez exactement un enregistrement v=DMARC1 sur _dmarc. S'il en apparaît un second, par exemple ajouté il y a des années par un créateur de site, les destinataires considèrent que le domaine n'a aucune politique valide.

Pour lire le premier rapport agrégé, ouvrez le fichier XML et vérifiez trois champs dans chaque enregistrement : source_ip, header_from et le domaine sous auth_results/dkim. Une ligne avec header_from example.com et un domaine DKIM example.com est alignée. Une ligne provenant d'une IP Brevo dont le domaine DKIM appartient à Brevo signifie que l'authentification du domaine example.com dans Brevo n'est pas terminée. Corrigez cela avant de durcir la politique, pas après. Les lignes venant d'IP inconnues correspondent soit à un outil oublié dans votre inventaire, soit à quelqu'un qui usurpe le domaine. Dans les deux cas, c'est précisément pour cela que p=none passe en premier. Un piège que les guides généralistes passent sous silence : si rua pointe vers une boîte sur un autre domaine, par exemple celui d'un prestataire de traitement des rapports, la spécification DMARC exige que ce domaine publie un enregistrement d'autorisation sur example.com._report._dmarc.domaineprestataire. Sans lui, les destinataires qui vérifient cet enregistrement n'envoient pas les rapports, et vous lisez une boîte vide en pensant que tout va bien.

Comment EmailFlow OS utilise-t-il vos enregistrements SPF, DKIM et DMARC ?

EmailFlow OS n'envoie pas depuis une adresse de plateforme partagée. Vous enregistrez une seule vidéo et la téléversez dans EmailFlow OS, vous connectez votre propre compte Brevo et votre domaine d'envoi, et vous importez votre liste de prospects dans EmailFlow OS. EmailFlow OS crée ensuite une version personnalisée de cet enregistrement pour chaque destinataire, et non pour chaque entreprise, et envoie chacune depuis votre boîte, via votre compte Brevo, sous votre domaine. C'est pourquoi c'est à vous de bien configurer les enregistrements ci-dessus. La clé DKIM que Brevo vérifie pour votre domaine et la politique DMARC sur _dmarc.votredomaine sont ce que les serveurs destinataires évaluent pour chaque message personnalisé. Un domaine d'expédition partagé placerait vos mails sous la réputation de quelqu'un d'autre. Avec ce fonctionnement, la réputation, les rapports et le DNS restent sous votre contrôle. Ce qu'un serveur destinataire fait de chaque message reste sa propre décision, fondée sur l'authentification, l'historique d'envoi et les plaintes. La place de la vidéo personnalisée par destinataire dans une séquence complète est décrite dans notre guide sur la prospection à froid avec une seule vidéo personnalisée.

Questions fréquentes

? Comment configurer DMARC ?

Vérifiez d'abord que SPF et DKIM passent sous votre propre domaine. Publiez ensuite un seul enregistrement TXT sur _dmarc.votredomaine contenant v=DMARC1; p=none; rua=mailto:votre-adresse-de-rapport. Envoyez un test vers Gmail et vérifiez qu'Afficher l'original indique DMARC: PASS. Lisez les rapports agrégés, corrigez les sources non alignées, puis passez à p=quarantine et plus tard à p=reject. Les consignes d'expédition de Google acceptent p=none comme minimum pour les expéditeurs en masse (état octobre 2026).

? Pourquoi est-ce que je ne reçois aucun rapport DMARC ?

Les trois causes habituelles : la balise rua manque ou contient une faute dans mailto: ; l'enregistrement n'est pas sur _dmarc mais à la racine ou sur un nom d'hôte doublé ; ou rua pointe vers un domaine externe qui n'a pas publié l'enregistrement d'autorisation sur votredomaine._report._dmarc.autredomaine exigé par la spécification DMARC. Contrôlez l'enregistrement avec dig TXT _dmarc.votredomaine avant de chercher le problème dans la boîte de réception.

? Faut-il vraiment les trois : SPF, DKIM et DMARC ?

Pour les envois en masse vers Gmail, oui : les consignes d'expédition de Google exigent des expéditeurs en masse vers des comptes Gmail personnels qu'ils publient SPF, DKIM et DMARC (au moins p=none), avec alignement. Les petits expéditeurs doivent avoir au minimum SPF ou DKIM, mais DKIM plus DMARC est la seule combinaison qui relie l'authentification à votre domaine From visible et qui survit au transfert.

? Un domaine peut-il avoir deux enregistrements SPF ?

Non. La spécification SPF autorise exactement un enregistrement v=spf1 par domaine. Deux enregistrements produisent un permerror, que les destinataires traitent comme un échec et non comme un pass. Pour combiner Google Workspace et Brevo, placez les deux mécanismes include dans un seul enregistrement, terminé par ~all, et gardez le nombre total de requêtes DNS dans la limite fixée par la même spécification.

? Qu'est-ce que l'alignement DKIM ?

L'alignement signifie que le domaine d= de la signature DKIM correspond au domaine From. En mode relâché (adkim=r, la valeur par défaut de DMARC), un sous-domaine comme mail.example.com est aligné sur example.com. En mode strict (adkim=s), la correspondance doit être exacte. Une signature valide mais non alignée, par exemple sous le domaine propre de la plateforme, ne compte pas pour DMARC.

? Combien de temps faut-il au DNS pour que DKIM soit vérifié ?

Cela dépend du TTL de l'enregistrement, c'est-à-dire la durée pendant laquelle les résolveurs gardent l'ancienne réponse en cache. Pour Workspace, l'aide Google Workspace Admin prévient que la propagation peut prendre un certain temps avant de pouvoir activer l'authentification DKIM. Si la vérification échoue toujours après ce délai, lancez dig TXT sur le nom d'hôte du sélecteur. Cherchez un nom d'hôte doublé, ou une clé que l'interface DNS a coupée au lieu de la découper.