Protocoles SPF, DKIM et DMARC : pourquoi et comment les configurer ?

25 septembre 2026

SPF, DKIM et DMARC sont les trois protocoles d’authentification qui permettent de prouver qu’un message provient bien de votre domaine. Le premier liste les serveurs autorisés à envoyer des mails en votre nom, le deuxième appose une signature numérique sur chaque message, le troisième indique aux serveurs de messagerie quoi faire lorsque ces contrôles échouent et vous envoie des rapports. Ensemble, ces normes protègent votre nom de domaine contre le phishing et l’usurpation d’identité, et améliorent l’arrivée de vos campagnes en boîte de réception. Dans cet article, nous voyons ce que recouvre le trio SPF DKIM DMARC, leur différence, comment les configurer étape par étape dans votre zone DNS et comment vérifier que tout fonctionne correctement.

Les attaques par courrier électronique sont de plus en plus nombreuses et ciblées. Le phishing, ou hameçonnage, consiste à envoyer un message en se faisant passer pour un organisme de confiance (banque, administration, transporteur) afin de récupérer des données confidentielles. Le protocole SMTP, sur lequel repose l’envoi des mails, n’a pas été conçu pour vérifier l’identité de l’expéditeur : n’importe quel serveur peut prétendre envoyer au nom de votre domaine. SPF, DKIM et DMARC comblent cette faille. Ce sont des enregistrements DNS publiés sur votre domaine d’envoi, que les serveurs de messagerie des destinataires consultent automatiquement à chaque message reçu.

Le protocole SPF (Sender Policy Framework) est une méthode d’authentification qui fait le lien entre un nom de domaine et les serveurs autorisés à envoyer du courrier en son nom. Concrètement, le propriétaire du domaine publie dans sa zone DNS un enregistrement de type TXT (le « SPF record ») qui liste les adresses IP et les outils d’envoi autorisés : votre mail server, votre service de routage, votre CRM, votre solution de support client, etc. Tout ce qui n’y figure pas est considéré comme non autorisé par défaut.

Lorsqu’un message entrant arrive, le serveur du destinataire lit le domaine indiqué dans l’adresse de retour (le « Return-Path », aussi appelé enveloppe ou « MAIL FROM ») et vérifie si l’adresse IP de l’expéditeur figure dans l’enregistrement SPF. Si c’est le cas, la vérification SPF est validée (pass). Sinon, elle échoue (fail ou softfail), et le message devient suspect.

Le protocole DKIM (DomainKeys Identified Mail) fait le lien entre un nom de domaine et un message. Il repose sur une paire de clés cryptographiques : une clé privée, conservée par le serveur d’envoi, qui sert à signer chaque mail, et une clé publique, publiée dans le DNS de votre domaine. La signature DKIM est ajoutée dans l’en-tête du message (champ « DKIM-Signature »), avec le domaine signataire et un sélecteur qui indique où trouver la clé publique.

À la réception, le serveur récupère la clé publique et vérifie la signature. DKIM prouve ainsi deux choses : le message a bien été autorisé par le domaine signataire, et son contenu n’a pas été modifié en cours de route. C’est un gage d’authenticité que SPF seul ne fournit pas.

Le protocole DMARC (Domain-based Message Authentication, Reporting and Conformance) est une norme complémentaire qui s’appuie sur SPF et DKIM. Il apporte deux éléments que ces derniers ne gèrent pas. D’abord, une politique : le propriétaire du domaine indique aux fournisseurs de messagerie comment traiter les messages qui échouent à l’authentification (les laisser passer, les placer en quarantaine ou les rejeter). Ensuite, un système de reporting : les serveurs destinataires envoient des rapports réguliers qui montrent qui envoie des mails avec votre domaine, et avec quel résultat.

DMARC introduit aussi la notion d’alignement : pour réussir, le domaine validé par SPF ou par DKIM doit correspondre au domaine visible dans le champ « From », celui que lit le destinataire. C’est ce point qui empêche un fraudeur d’utiliser votre marque dans l’adresse d’expéditeur tout en passant SPF avec son propre domaine.

Les trois protocoles ne répondent pas à la même question. SPF vérifie le serveur qui envoie, DKIM vérifie l’intégrité et l’origine du message, DMARC vérifie la cohérence avec l’adresse visible et définit la règle à appliquer. L’authentification DKIM et l’authentification DMARC complètent donc SPF au lieu de le remplacer.

Protocole	Ce qu’il vérifie	Où il est publié	Limite principale
SPF	L’adresse IP du serveur d’envoi est-elle autorisée par le domaine ?	Enregistrement DNS sur le domaine (ou sous-domaine) d’envoi	Se casse lors d’un transfert, limité à 10 requêtes DNS
DKIM	Le message est-il signé par le domaine et intact ?	Enregistrement DNS sur selecteur._domainkey.votredomaine	Ne dit pas quoi faire si la signature est invalide
DMARC	SPF ou DKIM passe-t-il avec un domaine aligné sur le « From » ?	Enregistrement DNS (« DMARC record ») sur _dmarc.votredomaine	Nécessite que SPF et DKIM soient correctement en place

Voici ce qui se passe lorsqu’un serveur de messagerie reçoit un mail qui prétend venir de votre domaine :

1. Il interroge le DNS du domaine de retour et vérifie l’enregistrement SPF.
2. Il lit la signature DKIM, récupère la clé publique et contrôle que le message n’a pas été altéré.
3. Il consulte l’enregistrement DMARC du domaine affiché dans le « From » et vérifie qu’au moins un des deux contrôles précédents passe avec un domaine aligné.
4. Il applique la politique DMARC si le contrôle n’est pas concluant, puis intègre le résultat dans le rapport envoyé au propriétaire du domaine.

Aucun de ces protocoles ne suffit seul. SPF sans DMARC n’empêche pas l’usurpation du « From ». DKIM sans DMARC ne dit rien du traitement à appliquer. DMARC sans SPF ni DKIM n’a rien à évaluer. C’est leur combinaison qui crée une authentification fiable.

Ces protocoles sont devenus des standards de l’envoi de mails. Un message expédié sans authentification est considéré avec méfiance par les filtres anti-spam, et de plus en plus souvent refusé. Leurs avantages se résument en trois points : protection de votre domaine, meilleure réputation d’expéditeur et conformité avec les exigences des grandes messageries.

Sans DMARC, un fraudeur peut envoyer des messages avec votre nom de domaine dans l’adresse d’expéditeur, à vos clients, vos partenaires ou vos collaborateurs. Ces attaques, souvent appelées spoofing, alimentent le phishing et la fraude au président. Avec une politique DMARC stricte, les serveurs destinataires peuvent les rejeter ou les marquer comme indésirables automatiquement. Vous protégez ainsi vos contacts, mais aussi l’image de votre marque : un client victime d’un faux mail à votre nom associe durablement l’incident à votre entreprise.

Un domaine authentifié est mieux identifié par les fournisseurs de messagerie. Les messages légitimes, authentiques et correctement signés, ont alors plus de chances d’arriver dans la boîte de réception plutôt que dans le dossier spam ou courrier indésirable. L’authentification permet aussi aux fournisseurs d’attribuer une réputation stable à votre domaine, construite sur l’historique de vos envois. C’est une condition pour améliorer la délivrabilité, pas une garantie : la qualité de votre base, le consentement de vos contacts, l’engagement et le taux de plaintes pèsent tout autant.

Enfin, DMARC ouvre la porte à BIMI (Brand Indicators for Message Identification), qui permet d’afficher le logo de votre marque à côté de vos messages dans certaines messageries. BIMI exige une politique DMARC en quarantaine ou en rejet : un moyen visible de renforcer la confiance de vos destinataires.

Depuis février 2024, Google et Yahoo imposent de nouvelles règles aux expéditeurs. Tous doivent au minimum authentifier leurs envois avec SPF ou DKIM. Les expéditeurs de masse, qui envoient plus de 5 000 messages par jour vers des adresses Gmail, doivent aller plus loin : SPF et DKIM obligatoires, un enregistrement DMARC publié (au moins en mode « p=none ») avec un domaine aligné, un lien de désinscription en un clic et un taux de spam maîtrisé. Microsoft applique des exigences comparables depuis mai 2025 pour les gros volumes envoyés vers Outlook.com et Hotmail. Autrement dit, configurer SPF, DKIM et DMARC n’est plus une option pour une organisation qui fait de l’emailing. Ces fournisseurs peuvent refuser d’accepter les messages non conformes provenant de votre domaine.

La mise en œuvre se fait dans l’ordre : SPF, puis DKIM, puis DMARC. Chaque étape consiste à créer ou modifier un enregistrement DNS, sous forme de texte.

Pour configurer les paramètres d’authentification, connectez-vous au compte de votre hébergeur ou registrar (OVHcloud, Gandi, IONOS, Cloudflare, o2switch…) et ouvrez la zone DNS du domaine. Si vous n’y avez pas accès, votre fournisseur d’hébergement ou votre équipe informatique peut vous aider, et la plupart des hébergeurs proposent un centre d’aide dédié. Faites aussi la liste de tous les outils qui envoient des mails avec votre domaine de messagerie : messagerie professionnelle (Google Workspace, Microsoft 365), plateforme de routage, outil de facturation, site web e-commerce, CRM, prestataires externes. Un outil oublié, c’est un risque de blocage de vos propres messages.

La configuration de SPF passe par un seul enregistrement publié sur le domaine d’envoi. Exemple de valeur publiée sur example.com, pour un domaine qui utilise Google Workspace et Mailjet :

"v=spf1 include:_spf.google.com include:spf.mailjet.com ~all"

Quelques règles à retenir :

• Un seul enregistrement SPF par domaine. Si vous en publiez plusieurs, la vérification échoue. Pour autoriser un nouvel outil, modifiez l’enregistrement existant au lieu d’en créer un nouveau.
• Utilisez le type TXT. L’ancien type d’enregistrement « SPF » est abandonné : seul le TXT record est pris en charge par les serveurs.
• Respectez la limite de 10 requêtes DNS. Chaque mécanisme « include », « a » ou « mx » compte. Au-delà, SPF renvoie une erreur (permerror).
• Choisissez la fin de l’enregistrement. « ~all » (softfail) signale les serveurs non listés comme suspects, « -all » (fail) demande de les refuser. Le « ~all » est souvent conseillé tant que DMARC gère la politique.

Pour activer DKIM, chaque plateforme d’envoi génère sa propre paire de clés et vous fournit la clé publique à publier. Vous créez alors un nouvel enregistrement TXT associé à un nom de la forme selecteur._domainkey.example.com. Exemple de valeur publiée sur mailjet._domainkey.example.com :

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

Contrairement à SPF, un domaine peut comprendre plusieurs enregistrements DKIM sans que cela pose problème : chaque outil dispose de son sélecteur. Privilégiez des clés de 2048 bits et pensez à les renouveler régulièrement. Une fois l’enregistrement DKIM publié, retournez dans l’outil d’envoi pour lancer la vérification et activer la signature.

Avant d’activer DMARC, assurez-vous que SPF et DKIM sont correctement en place pour tous vos flux. L’enregistrement DMARC se publie sur le sous-domaine _dmarc. Exemple de valeur publiée sur _dmarc.example.com :

"v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Les principales balises :

• p : la politique appliquée au domaine. « none » (aucune action, surveillance seule), « quarantine » (placement en spam) ou « reject » (rejet du message).
• rua : l’adresse qui reçoit les rapports agrégés, au format XML, envoyés en général chaque jour par les fournisseurs.
• ruf : l’adresse des rapports d’incidents détaillés, peu envoyés aujourd’hui pour des raisons de confidentialité.
• pct : le pourcentage de messages soumis à la politique, utile pour une montée en charge progressive.
• sp : la politique appliquée aux sous-domaines.
• adkim et aspf : le mode d’alignement, relâché (r) ou strict (s).

La bonne pratique consiste à démarrer en « p=none », à analyser les rapports pendant quelques semaines pour identifier toutes les sources légitimes, puis à passer en « quarantine », d’abord avec un pourcentage réduit, avant d’atteindre « reject ». Passer directement en rejet sans cette phase d’observation risque de bloquer vos propres messages.

Pour définir Mailjet comme expéditeur légitime, ajoutez vos domaines et sous-domaines d’envoi dans votre compte, puis configurez l’authentification SPF et DKIM pour chacun d’eux. Le paramétrage suppose d’être propriétaire du nom de domaine, ce qui exclut les adresses de webmails grand public comme gmail.com ou hotmail.fr.

Mailjet vous fournit les valeurs à intégrer dans votre zone DNS : l’include SPF à ajouter à votre enregistrement existant et la clé publique DKIM à publier chez votre hébergeur. Une fois les enregistrements en place, la vérification se fait depuis votre compte. Vous trouverez la démarche étape par étape dans notre documentation d’aide, avec des guides pour les principaux hébergeurs. Pour la mise en place de DMARC et le passage à une politique plus stricte, l’équipe support peut vous accompagner.

Une configuration n’est terminée qu’une fois vérifiée. Une faute de frappe dans un enregistrement ou un outil oublié suffit à faire échouer l’authentification. Voici trois manières de vous en assurer.

Envoyez-vous un message depuis chaque outil qui utilise votre domaine, puis affichez son code source. Dans Gmail, ouvrez le message, cliquez sur les trois points puis sur « Afficher l’original » : Gmail indique directement le résultat SPF, DKIM et DMARC. Cette vérification dans Gmail est la plus simple pour déterminer si un envoi est bien authentifié. Dans les autres clients de messagerie, recherchez l’en-tête « Authentication-Results ». Vous devez y voir spf=pass, dkim=pass et dmarc=pass, avec votre domaine.

Pour contrôler vos enregistrements sans attendre un envoi, vous pouvez utiliser un outil de vérification DNS. Des services en ligne comme MXToolbox ou dmarcian permettent de faire un check de vos enregistrements SPF, DKIM et DMARC en saisissant votre domaine : ils signalent les erreurs de syntaxe, le dépassement des 10 requêtes SPF ou l’absence d’un sélecteur DKIM. Mail-tester analyse de son côté un message réel et attribue une note. Les utilisateurs plus techniques peuvent interroger le DNS en ligne de commande, avec dig ou nslookup. Pensez que la propagation d’une modification DNS peut prendre de quelques minutes à 48 heures.

Les rapports agrégés reçus sur l’adresse « rua » sont le meilleur moyen de voir ce qui se passe réellement sur votre domaine : volume de messages, adresses IP d’envoi, résultats SPF et DKIM, alignement. Leur format XML est difficile à lire tel quel ; un outil d’analyse DMARC les transforme en tableaux exploitables. Ces informations vous permettent de repérer les sources légitimes mal configurées à corriger, et les sources inconnues qui tentent d’utiliser votre domaine. Surveillez également l’évolution du taux de messages authentifiés : c’est le meilleur indicateur de progression avant de durcir votre politique.

Même bien configurés, ces protocoles ont des limites qu’il faut connaître :

• Le transfert casse SPF. Quand un message est transféré automatiquement, il repart d’un serveur qui ne figure pas dans votre enregistrement. DKIM, qui voyage avec le message, prend alors le relais pour valider DMARC, d’où l’importance d’avoir les deux.
• Les listes de diffusion peuvent casser DKIM en modifiant le sujet ou en ajoutant un pied de page. Le protocole ARC aide les intermédiaires à conserver les résultats d’authentification d’origine.
• L’authentification ne remplace pas les bonnes pratiques. Un domaine parfaitement authentifié qui envoie à des contacts non consentis ou avec un contenu douteux finira quand même en spam. Veillez à respecter les bonnes pratiques d’envoi.
• Les erreurs les plus courantes : deux enregistrements SPF sur un même domaine, un « include » manquant pour un nouvel outil, une clé DKIM mal copiée (espaces ou guillemets en trop), un passage en « reject » sans phase d’observation, des sous-domaines oubliés.

Il n’existe pas d’obligation légale générale, mais les grands fournisseurs de messagerie l’exigent pour les expéditeurs de gros volumes, au minimum avec une politique « p=none ». Pour toute entreprise qui envoie des campagnes ou des messages transactionnels, c’est aujourd’hui une norme de fait.

La création des enregistrements prend quelques minutes par outil. Comptez ensuite le délai de propagation DNS, puis plusieurs semaines d’observation des rapports DMARC avant de passer à une politique stricte.

Le serveur destinataire applique la politique publiée : il laisse passer le message en « none », le place dans le dossier spam en « quarantine » ou le refuse en « reject ». L’échec est ensuite indiqué dans les rapports envoyés au propriétaire du domaine.

SPF identifie les serveurs autorisés, DKIM signe et protège le contenu, DMARC vérifie la cohérence avec l’adresse visible et définit la réponse à apporter aux messages frauduleux. Mis en place ensemble et vérifiés régulièrement, ils protègent votre marque, rassurent les fournisseurs de messagerie et posent les bases d’un routage fiable.

Avec Mailjet, l’authentification de vos domaines se configure depuis votre compte, avec une documentation détaillée pour chaque hébergeur et l’accompagnement de nos experts en délivrabilité. Vous gardez ainsi la main sur la sécurité de vos envois marketing comme transactionnels.