SPF, DKIM et DMARC : configurer l'authentification de vos emails

SPF, DKIM et DMARC sont trois enregistrements DNS qui répondent à une seule question, posée par le serveur qui reçoit votre message : cet email prétend venir de votre domaine, est-ce vrai ? Tant que la réponse est incertaine, votre message part avec un handicap qu'aucune qualité de rédaction ne rattrape.

Cette page explique ce que fait chacun des trois, dans quel ordre les déployer, et comment vérifier qu'ils sont réellement actifs. Elle fait partie de notre guide du cold email B2B.

Le problème que ces trois enregistrements résolvent

Le protocole d'envoi d'email, SMTP, a été conçu sans authentification. N'importe quel serveur peut écrire ce qu'il veut dans le champ From d'un message. C'est ce qui rend l'usurpation d'identité triviale, et c'est la raison pour laquelle les trois mécanismes décrits ici ont été ajoutés par-dessus, des années plus tard.

Chacun couvre une partie du problème, et aucun ne suffit seul :

Enregistrement	Ce qu'il prouve	Ce qu'il ne prouve pas
SPF	Que le serveur qui a envoyé le message est autorisé par votre domaine	Que le contenu du message n'a pas été modifié en route
DKIM	Que le message a bien été signé par votre domaine et n'a pas été altéré	Que le domaine signataire est celui que le lecteur voit
DMARC	Que le domaine affiché au lecteur est bien celui qui est authentifié, et dit quoi faire sinon	Rien de plus : il s'appuie entièrement sur les deux autres

La dernière colonne explique pourquoi la question ne se pose plus vraiment en termes de choix. Les trois se complètent, et DMARC est inutilisable si les deux premiers ne sont pas en place.

L'enjeu a changé de nature en février 2024, quand Google et Yahoo ont durci leurs exigences pour les expéditeurs en volume. Les règles publiées par Google imposent aux expéditeurs de plus de 5 000 messages par jour vers Gmail de disposer de SPF, de DKIM et de DMARC, d'un lien de désinscription en un clic, et de maintenir leur taux de plainte pour spam sous 0,3 %. Ce qui relevait de la bonne pratique est devenu une condition d'accès.

SPF : déclarer qui a le droit d'envoyer pour votre domaine

SPF, défini par la RFC 7208, est un enregistrement TXT publié sur votre domaine qui liste les serveurs autorisés à envoyer en son nom. Le serveur destinataire lit cette liste et la compare à l'adresse IP qui lui parle.

Un enregistrement ressemble à ceci :

• v=spf1 ouvre la déclaration, et doit toujours être en tête.
• include:_spf.google.com délègue l'autorisation à un fournisseur, ici Google Workspace. Un include par outil qui envoie pour vous.
• ip4: ou ip6: autorise une adresse ou une plage précise, pour un serveur que vous opérez vous-même.
• -all ferme la liste : tout ce qui n'est pas déclaré au-dessus doit être rejeté.

Trois points comptent plus que les autres.

Un seul enregistrement SPF par domaine. C'est une règle du protocole, pas une préférence. Deux enregistrements v=spf1 sur le même domaine produisent une erreur permanente, et le résultat est un échec, pas une addition des deux listes. Quand vous ajoutez un outil, vous complétez l'enregistrement existant, vous n'en créez pas un second.

La limite de dix résolutions DNS. La RFC 7208 plafonne à dix le nombre de requêtes DNS qu'un mécanisme SPF peut déclencher, et chaque include en consomme au moins une, parfois davantage puisqu'un include peut lui-même en contenir. Au-delà, la vérification échoue. C'est la panne la plus fréquente sur les domaines qui ont accumulé les outils marketing au fil des années, et elle est silencieuse : rien ne change visuellement, les messages partent toujours, ils passent simplement de « authentifié » à « échec de vérification ».

La différence entre -all et ~all. Le premier demande le rejet des messages non autorisés, le second signale l'anomalie sans l'imposer. Le second est confortable pendant le déploiement, quand vous n'êtes pas certain d'avoir recensé tous vos outils d'envoi. Il ne devrait pas être un état permanent : une liste qui n'exclut rien n'exclut personne.

DKIM : signer chaque message pour prouver qu'il n'a pas été modifié

DKIM, défini par la RFC 6376, ajoute une signature cryptographique à chaque message sortant. Votre serveur d'envoi signe avec une clé privée, publie la clé publique dans votre DNS, et le destinataire vérifie la correspondance.

Le mécanisme repose sur un sélecteur, un simple nom qui permet d'avoir plusieurs clés en parallèle. La clé publique se trouve sur selecteur._domainkey.votredomaine.fr, et l'en-tête DKIM-Signature du message indique quel sélecteur utiliser. C'est ce qui permet à chaque outil d'envoi d'avoir sa propre clé sans que les autres soient affectés, et c'est aussi ce qui rend possible la rotation d'une clé sans interruption de service.

Là où SPF authentifie le serveur, DKIM authentifie le message. La distinction devient concrète en cas de réacheminement : quand un destinataire fait suivre automatiquement vos emails vers une autre boîte, le serveur intermédiaire n'est pas dans votre liste SPF et la vérification échoue. La signature DKIM, elle, voyage avec le message et survit à ce transfert. C'est une des raisons de tenir les deux plutôt que de choisir.

Sur la longueur de clé, la pratique s'est déplacée vers 2048 bits. Certains hébergeurs DNS anciens n'acceptent pas des valeurs TXT aussi longues et imposent de découper l'enregistrement en plusieurs chaînes ; c'est une contrainte de saisie, pas un problème de sécurité.

DMARC : dire aux serveurs quoi faire quand SPF et DKIM échouent

DMARC, défini par la RFC 7489, se publie sur _dmarc.votredomaine.fr et remplit deux fonctions : il énonce une politique, et il demande des rapports.

La politique est portée par la balise p, qui prend trois valeurs :

Politique	Ce qu'elle demande au destinataire	Quand l'utiliser
p=none	Ne rien changer, mais envoyer des rapports	Au démarrage, pour observer sans risque
p=quarantine	Placer en indésirable les messages non conformes	Une fois les rapports lus et les envois légitimes tous alignés
p=reject	Refuser purement et simplement	En régime établi, quand plus rien de légitime n'échoue

La balise rua indique l'adresse à laquelle envoyer les rapports agrégés. Elle est le vrai intérêt de DMARC en phase de déploiement : ces rapports quotidiens, au format XML, listent toutes les sources qui envoient en votre nom, y compris celles que vous aviez oubliées et celles que vous n'avez jamais autorisées. Beaucoup d'organisations découvrent leur inventaire réel d'outils d'envoi en lisant leur premier rapport DMARC.

L'alignement, la notion qui fait échouer les configurations qui semblent correctes

C'est le point le plus mal compris, et celui qui explique la majorité des configurations qui affichent SPF et DKIM au vert tout en échouant à DMARC.

DMARC n'accepte pas simplement que SPF ou DKIM passe. Il exige que le domaine validé soit aligné avec le domaine que le lecteur voit dans le champ From. Or SPF vérifie un tout autre champ, l'enveloppe de retour, qui est souvent celui de votre prestataire d'envoi et non le vôtre. Le résultat classique : SPF passe, mais pour le domaine du prestataire, donc l'alignement échoue, donc DMARC échoue, alors que chaque test pris isolément semble bon.

La correction consiste à configurer un domaine de retour personnalisé chez votre prestataire, généralement un sous-domaine du vôtre, ou à vous appuyer sur DKIM dont le domaine signataire est plus simple à aligner. Un seul des deux alignements suffit à satisfaire DMARC.

L'alignement existe en deux modes : relâché, qui accepte un sous-domaine du domaine racine, et strict, qui exige une correspondance exacte. Le mode relâché est la valeur par défaut et convient dans presque tous les cas.

L'ordre de déploiement, et pourquoi il ne se discute pas

Publier p=reject avant d'avoir recensé ses expéditeurs revient à couper le courrier légitime que l'on avait oublié : la facturation automatique, l'outil de recrutement, la plateforme de signature électronique, le CRM. Le seul ordre sûr est incrémental.

• Recenser tout ce qui envoie en votre nom, avant d'écrire quoi que ce soit.
• Publier SPF avec un include par outil, et ~all le temps de la mise au point.
• Activer DKIM chez chaque prestataire, avec un sélecteur distinct par outil.
• Publier DMARC en p=none avec une adresse rua, et ne rien faire d'autre.
• Lire les rapports pendant plusieurs semaines, jusqu'à ce que toutes les sources légitimes soient alignées.
• Durcir en p=quarantine, observer encore, puis p=reject, et passer SPF en -all.

L'étape de lecture des rapports est celle que l'on saute, et c'est celle qui porte toute la valeur. Les cinq autres sont de la saisie DNS.

Comment vérifier que la configuration est réellement active

Un enregistrement publié n'est pas un enregistrement qui fonctionne. Trois contrôles, du plus rapide au plus fiable.

Interroger le DNS directement. Une requête TXT sur votre domaine renvoie l'enregistrement SPF, une requête sur _dmarc.votredomaine.fr renvoie la politique DMARC, et une requête sur selecteur._domainkey.votredomaine.fr renvoie la clé publique. Cela confirme la publication, et rien de plus.

Lire les en-têtes d'un message reçu. C'est le contrôle qui compte, parce qu'il donne le verdict du destinataire et non le vôtre. Envoyez-vous un message sur une boîte externe, affichez le message d'origine, et cherchez l'en-tête Authentication-Results : il indique noir sur blanc spf=pass, dkim=pass et dmarc=pass, ou l'échec correspondant. C'est aussi là que se lit un échec d'alignement, invisible partout ailleurs.

Lire les rapports DMARC agrégés. Seule source qui couvre l'ensemble de vos envois réels, sur la durée, y compris ceux dont vous ignorez l'existence. Le format XML brut est pénible à lire à la main ; les services d'analyse de rapports DMARC existent pour cela.

Les erreurs qui reviennent le plus souvent

• Deux enregistrements SPF sur le même domaine, généralement parce qu'un second outil a été ajouté sans toucher au premier. Le protocole ne les additionne pas, il échoue.
• Le dépassement des dix résolutions DNS, qui arrive par accumulation et ne produit aucun signal visible côté expéditeur.
• Le mécanisme +all, parfois copié depuis un forum, qui autorise la terre entière à envoyer en votre nom et annule l'intérêt de l'enregistrement.
• Un DMARC sans rua, qui vous prive des rapports et vous laisse durcir la politique à l'aveugle.
• Le passage direct à p=reject, sans phase d'observation.
• La confusion entre authentification et réputation. Les trois enregistrements prouvent que vous êtes bien vous. Ils ne disent rien de la qualité de vos envois, et n'empêchent pas un domaine authentifié d'aller en indésirable s'il génère des plaintes.

Ce que cela change pour une campagne de prospection

Ce dernier point mérite d'être développé, parce qu'il est la source d'une déception fréquente. L'authentification est une condition d'entrée, pas un levier de performance. Une fois les trois enregistrements en place, vous êtes au niveau attendu de tout expéditeur sérieux, vous n'avez pas pris d'avance.

Ce qui se joue ensuite relève de la délivrabilité au sens large : la réputation du domaine, la montée en volume progressive, la qualité de la liste, le taux de plainte. Un domaine parfaitement authentifié qui écrit à des adresses obsolètes accumulera des rebonds durs et verra sa réputation se dégrader malgré une configuration technique irréprochable. C'est la raison pour laquelle une vérification des adresses avant l'envoi et l'authentification vont ensemble.

Une pratique s'est imposée en prospection sortante : réserver un domaine distinct aux campagnes, souvent une variante proche du domaine principal, et l'authentifier de la même manière. L'intérêt n'est pas de contourner quoi que ce soit, mais de cloisonner : si la réputation du domaine de prospection se dégrade, la messagerie interne et la facturation continuent de partir normalement. Les erreurs fréquentes en cold email couvrent le reste de ce qui se passe après l'authentification.

Questions fréquentes

SPF, DKIM et DMARC sont-ils obligatoires ?

Aucune loi ne les impose, mais les principaux fournisseurs de messagerie en ont fait une condition d'acceptation. Depuis février 2024, Google exige des expéditeurs de plus de 5 000 messages par jour vers Gmail qu'ils disposent des trois, selon les règles publiées sur son site. En pratique, pour quiconque envoie en volume, la question n'est plus de savoir s'il faut les configurer.

Peut-on se contenter de SPF ?

Non, et pour une raison précise : SPF ne survit pas au réacheminement. Quand un destinataire fait suivre automatiquement votre message vers une autre boîte, le serveur intermédiaire n'est pas dans votre liste SPF et la vérification échoue. La signature DKIM voyage avec le message et reste valide. Sans DKIM, vous perdez l'authentification sur toute une catégorie de trajets courants.

Pourquoi ma configuration passe SPF et DKIM mais échoue à DMARC ?

Presque toujours à cause de l'alignement. DMARC n'exige pas seulement que SPF ou DKIM réussisse, il exige que le domaine validé corresponde à celui affiché dans le champ From. Or SPF vérifie l'enveloppe de retour, qui est souvent celle de votre prestataire d'envoi. La correction consiste à configurer un domaine de retour personnalisé chez ce prestataire, ou à aligner le domaine signataire DKIM.

Combien de temps faut-il rester en p=none avant de durcir ?

Le temps de voir passer un cycle complet d'envois, ce qui prend en général quelques semaines. Le critère n'est pas la durée mais le contenu des rapports : vous pouvez durcir quand toutes les sources légitimes qui y apparaissent sont alignées, et pas avant. Une facturation annuelle ou un outil utilisé une fois par trimestre ne se manifestera pas dans les premiers jours.

Faut-il un DKIM différent par outil d'envoi ?

Oui, et c'est précisément à cela que sert le sélecteur. Chaque prestataire génère sa propre paire de clés et publie la clé publique sous son propre sélecteur. Les enregistrements coexistent sans se gêner, et retirer un outil se limite à supprimer son sélecteur, sans toucher aux autres.

Ces enregistrements suffisent-ils à ne plus tomber en spam ?

Non. Ils prouvent votre identité, ils ne disent rien de la qualité de vos envois. Un domaine parfaitement authentifié qui écrit à des adresses obsolètes ou qui génère des plaintes verra sa réputation se dégrader malgré une configuration irréprochable. L'authentification est une condition d'entrée, la réputation est ce qui se joue ensuite.