SPF, DKIM, DMARC expliqués simplement (avec exemples de records)

Vos emails de prospection partent, personne ne répond, et vous ne savez pas s'ils arrivent. Avant de réécrire votre objet, vérifiez SPF, DKIM et DMARC : ce sont les trois enregistrements DNS qui disent au serveur de réception que votre domaine autorise bien le serveur qui lui parle. Sans eux, votre message est traité comme un inconnu, et un inconnu se fait filtrer.

Vous trouverez ici chaque enregistrement détaillé avec des records réels commentés terme par terme, la différence exacte entre softfail et hardfail, et la procédure de montée de la politique DMARC de p=none vers reject. Ce texte est écrit pour les dirigeants et les responsables commerciaux qui pilotent des campagnes de cold email et veulent contrôler leur configuration sans dépendre d'un prestataire technique.

SPF, DKIM et DMARC : ce que ces trois sigles vérifient vraiment

Quand vous envoyez un cold email, le serveur qui le reçoit ne vous connaît pas. Il voit une adresse IP, un nom de domaine et un en-tête From: que n'importe qui peut écrire à la main. Le protocole SMTP, conçu au début des années 1980, ne prévoit aucune vérification de l'expéditeur. SPF, DKIM et DMARC sont les trois enregistrements DNS qui comblent ce trou.

Chacun répond à une question différente. SPF répond à « quels serveurs ont le droit d'envoyer pour ce domaine ». DKIM répond à « ce message a-t-il bien été signé par le domaine, et son contenu est-il intact ». DMARC répond à « que doit faire le serveur de réception quand les deux réponses précédentes sont négatives ». Vous publiez ces trois enregistrements une seule fois par domaine d'envoi, et l'opération prend moins d'une heure.

Cette configuration ne fait pas arriver vos emails en boîte de réception à elle seule. Elle rend votre domaine identifiable, rien de plus. Un domaine authentifié qui envoie un contenu jugé indésirable finit quand même en spam. Un domaine non authentifié, lui, part avec un handicap que le meilleur message du monde ne rattrape pas : depuis février 2024, Gmail exige au minimum SPF ou DKIM sur tout email entrant, et les trois protocoles pour les expéditeurs qui dépassent 5 000 messages par jour vers Gmail.

Vous verrez plus bas les records que nous publions réellement, terme par terme, puis la procédure pour vérifier les vôtres.

Les points clés à retenir :

• SPF : autorise des serveurs d'envoi pour votre domaine, dans un enregistrement TXT unique. Deux records SPF sur le même domaine cassent l'authentification des deux.
• DKIM : signe chaque message avec une clé privée et publie la clé publique sous un sélecteur. La signature couvre aussi le corps du message, donc toute modification en transit la casse.
• DMARC : dit au serveur de réception quoi faire quand SPF et DKIM échouent, et vous envoie des rapports quotidiens sur les envois faits en votre nom.
• Alignement : DMARC exige que le domaine validé par SPF ou par DKIM corresponde à celui du champ From: que votre prospect lit. Un SPF valide ne suffit donc pas.
• Softfail ou hardfail : ~all laisse passer le message en notant l'échec, -all autorise le rejet. Passez au hardfail une fois toutes vos sources d'envoi identifiées, jamais avant.
• Montée de politique : vous observez avec p=none, vous filtrez avec p=quarantine, puis vous bloquez avec p=reject. Chaque palier dure deux à quatre semaines de lecture de rapports.

Pourquoi un serveur de réception exige une preuve avant d'accepter votre message

Le serveur de réception traite des millions de messages par jour et doit trancher en quelques millisecondes. Il commence par les questions mécaniques : ce domaine existe-t-il, l'adresse IP qui lui parle est-elle déclarée, sa réputation est-elle connue. L'authentification lui donne une réponse binaire et immédiate. Le reste de l'évaluation, contenu du message et comportement des destinataires, vient après.

Un domaine sans authentification n'est pas rejeté d'office. Il est traité comme inconnu, donc suspect. Sur une campagne de cold email, cette suspicion se paie en placement : vos messages partent en onglet Promotions, puis en spam, puis ne partent plus du tout parce que votre domaine a été signalé. Nous détaillons ce mécanisme dans notre guide sur les raisons pour lesquelles vos emails finissent en spam.

L'authentification protège aussi votre nom. Sans politique DMARC active, n'importe qui peut envoyer un message qui affiche votre domaine dans le champ expéditeur, et vos prospects reçoivent une facture frauduleuse signée de votre entreprise. Vous l'apprenez par eux, une fois le dégât fait. C'est la raison pour laquelle nous traitons ces trois enregistrements comme un prérequis et non comme une option sur toutes les campagnes de cold email que nous opérons.

Le coût de l'oubli est asymétrique. La configuration vous prend une heure et ne se refait pas. Une réputation de domaine abîmée vous coûte plusieurs semaines de warmup sur un domaine neuf, et tous les rendez-vous qualifiés que vous n'obtenez pas pendant ce temps.

SPF : la liste des serveurs autorisés à envoyer pour votre domaine

SPF, pour Sender Policy Framework, est la liste publique des serveurs autorisés à envoyer pour votre domaine. Vous la publiez dans un enregistrement TXT à la racine du domaine, et le serveur de réception compare l'adresse IP qui lui parle aux adresses déclarées.

Ce que contient un record SPF, terme par terme

Voici le record que nous publions sur un domaine d'envoi hébergé chez Google Workspace :

exemple.com. IN TXT "v=spf1 include:_spf.google.com ~all"

v=spf1 annonce la version du protocole et doit ouvrir la ligne. include:_spf.google.com délègue la liste des adresses IP autorisées à Google, qui la met à jour à votre place. ~all traite tout le reste en softfail, ce qui signifie « cette adresse IP n'est pas autorisée, accepte le message mais note l'échec ». La documentation de Google Workspace sur la configuration de SPF donne la valeur exacte à publier selon votre hébergeur.

Les deux pièges qui font échouer un SPF pourtant correct

Un domaine ne peut porter qu'un seul enregistrement SPF. En ajouter un second pour un nouvel outil produit une erreur permanente, et SPF échoue alors pour la totalité de vos envois, y compris ceux qui passaient la veille. Vous fusionnez tous les mécanismes dans une seule ligne.

La seconde limite est le plafond de dix résolutions DNS. Chaque include:, chaque a et chaque mx consomme une résolution, et les include imbriqués comptent également. Au onzième, le verdict bascule en erreur permanente. Un domaine qui accumule facturation, CRM, newsletter et service d'envoi dépasse ce plafond sans prévenir.

Retenez enfin ce point souvent ignoré : SPF vérifie le domaine du Return-Path, celui de l'enveloppe SMTP, et pas celui que votre prospect lit dans le champ expéditeur. Les deux peuvent différer, et c'est ce que DMARC va contrôler.

DKIM : la signature qui prouve que le message n'a pas été modifié

DKIM, pour DomainKeys Identified Mail, ajoute une signature cryptographique à chaque message sortant. Le serveur d'envoi calcule cette signature avec une clé privée qu'il garde, et vous publiez la clé publique correspondante dans votre DNS. Le serveur de réception refait le calcul et sait si le message vient bien du domaine annoncé.

Le sélecteur, la partie que tout le monde oublie

La clé publique se publie sous un nom qui contient un sélecteur, choisi par votre hébergeur d'envoi :

google._domainkey.exemple.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Ici, google est le sélecteur, k=rsa désigne l'algorithme et p= porte la clé publique elle-même, tronquée dans cet exemple. Le sélecteur explique pourquoi un même domaine peut signer avec plusieurs services : chacun pose sa clé sous son propre sélecteur, sans écraser celle du voisin. Chaque message sortant porte un en-tête DKIM-Signature qui indique quel sélecteur utiliser.

Bon à savoir : la signature DKIM ne couvre pas seulement les en-têtes. Elle contient un champ bh=, qui est l'empreinte du corps du message. Si un intermédiaire ajoute une bannière au bas de l'email, cette empreinte ne correspond plus et DKIM échoue, alors que votre configuration est parfaite. C'est ce qui casse l'authentification quand un message transite par une liste de diffusion.

Longueur de clé et rotation

Une clé de 1024 bits reste acceptée partout, une clé de 2048 bits est la longueur recommandée aujourd'hui. Prenez 2048 dès la création, en sachant qu'une clé de cette taille dépasse souvent la limite de 255 caractères par chaîne et doit être découpée en plusieurs segments entre guillemets.

Changez ensuite la clé une fois par an : vous publiez un nouveau sélecteur, vous basculez l'envoi dessus, puis vous retirez l'ancien quelques jours plus tard.

DMARC : l'instruction que vous donnez aux serveurs de réception

DMARC ne vérifie rien par lui-même. Il lit les verdicts rendus par SPF et par DKIM, ajoute une condition supplémentaire, et vous laisse décider du sort des messages qui échouent. Vous le publiez dans un enregistrement TXT posé sur un sous-domaine réservé :

_dmarc.exemple.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@exemple.com"

p= porte la politique et rua= l'adresse qui reçoit les rapports agrégés. Deux paramètres complètent souvent la ligne : sp= fixe une politique distincte pour les sous-domaines, et pct= applique la politique à une fraction seulement des messages, ce qui permet une montée progressive.

L'alignement, la condition que SPF seul ne remplit pas

Pour que DMARC réussisse, il faut qu'au moins un des deux protocoles passe, et que le domaine qu'il a validé corresponde à celui du champ From: que votre prospect voit. Votre message peut donc obtenir un SPF valide et échouer quand même à DMARC, parce que le Return-Path appartient à votre plateforme d'envoi et pas à votre domaine.

L'alignement se règle avec aspf= pour SPF et adkim= pour DKIM. La valeur par défaut r accepte les sous-domaines du même domaine organisationnel, la valeur s exige une correspondance exacte. Restez sur la valeur par défaut tant que vous n'avez pas une raison précise de durcir. La spécification complète se lit dans la RFC 7489, qui définit DMARC.

Les rapports agrégés, votre seule source de vérité

L'adresse indiquée dans rua= reçoit chaque jour des fichiers XML envoyés par les serveurs de réception. Ces rapports listent les adresses IP qui ont envoyé en votre nom, avec le verdict SPF et le verdict DKIM de chacune. Vous y découvrez les services qui envoient pour vous et que vous aviez oubliés, donc l'inventaire dont vous avez besoin avant de durcir la politique.

Softfail ou hardfail : ce qui change entre ~all et -all

Le dernier terme de votre record SPF porte un qualificateur qui dit au serveur de réception comment traiter une adresse IP absente de la liste. Quatre valeurs existent, et deux seulement ont un sens sur un domaine qui envoie vraiment.

La différence pratique entre ~all et -all s'est réduite depuis que DMARC existe. Avec une politique p=reject, un message non aligné est rejeté de toute façon, que SPF ait répondu softfail ou hardfail. Le -all garde pourtant son utilité : il protège votre domaine face aux serveurs qui vérifient SPF sans consulter la politique DMARC, et ces serveurs restent nombreux.

Le risque du -all est réel, lui aussi. Le jour où votre comptable envoie une relance depuis un outil de facturation absent du record, ce message peut être rejeté sans avertissement, et vous ne l'apprenez que si le destinataire vous appelle. Passez donc en -all après avoir lu vos rapports DMARC pendant quelques semaines, et jamais le jour de la mise en place.

Monter votre politique DMARC de p=none à p=reject sans casser vos envois

Une politique DMARC se durcit en trois paliers, dans cet ordre, sans jamais sauter d'étape. Le passage direct à p=reject sur un domaine dont vous ne connaissez pas encore toutes les sources d'envoi coupe des emails légitimes, et vous découvrez lesquels par les réclamations de vos clients.

Palier 1 : p=none et lecture des rapports

Vous publiez v=DMARC1; p=none; rua=mailto:dmarc@exemple.com et vous ne touchez plus à rien pendant deux à quatre semaines. Aucun message n'est affecté, les serveurs de réception se contentent de vous envoyer leurs rapports. Vous listez alors chaque source d'envoi qui apparaît, vous corrigez celles qui échouent, et vous coupez celles que vous ne reconnaissez pas.

Palier 2 : quarantine, puis reject

Quand toutes vos sources légitimes ressortent alignées, vous passez à p=quarantine. Les messages qui échouent partent en spam au lieu d'être livrés normalement. Vous gardez cette politique deux à quatre semaines de plus, en surveillant les rapports pour repérer une source oubliée, par exemple un outil que vous n'utilisez qu'une fois par trimestre.

Vous terminez par p=reject, qui demande le rejet pur et simple des messages non authentifiés. Sur un domaine dédié au cold email, ce palier se tient sans difficulté parce que le domaine ne sert qu'à cela. Sur votre domaine principal, prenez le temps du pct= : appliquez la politique à un quart des messages, lisez les rapports, puis montez jusqu'à la totalité.

Cette montée se mène en parallèle du warmup de votre domaine d'envoi, et non après lui. Le domaine chauffe pendant que la politique se durcit, et vous arrivez au premier envoi de campagne avec une configuration déjà stable. Le rythme d'envoi suit ensuite la logique décrite dans notre guide sur le nombre d'emails de prospection à envoyer par jour.

Vérifier vos enregistrements SPF, DKIM et DMARC en dix minutes

Vous n'avez besoin d'aucun outil payant pour contrôler votre configuration. Trois requêtes DNS et un email de test suffisent, et vous les lancez depuis n'importe quel terminal.

Lire vos trois enregistrements dans le DNS

Interrogez d'abord la racine du domaine, puis le sélecteur DKIM, puis le sous-domaine réservé à DMARC :

nslookup -type=TXT exemple.com

nslookup -type=TXT google._domainkey.exemple.com

nslookup -type=TXT _dmarc.exemple.com

La première commande doit renvoyer une seule ligne commençant par v=spf1. Si elle en renvoie deux, votre SPF est déjà cassé. La deuxième doit renvoyer une valeur v=DKIM1 suivie d'une clé publique. La troisième doit renvoyer v=DMARC1 et une politique. Remplacez le sélecteur google par celui de votre propre hébergeur si vous n'êtes pas chez Google Workspace.

Envoyez ensuite un email depuis votre outil d'envoi vers une boîte que vous contrôlez, chez un autre hébergeur, puis affichez la source du message reçu. Vous cherchez la ligne Authentication-Results, qui contient les trois verdicts en clair, par exemple spf=pass, dkim=pass et dmarc=pass. Un dmarc=fail accompagné d'un spf=pass signale un problème d'alignement, et non un problème de record.

Refaites ce contrôle après chaque changement d'outil d'envoi et chaque migration DNS. La documentation de Google Workspace sur la configuration de DMARC décrit les valeurs attendues et les erreurs les plus fréquentes.

Comment nous configurons un domaine d'envoi avant de lancer une campagne

Sur les campagnes que nous opérons, l'authentification se règle avant même la constitution de la liste de prospects. Nous travaillons sur des domaines secondaires dédiés au cold email, distincts du domaine principal du client, pour qu'un incident de réputation ne touche jamais les emails de facturation ni les échanges avec les clients déjà signés.

Sur chaque domaine, nous publions les mêmes records de départ : v=spf1 include:_spf.google.com ~all pour SPF, la clé DKIM fournie par l'hébergeur sous son sélecteur, et v=DMARC1; p=none avec une adresse de rapports. Nous restons en p=none le temps du warmup, puis nous montons vers quarantine et enfin vers reject une fois que les rapports ne montrent plus que des sources connues. Cette progression fait partie de notre façon de travailler sur chaque nouveau domaine.

Nous tenons aussi une règle simple : un domaine, un service d'envoi. Multiplier les services sur un même domaine gonfle le nombre de résolutions DNS du record SPF et rapproche du plafond de dix, pour un bénéfice nul. Quand un client veut ajouter un outil, nous lui créons un sous-domaine plutôt que d'empiler les include: dans une ligne déjà chargée.

Nous relisons enfin les rapports DMARC toutes les semaines pendant le premier mois d'une campagne. C'est le seul moment où une source oubliée se révèle sans coûter un seul rendez-vous qualifié. Si vous voulez que nous regardions votre configuration actuelle avant de lancer quoi que ce soit, vous pouvez parler de votre prospection avec nous.

Par où commencer si vous partez de zéro

Commencez par le contrôle, pas par la modification. Lancez les trois requêtes DNS de la section précédente sur votre domaine d'envoi et notez ce qui manque. Dans la plupart des cas que nous voyons, SPF existe, DKIM est actif parce que l'hébergeur l'a créé automatiquement, et DMARC est purement absent. Publier une ligne p=none avec une adresse de rapports vous prend cinq minutes et vous donne enfin de la visibilité sur ce qui part en votre nom.

Réservez ensuite un créneau dans trois semaines pour lire vos premiers rapports. C'est ce rendez-vous avec vous-même qui décide si votre configuration tient, pas la publication des records elle-même. Un domaine authentifié dont personne ne lit les rapports finit par dériver, parce qu'un nouvel outil s'ajoute toujours quelque part sans que le record SPF suive.

À retenir : publiez un seul record SPF terminé par ~all, activez DKIM chez votre hébergeur et laissez la clé publique sous son sélecteur, puis posez v=DMARC1; p=none avec une adresse de rapports. Lisez ces rapports pendant un mois, corrigez les sources qui échouent, et montez seulement ensuite vers quarantine puis vers reject. Durcir la politique sans avoir lu les rapports coupe des emails légitimes, et vous l'apprenez toujours trop tard.

Questions fréquentes

Aller plus loin

• ›Agence de cold emailing B2B
• ›Délivrabilité cold email : pourquoi vos emails finissent en spam (et comment l'éviter)
• ›Parler de votre prospection avec nous