SPF, DKIM et DMARC : authentifier ses emails et protéger son domaine

SPF, DKIM et DMARC sont trois protocoles d'authentification des emails qui prouvent l'authenticité d'un message : il vient bien du nom de domaine qu'il affiche. SPF publie dans le DNS la liste des serveurs autorisés à envoyer pour un nom de domaine, DKIM ajoute une signature cryptographique vérifiée grâce à une clé publique, et DMARC indique aux messageries ce qu'elles doivent faire d'un mail qui échoue à ces contrôles, tout en renvoyant des rapports au propriétaire du nom. Configurés ensemble, ils protègent le domaine contre l'usurpation et le phishing et améliorent la délivrabilité. Depuis février 2024, Gmail et Yahoo exigent cette authentification de tous les expéditeurs, et l'enregistrement DMARC des envois en volume.

Qu'est-ce que SPF, DKIM et DMARC ?

Le protocole SMTP, qui transporte le courrier électronique depuis les années 1980, ne contrôle pas l'identité de celui qui écrit : n'importe quel serveur peut envoyer un message en prétendant venir de votre adresse. C'est cette faiblesse qu'exploitent le spam, les envois malveillants et le phishing. Les trois normes SPF, DKIM et DMARC ont été conçues pour y répondre. Elles reposent toutes sur le DNS, le système de noms de domaine : le propriétaire du domaine y publie des informations que les serveurs de messagerie consultent à la réception de chaque mail.

Aucune ne suffit seule. SPF vérifie le serveur d'envoi, DKIM vérifie l'intégrité du message et le domaine qui l'a signé, DMARC relie ces deux résultats au From visible par le destinataire et fixe une règle. On les présente souvent comme un trio parce qu'un domaine bien protégé met en œuvre les trois, et parce que les grandes messageries évaluent désormais leur présence.

SPF, Sender Policy Framework

SPF (Sender Policy Framework, norme RFC 7208) est un enregistrement TXT publié dans la zone DNS du domaine. Il liste les IP et les services autorisés à envoyer des emails au nom de ce domaine : votre serveur de messagerie, votre fournisseur comme Google Workspace ou Microsoft 365, votre outil d'emailing. À la réception, le serveur du destinataire compare l'IP de la machine émettrice avec ce texte publié. Si elle y figure, la vérification SPF est réussie ; sinon, elle échoue.

Point souvent mal compris : SPF contrôle le domaine de l'enveloppe technique du message (l'adresse de retour, ou Return-Path), pas le champ From que lit le destinataire. C'est l'une des raisons pour lesquelles DMARC est nécessaire.

DKIM, DomainKeys Identified Mail

DKIM (DomainKeys Identified Mail, norme RFC 6376) ajoute un cachet numérique dans le header de chaque message envoyé. Le serveur d'envoi signe certaines parties du mail avec une clé privée ; la clé publique correspondante est publiée dans le DNS, sous un nom de la forme selecteur._domainkey.example.com. Le serveur de réception récupère cette clé, vérifie la signature et sait ainsi deux choses : le message n'a pas été modifié en route, et il a bien été signé par le nom indiqué dans le header DKIM.

Le sélecteur permet d'utiliser plusieurs clés sur un même domaine, par exemple une pour la messagerie interne et une pour l'outil d'emailing. DKIM résiste mieux que SPF aux transferts : un message transféré par un autre serveur garde sa signature tant que son contenu n'est pas modifié.

DMARC, Domain-based Message Authentication, Reporting and Conformance

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) s'appuie sur les deux autres. Il est publié dans un enregistrement TXT au nom _dmarc.example.com et remplit trois fonctions. Il exige d'abord l'alignement : pour qu'un message passe DMARC, le domaine validé par SPF ou celui de la signature DKIM doit correspondre au domaine de l'adresse From. Il permet ensuite de définir ce que le destinataire doit faire d'un mail qui échoue. Il organise enfin le reporting : les messageries envoient au propriétaire du domaine des rapports qui indiquent quels serveurs envoient en son nom et avec quel résultat.

Comment fonctionne l'authentification d'un email ?

Prenons un message envoyé depuis contact@example.com vers une boîte Gmail. À la réception, le serveur de réception effectue plusieurs contrôles en quelques millisecondes :

1. il lit l'adresse IP du serveur qui lui parle et consulte le record SPF du domaine de retour ;
2. il cherche la signature DKIM dans l'en-tête, récupère la clé publique dans le DNS et vérifie la signature ;
3. il consulte l'enregistrement DMARC du domaine affiché dans le From et contrôle qu'au moins un des deux résultats précédents est réussi et aligné ;
4. il applique la règle DMARC en cas d'échec, puis combine ces résultats avec d'autres signaux (réputation, plaintes, contenu) pour décider du placement en boîte de réception, en courrier indésirable ou du rejet.

Le résultat de ces contrôles est visible dans l'en-tête du message reçu, à la ligne Authentication-Results. Dans Gmail, l'option « Afficher l'original » indique pour chaque mail si SPF, DKIM et DMARC sont validés. C'est la manière la plus simple de tester un paramétrage sans outil.

Comment configurer SPF, DKIM et DMARC ?

La mise en place se fait dans la zone DNS du domaine, chez le bureau d'enregistrement ou l'hébergeur qui la gère, et dans l'interface de chaque service d'envoi. L'ordre conseillé est toujours le même : SPF, puis DKIM, puis DMARC en mode observation.

Étape 1 : publier l'enregistrement SPF

Commencez par recenser tous les services qui envoient des mails avec votre domaine : messagerie, outil d'emailing, logiciel de facturation, CRM, formulaire du site web, service client. Chaque fournisseur indique dans sa documentation la valeur à ajouter, le plus souvent un mécanisme include:. Un nouvel enregistrement TXT de ce type ressemble à ceci :

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

La fin de l'enregistrement fixe le traitement des serveurs non listés : -all demande un échec strict, ~all un échec « doux » qui laisse passer le message en le marquant. Trois règles évitent la plupart des problèmes :

• un seul enregistrement SPF par domaine : deux enregistrements qui commencent par v=spf1 rendent la vérification invalide ;
• pas plus de 10 recherches DNS au total (chaque include, a, mx en compte au moins une), sans quoi le résultat est une erreur permanente ;
• un domaine qui n'envoie jamais de mail peut publier v=spf1 -all, ce qui signale qu'aucun serveur n'est autorisé.

Étape 2 : activer la signature DKIM

La clé DKIM se génère dans l'outil d'envoi : dans la console d'administration de Google Workspace, dans Microsoft 365, ou dans les paramètres de domaine d'un service d'emailing. L'outil fournit le nom de l'enregistrement (avec son sélecteur) et sa valeur, à publier en TXT ou en CNAME selon le fournisseur. Une fois l'enregistrement en ligne, il faut revenir dans l'outil pour activer la signature. Une clé de 2048 bits est aujourd'hui recommandée quand le fournisseur la propose. Chaque service d'envoi doit signer avec votre domaine : un outil qui signe avec son propre domaine passera DKIM, mais pas l'alignement DMARC.

Étape 3 : publier une politique DMARC en mode observation

Le premier enregistrement DMARC se publie avec la valeur p=none, qui ne bloque rien mais déclenche l'envoi des rapports :

v=DMARC1; p=none; rua=mailto:rapports@example.com

La balise rua désigne l'adresse qui recevra les rapports agrégés, des fichiers XML envoyés en général une fois par jour par chaque grande messagerie. Ces données sont difficiles à lire à la main : des services spécialisés les transforment en tableaux par source d'envoi. D'autres balises existent : sp pour la politique des sous-domaines, pct pour appliquer la politique à une partie seulement des messages, adkim et aspf pour choisir un alignement strict ou souple.

Étape 4 : durcir progressivement la politique

Après quelques semaines de lecture des rapports, quand toutes les sources légitimes passent DMARC, le niveau peut évoluer vers p=quarantine (les mails non conformes vont en spam), puis vers p=reject (ils sont refusés). C'est à ce niveau que DMARC protège réellement le domaine contre l'usurpation. Passer directement en reject sans phase d'observation est l'erreur classique : un service oublié, comme l'outil de facturation, voit alors ses messages rejetés sans que personne ne s'en aperçoive.

Les exigences de Gmail, Yahoo et Outlook pour les expéditeurs

L'authentification n'est plus une simple bonne pratique. Depuis le 1er février 2024, Google impose à tous ceux qui écrivent vers des comptes Gmail personnels de configurer SPF ou DKIM, de disposer d'enregistrements DNS valides et de maintenir un taux de spam signalé inférieur à 0,3 %. Les organisations qui envoient plus de 5 000 messages par jour vers Gmail doivent en plus configurer SPF et DKIM, publier un enregistrement DMARC (la politique none est acceptée), aligner le domaine du From avec SPF ou DKIM et proposer un désabonnement en un clic dans les messages marketing. Yahoo a annoncé des règles équivalentes à la même date.

Microsoft a suivi en 2025 pour Outlook.com, Hotmail et Live : les domaines qui envoient plus de 5 000 messages par jour vers ces adresses doivent passer SPF, DKIM et DMARC avec au moins la politique none, sous peine de voir leurs messages rejetés. Les règles détaillées et leur calendrier évoluent ; la référence reste la page officielle de chaque fournisseur, comme les consignes de Google pour les expéditeurs d'e-mails.

Pour une entreprise qui fait de la prospection ou de l'emailing B2B, la conséquence est directe : un domaine sans authentification voit ses envois classés en courrier indésirable, voire refusés, quelle que soit la qualité du message.

Pourquoi mes emails finissent dans les spams malgré SPF, DKIM et DMARC ?

L'authentification est une condition nécessaire, pas suffisante. Elle prouve que le message vient bien de vous ; elle ne dit rien de votre réputation. Un domaine parfaitement configuré qui envoie à des adresses invalides ou à des contacts qui n'ont rien demandé finira quand même en spam. Les causes les plus fréquentes sont :

• une liste de mauvaise qualité, avec beaucoup d'adresses inexistantes : un nettoyage de la base email réduit les rebonds ;
• un taux de plainte élevé, souvent lié à des contacts qui ne connaissent pas la marque ou à une désinscription difficile à trouver ;
• un domaine neuf qui envoie d'un coup de gros volumes, sans montée en charge progressive ;
• un défaut d'alignement : SPF et DKIM sont réussis, mais pour le domaine du prestataire et non pour le vôtre, donc DMARC échoue ;
• un contenu qui ressemble à du phishing : liens raccourcis, pièces jointes inattendues, Reply-To différent de l'auteur affiché.

Le guide sur la délivrabilité des emails détaille ces facteurs et les indicateurs à surveiller.

Comment vérifier SPF, DKIM et DMARC ?

Trois méthodes complémentaires permettent de contrôler le paramétrage. La première est l'en-tête d'un message reçu, déjà évoqué : la ligne Authentication-Results donne le verdict de chaque protocole et le domaine contrôlé. La deuxième consiste à interroger le DNS. En ligne de commande, nslookup -type=TXT example.com affiche le TXT SPF, nslookup -type=TXT _dmarc.example.com celui de DMARC. Des outils de vérification en ligne, gratuits pour la plupart, font la même chose avec une interface et signalent les erreurs de syntaxe, le dépassement des 10 recherches SPF ou une clé DKIM introuvable.

La troisième méthode, la plus complète, est la lecture des rapports DMARC sur la durée. Elle révèle les services d'envoi oubliés, les serveurs qui usurpent le domaine et la part réelle des messages conformes. Google propose aussi, dans Postmaster Tools, un suivi de l'authentification et du taux de spam pour les domaines qui envoient vers Gmail.

Les avantages de SPF, DKIM et DMARC

Le premier bénéfice est la sécurité. Avec une politique DMARC en reject, un fraudeur ne peut plus envoyer de faux mails qui affichent exactement votre domaine dans le From : ces messages sont refusés par les messageries qui appliquent la norme. Vos clients, vos fournisseurs et vos salariés sont mieux protégés contre le phishing qui usurpe votre marque, l'un des vecteurs d'abus les plus courants contre les entreprises.

Le deuxième est la délivrabilité : un domaine authentifié et aligné inspire davantage confiance aux filtres, et c'est désormais une exigence pour envoyer en volume. Le troisième est la visibilité. Les rapports DMARC donnent une carte de tous les flux qui utilisent le domaine, ce que peu d'organisations connaissent avec précision. Enfin, une politique DMARC en quarantine ou en reject ouvre l'accès à BIMI, la norme qui permet d'afficher le logo de la marque à côté des messages dans certaines boîtes de réception.

Sécurité : menaces, compromission et infrastructure d'envoi

Ces protocoles répondent à une menace précise : le faux message qui se fait passer pour une marque connue. Ils ne remplacent pas les autres mesures de sécurité. Le chiffrement SSL ou TLS entre serveurs, sur le port 25 ou le port de soumission 587, protège le transport du message, pas l'identité de son auteur. À l'inverse, DKIM authentifie le contenu mais ne le chiffre pas.

La clé privée DKIM doit être protégée comme un mot de passe. En cas de compromission d'un serveur ou d'un compte d'envoi, la bonne pratique est de générer une nouvelle paire de clés, de publier la nouvelle clé publique sous un autre sélecteur, puis de retirer l'ancienne : cette rotation, prévue dès la conception de la norme, se fait sans coupure. Un serveur mal configuré en relais ouvert (open relay), qui accepte d'envoyer pour n'importe qui, ruine en quelques heures la réputation de toute l'infrastructure.

Avec une infrastructure dans le cloud, l'utilisation de plusieurs services est la règle : messagerie hébergée, plateforme d'emailing, API d'envoi transactionnel, outil de support client. Chacun doit être déclaré dans SPF et signer avec votre nom de domaine. Un sous-domaine spécifique par usage (par exemple news.example.com pour les campagnes) permet d'isoler la réputation de chaque flux et de déterminer plus facilement l'origine d'un problème.

Outils, formation et coût de la mise en œuvre

Publier un record TXT ne coûte rien : la gestion de la zone est comprise dans la plupart des offres de nom de domaine, et l'activation de DKIM est incluse dans les produits de messagerie professionnelle et les outils d'emailing du marché. Le coût réel tient au temps passé à recenser les flux et à lire les rapports. Pour les analyser, des services spécialisés existent, avec des tarifs qui dépendent surtout du volume de messages et du nombre de domaines suivis ; plusieurs proposent une formule gratuite limitée, suffisante pour une petite organisation. Avant de choisir, il faut comparer ce que chaque tarif couvre : nombre de rapports traités, alertes, accompagnement au déploiement.

Côté ressources, la documentation de chaque fournisseur (centre d'aide de Google Workspace, de Microsoft 365, de votre outil d'emailing) donne les valeurs exactes à publier. L'Afnic, qui gère le .fr, propose une formation dédiée à la sécurisation des emails par ces trois protocoles, utile aux équipes qui administrent elles-mêmes leurs domaines. Pour un premier check, un outil de vérification en ligne et un message test envoyé vers une boîte Gmail suffisent à mesurer où en est la configuration.

Les erreurs courantes lors de la configuration

La plupart des problèmes viennent d'un petit nombre d'erreurs, faciles à éviter si l'on vérifie chaque étape :

• Deux enregistrements SPF sur le même domaine, souvent ajoutés par deux prestataires différents : il faut les fusionner en un seul.
• Trop de mécanismes include, qui dépassent la limite de 10 recherches DNS : retirer les services qui ne servent plus, ou envoyer certains flux depuis un sous-domaine.
• DKIM généré mais pas activé dans l'outil : la clé est publiée, mais les messages ne sont pas signés.
• Un passage trop rapide en reject, avant d'avoir identifié toutes les sources légitimes.
• Une adresse rua jamais lue : les rapports arrivent, mais personne ne les analyse, et la politique reste en none pendant des années.
• Les sous-domaines oubliés, que les fraudeurs utilisent quand le domaine principal est protégé : la balise sp permet de leur appliquer une politique.
• Les domaines inactifs non protégés : un domaine qui n'envoie rien doit publier un SPF en -all et un DMARC en reject.

SPF, DKIM, DMARC et prospection : ce que l'authentification ne règle pas

Configurer ces protocoles rend vos envois techniquement légitimes, pas juridiquement conformes. La prospection par email reste soumise à l'article L34-5 du Code des postes et des communications électroniques et au RGPD : consentement préalable pour les particuliers, intérêt légitime et lien avec la profession pour les professionnels, identification de l'annonceur et moyen simple de s'opposer aux envois. Un lien de désinscription visible fait partie des obligations, et Gmail l'exige aussi sous forme de header en un clic pour les envois en volume.

Utiliser un domaine bien authentifié pour envoyer à un fichier d'adresses collectées sans base légale ne protège ni la réputation ni l'entreprise : les plaintes dégradent le domaine, et l'envoi reste sanctionnable. L'authentification est la base technique d'un email marketing propre, à côté d'une liste construite dans les règles.

SPF, DKIM et DMARC : questions fréquentes

Faut-il configurer les trois protocoles ?

Oui. SPF et DKIM authentifient, DMARC vérifie l'alignement avec l'adresse visible et applique une politique. Pour les envois de plus de 5 000 messages par jour vers Gmail ou Outlook, les trois sont exigés.

Combien de temps faut-il pour que l'enregistrement soit pris en compte ?

La propagation DNS prend de quelques minutes à 48 heures selon la durée de cache (TTL) de la zone. Il faut ensuite plusieurs jours de rapports DMARC pour avoir une vue fiable des sources d'envoi.

Que choisir entre ~all et -all pour SPF ?

Quand DMARC est en place, la différence pèse moins, car c'est DMARC qui décide. Beaucoup d'administrateurs gardent ~all pendant la phase d'observation et passent à -all une fois toutes les sources connues.

DMARC en p=none protège-t-il le domaine ?

Non. Le mode none sert à observer et à recevoir les rapports ; il ne demande aucune action contre les messages frauduleux. La protection contre les faux messages commence avec quarantine et devient complète avec reject.