SPF, DKIM et DMARC expliqués : le guide de configuration complet

L’email a été inventé dans les années 1970, bien avant que quiconque s’inquiète du spam ou du phishing. Le protocole d’origine (SMTP) est incapable de vérifier qu’un message provient réellement du domaine qu’il prétend représenter. N’importe qui peut donc envoyer un email en se faisant passer pour you@yourdomain.com, et seule l’authentification permet aux fournisseurs de messagerie de faire la différence.

SPF, DKIM et DMARC ont été créés pour corriger ce problème. Ensemble, ils répondent à trois questions essentielles : le serveur d’envoi est-il autorisé ? (SPF), le message a-t-il été altéré ? (DKIM) et que faire si l’authentification échoue ? (DMARC). Lorsque vous configurez correctement les trois, vous obtenez plusieurs avantages majeurs pour votre délivrabilité email.

SPF (Sender Policy Framework) est un enregistrement DNS qui indique aux serveurs de réception quelles adresses IP et quels serveurs sont autorisés à envoyer des emails au nom de votre domaine. Voyez-le comme une liste d’invités pour vos emails : seuls les serveurs inscrits sur la liste sont considérés comme fiables.

Lorsqu’une personne reçoit un email de you@yourdomain.com, le serveur de réception recherche un enregistrement SPF dans le DNS de votre domaine. Il compare ensuite l’adresse IP du serveur qui a réellement envoyé l’email à la liste des expéditeurs autorisés. S’il y a correspondance, SPF est validé. Sinon, SPF échoue, et l’email risque davantage d’être classé en spam ou rejeté purement et simplement.

Un enregistrement SPF est un enregistrement TXT ajouté au DNS de votre domaine. Voici à quoi ressemble un enregistrement SPF typique :

Décryptons chaque élément :

DKIM (DomainKeys Identified Mail) ajoute une signature numérique à chaque email sortant. Cette signature est générée à l’aide d’une clé privée que seul votre serveur de messagerie connaît, et vérifiée grâce à une clé publique publiée dans votre DNS. Elle prouve deux choses : l’email provient bien de votre domaine, et il est resté intact en transit.

Si SPF est la liste d’invités, DKIM est le sceau de cire sur l’enveloppe. Même si quelqu’un intercepte le message, toute modification des en-têtes ou du corps brisera la signature, et le serveur de réception le saura.

La clé publique DKIM est publiée sous forme d’enregistrement TXT sur un sous-domaine précis. Ce sous-domaine suit le format selector._domainkey.yourdomain.com, où le sélecteur est un nom choisi par votre fournisseur de messagerie :

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la couche de politique qui relie SPF et DKIM. Il indique aux serveurs de réception quoi faire lorsqu’un email échoue à l’authentification, et vous donne de la visibilité sur les expéditeurs qui utilisent votre domaine.

En l’absence de DMARC, quand SPF ou DKIM échoue, le serveur de réception décide à sa guise (avec de fortes variations d’un fournisseur à l’autre). DMARC vous permet, en tant que propriétaire du domaine, de définir une politique explicite : laisser passer, mettre en quarantaine ou rejeter purement et simplement.

Chaque protocole gère une pièce différente du puzzle. SPF vérifie le serveur d’envoi, DKIM vérifie l’intégrité du message et DMARC applique la politique. Voici le déroulement complet lorsqu’un serveur de réception traite votre email :

Le concept clé ici est l’alignement. DMARC exige que le domaine utilisé par SPF ou DKIM corresponde (soit aligné) au domaine de l’en-tête From: de l’email. Cela empêche un attaquant de valider SPF avec son propre domaine tout en usurpant le vôtre dans l’adresse d’expédition. Pour que DMARC soit validé, au moins l’un des deux, SPF ou DKIM, doit être validé et aligné.

C’est pourquoi il est essentiel de disposer des trois protocoles. SPF seul laisse l’en-tête From exposé à l’usurpation. DKIM seul laisse le destinataire décider de la marche à suivre en cas d’échec. DMARC les relie dans une solution complète. Pour approfondir l’impact de l’authentification sur votre réputation d’expéditeur, consultez notre guide de la délivrabilité email.

Google Workspace gère automatiquement la signature DKIM dès que vous publiez la clé. Voici comment configurer les trois enregistrements. Vous aurez besoin d’accéder à votre fournisseur DNS (Cloudflare, Namecheap, GoDaddy, Route 53, etc.) et à votre console d’administration Google.

Microsoft 365 (Exchange Online) demande une approche légèrement différente, surtout pour DKIM. La configuration de SPF et DMARC ressemble à celle de Google Workspace, mais DKIM utilise des enregistrements CNAME au lieu d’enregistrements TXT.

Microsoft utilise des enregistrements CNAME pour DKIM au lieu d’enregistrements TXT. Cela lui permet de renouveler automatiquement les clés DKIM, et votre DNS reste à jour de lui-même.

La configuration de DMARC est identique quel que soit votre fournisseur de messagerie : c’est un enregistrement DNS sur votre domaine. Suivez les mêmes étapes que pour Google Workspace : commencez par p=none, surveillez, puis durcissez.

Configurer les enregistrements DNS représente la moitié du travail. L’autre moitié consiste à vérifier que tout fonctionne correctement. Voici les meilleures façons de contrôler votre configuration SPF, DKIM et DMARC. Cette vérification est particulièrement importante si vous menez un processus de warm-up sur un nouveau domaine.

Plusieurs outils gratuits permettent de contrôler vos enregistrements directement, avant tout email de test :

Même les équipes expérimentées gagnent à vérifier ces points. Chacun peut faire chuter silencieusement votre délivrabilité email, en toute discrétion. Voici les bonnes pratiques à appliquer :

L’authentification email s’entretient dans la durée. Votre infrastructure d’envoi évolue : vous ajouterez de nouveaux outils marketing, changerez de CRM, intégrerez des services d’emails transactionnels ou étendrez votre activité à de nouveaux domaines. Chaque changement nécessite une mise à jour de vos enregistrements DNS.

Voici une checklist de maintenance pour garder une authentification saine. Elle est particulièrement utile si vous gérez plusieurs domaines ou si vous lancez des séquences de relance cold email sur différentes infrastructures d’envoi.

Lorsque vous intégrez un nouveau service d’envoi, suivez toujours ce processus : (1) ajoutez l’include: du service à votre enregistrement SPF, (2) publiez la clé DKIM du service dans votre DNS, (3) envoyez un email de test et vérifiez que l’authentification est validée, puis (4) seulement ensuite, commencez à envoyer vos vrais emails via ce service. Cela protège la réputation de votre domaine contre des échecs d’authentification temporaires.

Si votre équipe gère plusieurs domaines, pensez à créer un inventaire centralisé de l’authentification : un simple tableur listant chaque domaine, chaque service d’envoi autorisé et le niveau actuel de la politique DMARC. Relisez-le chaque trimestre pour repérer les dérives.