Authentifiez votre domaine avec SPF et DKIM

Un email soigneusement rédigé peut ne jamais atteindre sa destination si votre domaine n’est pas authentifié. Un enregistrement SPF incomplet, une signature DKIM mal publiée ou l’absence de DMARC suffisent à fragiliser votre délivrabilité et à exposer votre marque à l’usurpation. Configurer SPF et DKIM répond précisément à cet enjeu : prouver aux fournisseurs de messagerie que vous êtes bien à l’origine des messages envoyés depuis votre domaine.

Pour Gmail, Yahoo ou Microsoft, votre nom d’expéditeur ne suffit pas. Chaque serveur de réception cherche à vérifier que l’envoi est légitime avant de décider du placement de l’email. L’authentification lui fournit les informations techniques nécessaires : SPF déclare les serveurs autorisés à envoyer en votre nom, DKIM signe cryptographiquement vos messages, et DMARC ajoute une politique de contrôle et de reporting.

Bien configurés, ces protocoles renforcent la sécurité de votre messagerie, protègent votre identité de marque et limitent les risques de phishing et de courrier indésirable. Ce guide vous accompagne pas à pas : comprendre le rôle de chaque protocole, identifier les enregistrements DNS requis, les configurer dans votre zone DNS, déployer DMARC, puis vérifier votre configuration avant vos prochains envois.

SPF et DKIM : 2 protocoles complémentaires pour authentifier votre domaine

SPF et DKIM poursuivent le même objectif, renforcer l’authentification des emails envoyés depuis votre domaine, mais ils agissent de façon différente et complémentaire. SPF vérifie si le serveur à l’origine de l’envoi est autorisé. DKIM associe au message une signature cryptographique dont l’authenticité peut être contrôlée par le serveur de messagerie du destinataire. Ensemble, ils donnent aux fournisseurs deux preuves distinctes de la légitimité de votre expéditeur.

Lorsqu’un email arrive chez Gmail, Yahoo ou Microsoft, plusieurs contrôles sont effectués avant sa réception. Les informations publiées dans votre DNS et celles contenues dans le message permettent au système de vérifier si l’envoi correspond à la configuration définie par le propriétaire du domaine.

Qu’est-ce qu’un SPF ?

SPF, pour Sender Policy Framework, permet au propriétaire d’un domaine de déclarer quels serveurs et services sont autorisés à envoyer du courrier en son nom. Cette information est publiée dans la zone DNS sous la forme d’un enregistrement TXT. À la réception d’un email, le serveur consulte cet enregistrement SPF et compare l’infrastructure d’envoi aux sources autorisées pour ce domaine.

Cette configuration devient essentielle dès qu’une entreprise combine plusieurs services en parallèle : Microsoft 365 ou Exchange pour la messagerie des collaborateurs, une plateforme email pour les campagnes marketing, une application ou une API pour les emails transactionnels. Chaque source légitime doit alors figurer dans la politique SPF. Si le serveur qui envoie est correctement autorisé, le contrôle est validé ; dans le cas contraire, le résultat signale un problème d’authentification.

SPF apporte ainsi un premier niveau de protection contre l’utilisation non autorisée d’un domaine, mais il fonctionne encore mieux associé à DKIM et DMARC. Pour approfondir son fonctionnement, consultez notre article consacré à la manière de gérer le protocole SPF.

Définition d’un DKIM : une clé cryptée pour protéger votre serveur

DKIM, pour DomainKeys Identified Mail, repose sur un couple de clés : une clé privée et une clé publique. Au moment de l’envoi, la plateforme ajoute une signature DKIM au message grâce à la clé privée qu’elle conserve. La clé publique correspondante est publiée dans votre zone DNS, ce qui permet au serveur de réception de vérifier que la signature est valide et que certaines parties protégées du contenu n’ont pas été altérées.

Chaque configuration DKIM s’appuie sur un sélecteur, qui indique au serveur quelle clé publique utiliser pour la vérification. Un nom peut prendre une forme telle que selector1._domainkey.exemple.com, même si la valeur exacte dépend toujours de la plateforme. Selon votre fournisseur, la clé se publie via un enregistrement TXT ou un enregistrement CNAME. Reprenez toujours exactement le nom, le sélecteur et la valeur indiqués dans votre compte, plutôt qu’une configuration générique trouvée sur le web.

Pourquoi est-ce important d’authentifier son domaine en email marketing ?

Authentifier son domaine ne relève pas seulement d’une exigence technique. L’authentification fournit aux fournisseurs de messagerie des informations vérifiables sur l’identité de l’expéditeur et contribue à protéger votre domaine contre certaines formes d’usurpation. Pour une marque, l’enjeu est aussi une question de confiance : un client doit pouvoir relier un email à un expéditeur légitime, sans qu’un tiers puisse facilement se faire passer pour vous, comme dans une tentative d’hameçonnage.

Cette protection compte particulièrement lorsque plusieurs applications, équipes ou prestataires disposent d’un accès à vos outils d’envoi : une bonne gestion des services autorisés maintient une configuration cohérente dans le temps. Il reste toutefois important de distinguer authentification et délivrabilité. Même correctement authentifié, un email peut être placé dans les spams si la réputation d’expéditeur, la qualité de la liste de contacts ou les pratiques d’envoi envoient de mauvais signaux.

Les enregistrements DNS requis pour SPF, DKIM et DMARC

SPF, DKIM et DMARC reposent tous sur le DNS, mais chacun joue un rôle distinct et se configure différemment. Avant de modifier votre zone DNS, il est donc essentiel de savoir précisément quel enregistrement créer pour chaque protocole. Le tableau ci-dessous résume les trois enregistrements à publier.

Protocole	Type d’enregistrement	Rôle	Exemple
SPF	TXT	Déclare les serveurs autorisés à envoyer pour le domaine	v=spf1 include:spf.mailjet.com ~all
DKIM	TXT ou CNAME	Publie la clé publique qui vérifie la signature du message	selector1._domainkey (valeur fournie par la plateforme)
DMARC	TXT	Définit la politique de traitement et le reporting, sur _dmarc.votredomaine.com	v=DMARC1; p=none; rua=mailto:dmarc@exemple.com;

L’enregistrement SPF : une politique TXT unique

Un enregistrement SPF commence généralement par v=spf1, suivi des différents mécanismes qui identifient les services autorisés. Avant d’en créer un, vérifiez toujours si une politique SPF existe déjà. Un domaine qui utilise Microsoft 365, un service SMTP et plusieurs plateformes marketing doit rassembler l’ensemble de ces sources dans un même enregistrement : on enrichit l’existant plutôt que de créer plusieurs SPF indépendants pour le même domaine, ce qui invaliderait la configuration. Notez enfin que l’hébergement de votre site et la gestion de votre DNS peuvent dépendre de deux prestataires distincts. C’est la zone DNS active qu’il faut modifier.

Trois pièges reviennent souvent sur SPF. Un domaine ne doit publier qu’un seul enregistrement SPF : deux enregistrements v=spf1 en parallèle rendent la vérification invalide, d’où l’importance d’enrichir l’existant. La politique tolère par ailleurs un nombre limité de résolutions DNS, ce qui incite à ne déclarer que les services réellement utilisés plutôt que d’accumuler les include. Le mécanisme final, enfin, oriente le traitement des sources non listées : ~all signale un envoi suspect sans le rejeter, tandis que -all demande un rejet plus strict. Commencez par ~all le temps de valider votre configuration, puis renforcez si besoin.

L’enregistrement DKIM : une clé publique sélectrice de réceptions

L’enregistrement DKIM donne aux serveurs de réception l’accès à la clé publique nécessaire pour vérifier la signature du message. Son nom contient un sélecteur associé à _domainkey, et l’information se publie sous forme de TXT ou de CNAME selon le fournisseur. Si votre plateforme demande par exemple un CNAME sur selector1._domainkey, saisissez exactement le nom et la valeur indiqués : une erreur de sélecteur, un caractère manquant ou un domaine ajouté deux fois par votre interface DNS suffit à empêcher la vérification. La clé privée, elle, reste stockée du côté de la plateforme qui signe les messages et ne doit jamais être publiée.

Le sélecteur mérite une attention particulière lorsque plusieurs services signent vos emails. Chaque plateforme utilise son propre sélecteur et publie sa propre clé publique, ce qui permet de faire coexister sans conflit une signature pour vos campagnes marketing et une autre pour vos emails transactionnels. Certaines plateformes proposent aussi de renouveler périodiquement la clé DKIM : pensez alors à publier la nouvelle valeur avant de retirer l’ancienne, afin de ne pas interrompre la vérification des messages déjà en circulation.

L’enregistrement DMARC : politique et rapports

DMARC se publie sous forme d’enregistrement TXT, généralement sur _dmarc.votredomaine.com. Il complète SPF et DKIM en définissant la politique applicable aux emails qui ne répondent pas aux contrôles attendus, et il ajoute une fonction de reporting précieuse. Les rapports agrégés révèlent quels services utilisent votre domaine et le résultat de leur authentification, ce qui aide à repérer une source oubliée, une mauvaise configuration ou un envoi non identifié auparavant.

Guide de configuration SPF et DKIM dans votre DNS : les conseils Mailjet

La configuration de SPF et DKIM se joue à deux endroits : votre plateforme d’envoi, qui fournit les paramètres nécessaires, et votre gestionnaire DNS, dans lequel vous créez ou modifiez les enregistrements. La méthode reste similaire quel que soit le fournisseur, même si le nom des champs ou l’organisation de l’interface peuvent varier.

Étape 1 : accéder à la zone DNS de votre domaine

Commencez par identifier le fournisseur qui administre réellement les DNS de votre domaine. Si votre zone est gérée chez OVHcloud, connectez-vous à votre espace client et ouvrez le domaine concerné ; le principe reste identique chez un autre hébergeur. Avant toute modification, prenez le temps de consulter les enregistrements déjà présents : une même zone peut servir votre site web, votre plateforme email, Microsoft 365 ou d’autres applications de l’entreprise, et supprimer la mauvaise ligne perturberait un service en fonctionnement. Si vous ne disposez pas des droits nécessaires, contactez l’administrateur ou la personne chargée de la gestion technique du domaine.

Gardez aussi en tête la notion de propagation. Chaque enregistrement DNS possède une durée de vie, le TTL, qui détermine le temps que mettront les serveurs à prendre en compte vos modifications. Après une mise à jour, il est donc normal qu’un contrôle échoue quelques minutes, voire quelques heures, avant que la nouvelle valeur ne soit visible partout. Modifier un enregistrement pour ensuite l’ajuster plusieurs fois de suite ne fait qu’allonger ce délai.

Étape 2 : créer ou modifier votre enregistrement SPF

Recherchez d’abord un enregistrement TXT commençant par v=spf1. S’il existe déjà, ne créez pas automatiquement une seconde politique : intégrez le nouveau service d’envoi à la configuration existante. Avec Mailjet, SPF utilise notamment le mécanisme include:spf.mailjet.com. Un enregistrement simple prend alors la forme suivante :

v=spf1 include:spf.mailjet.com ~all

Si votre domaine utilise déjà un autre service, la politique doit être enrichie afin de conserver toutes les sources légitimes :

v=spf1 include:spf.example.com include:spf.mailjet.com ~all

La valeur exacte dépend toujours de votre infrastructure : vérifiez quels services envoient réellement des messages avant de modifier SPF. Une fois la nouvelle valeur enregistrée, laissez au DNS le temps de se propager avant de conclure que la configuration ne fonctionne pas.

Étape 3 : publier votre enregistrement DKIM

Récupérez d’abord les informations fournies par votre plateforme email : sélecteur, nom d’hôte, type d’enregistrement et valeur de la clé publique. Créez ensuite le TXT ou le CNAME demandé dans votre zone DNS. Soignez particulièrement le format du nom : certaines interfaces attendent uniquement selector1._domainkey et ajoutent votre domaine automatiquement, d’autres réclament le nom complet. Reprenez la valeur exactement, car une clé DKIM est longue et une simple erreur de copie provoque l’échec de l’authentification. Une fois l’enregistrement ajouté, retournez dans la plateforme pour vérifier son état et, si votre solution le demande, activer la signature.

Étape 4 : vérifier la configuration dans Mailjet

Avec Mailjet, les paramètres nécessaires sont accessibles directement depuis votre compte. Sélectionnez le domaine ou sous-domaine utilisé pour vos envois, récupérez les valeurs SPF et DKIM fournies, ajoutez-les dans votre zone DNS, puis revenez dans Mailjet pour contrôler leur état. La plateforme vérifie alors si les informations sont publiquement accessibles et si le domaine a été correctement configuré. Si les nouvelles valeurs ne sont pas détectées immédiatement, évitez de les modifier plusieurs fois de suite : la propagation DNS demande parfois du temps. Vous retrouverez le détail des étapes dans notre documentation, ainsi que dans notre article expliquant comment configurer SPF, DKIM et DMARC.

Déployez DMARC pour compléter SPF et DKIM

Une fois SPF et DKIM configurés, DMARC vous permet de mieux contrôler l’utilisation de votre domaine et de définir la manière dont les échecs d’authentification doivent être traités. Concrètement, DMARC vérifie l’alignement entre le domaine affiché dans le champ expéditeur et les domaines validés par SPF et DKIM, puis applique la politique que vous avez publiée. Le protocole ne se résume donc pas à une ligne ajoutée dans votre DNS : une politique trop stricte, appliquée trop tôt, peut affecter un service parfaitement légitime qui n’a pas encore été correctement identifié.

Créez votre enregistrement DMARC

Pour un domaine comme exemple.com, l’enregistrement DMARC se crée généralement sous _dmarc.exemple.com. Une première configuration peut prendre une forme proche de :

v=DMARC1; p=none; rua=mailto:dmarc@exemple.com;

Le paramètre p=none permet de commencer par observer les résultats sans demander d’action restrictive sur les messages concernés. L’adresse indiquée dans rua sert à recevoir les rapports agrégés : ces données recensent les principales sources qui utilisent votre domaine et signalent les erreurs d’authentification. Ce reporting est votre meilleur allié, car il cartographie vos flux d’envoi réels avant tout durcissement de la politique. Il révèle souvent un service oublié, un prestataire non déclaré dans SPF ou une clé DKIM absente, autant de points à corriger avant de renforcer la configuration.

Quelques paramètres complémentaires affinent votre enregistrement. Le paramètre pct applique la politique à un pourcentage seulement des messages, ce qui autorise un déploiement graduel sur une fraction de votre trafic. Le paramètre sp définit une politique spécifique pour vos sous-domaines, utile si certains d’entre eux servent à des envois distincts. Vous pouvez ajouter une adresse pour recevoir des rapports d’échec plus détaillés, en gardant à l’esprit que ces rapports peuvent contenir des informations sensibles. Restez simple au départ : une politique none accompagnée d’une adresse rua suffit à obtenir une vision claire de vos flux.

Choisissez votre politique : none, quarantine ou reject

DMARC propose principalement trois politiques, à adopter de façon progressive. La politique none observe et collecte des informations sur les envois, sans agir sur les messages. La politique quarantine indique aux fournisseurs de traiter avec davantage de prudence les messages non conformes, qui peuvent notamment être dirigés vers le courrier indésirable. La politique reject demande enfin le rejet des messages qui échouent à la politique.

La bonne méthode consiste à avancer par étapes. Commencez par none et analysez les rapports jusqu’à confirmer que toutes vos plateformes légitimes sont correctement authentifiées. Passez ensuite à quarantine pour un premier niveau de restriction, puis à reject une fois la configuration stabilisée. Cette progression protège votre domaine contre l’usurpation tout en évitant de bloquer involontairement des messages provenant d’un service autorisé. Prenez le temps nécessaire à chaque palier : un déploiement patient vaut toujours mieux qu’une politique reject activée avant d’avoir vérifié l’ensemble de vos sources d’envoi.

Vérifiez votre configuration SPF et DKIM

Publier les bons enregistrements ne suffit pas. Une erreur de syntaxe, un mauvais sélecteur ou un problème de propagation peut empêcher SPF ou DKIM de fonctionner comme prévu. Une étape de vérification permet donc de confirmer que vos informations sont accessibles et que les messages envoyés obtiennent bien les résultats attendus, avant de lancer vos prochaines campagnes.

Testez vos enregistrements avec les bons outils

La première vérification se réalise directement depuis votre plateforme email : Mailjet, par exemple, affiche l’état d’authentification du domaine depuis votre compte. Des outils externes complètent utilement ce contrôle. MxToolbox interroge vos enregistrements DNS et signale les anomalies. Mail-Tester analyse un email de test envoyé vers une adresse dédiée et détaille les résultats SPF, DKIM et DMARC. Interprétez ces résultats avec prudence : un test réussi confirme que certains éléments techniques sont correctement configurés à un instant donné, mais il ne peut pas assurer que tous vos futurs emails atteindront la boîte de réception. Tenez également compte de la propagation DNS, car une modification récente peut ne pas être encore visible depuis tous les réseaux.

Interprétez les résultats d’authentification

Lors de vos tests, examinez séparément les résultats SPF, DKIM et DMARC. Un résultat SPF positif indique que le serveur ayant transmis le message correspond à une source autorisée par la politique publiée. Un résultat DKIM positif signifie que la signature a pu être vérifiée avec la clé publique associée. Un résultat DMARC positif confirme l’alignement entre le domaine affiché et les domaines validés par SPF ou DKIM.

Si l’un des contrôles échoue, évitez de modifier plusieurs paramètres à la fois. Identifiez d’abord précisément le protocole concerné. Pour SPF, contrôlez la liste des services autorisés et l’absence de conflit entre plusieurs politiques. Pour DKIM, vérifiez le sélecteur, le type d’enregistrement et la valeur de la clé. Pour DMARC, observez l’alignement des domaines et la politique utilisée. Cette approche ciblée facilite le diagnostic et évite de créer un nouveau problème en tentant de corriger une erreur située ailleurs.

Pour un diagnostic plus fin, vous pouvez consulter directement les en-têtes d’un email reçu. La ligne Authentication-Results résume les verdicts obtenus, avec des mentions telles que pass, fail ou softfail pour chaque protocole. Un softfail SPF, par exemple, indique un envoi toléré mais non pleinement autorisé, souvent le signe d’une source à ajouter dans votre politique. Croiser ces en-têtes avec les rapports agrégés remontés par DMARC vous donne une image complète des services qui envoient réellement au nom de votre domaine.

Renforcez votre délivrabilité au-delà de l’authentification

SPF, DKIM et DMARC renforcent l’authentification, mais ils ne peuvent pas assurer à eux seuls que vos messages atteignent leur destination. Gmail, Yahoo et Microsoft s’appuient sur de nombreux autres signaux pour évaluer les emails reçus : la réputation d’expéditeur, les plaintes pour spam, la qualité des contacts ou encore la régularité des envois influencent tous la réception.

Les bonnes pratiques d’envoi à adopter

La qualité de votre base de contacts est le premier élément à surveiller. Envoyer régulièrement des campagnes à des adresses invalides, inactives ou obtenues sans consentement dégrade progressivement votre réputation. L’engagement des utilisateurs apporte lui aussi des informations aux fournisseurs de messagerie : des destinataires qui ouvrent et interagissent avec vos messages n’envoient pas les mêmes signaux que ceux qui ignorent vos campagnes ou les signalent comme spam.

Votre fréquence d’envoi doit rester cohérente, car une augmentation brutale du volume ou l’usage soudain d’une nouvelle infrastructure modifie la manière dont votre trafic est perçu. Le contenu, enfin, doit répondre aux attentes de vos destinataires : identité d’expéditeur claire, lien de désabonnement visible, raison d’être du message compréhensible. D’autres standards comme BIMI peuvent compléter votre dispositif autour de l’identité de marque, sans jamais remplacer SPF, DKIM ou DMARC.

Surveiller votre réputation dans le temps fait partie des bons réflexes. Des outils comme Google Postmaster Tools donnent de la visibilité sur la façon dont un fournisseur perçoit vos envois, et les rapports DMARC continuent d’alerter sur toute source inattendue. Si vous lancez une nouvelle adresse d’envoi ou augmentez fortement vos volumes, une montée en charge progressive aide les fournisseurs à établir votre réputation sur des bases saines plutôt que de recevoir un pic soudain de trafic inconnu. Cette régularité, combinée à une liste de contacts propre et à des messages attendus, pèse souvent davantage sur le placement que la seule configuration technique.

FAQ 

Comment vérifier que SPF et DKIM sont bien configurés ?

Consultez d’abord l’état d’authentification affiché dans votre plateforme d’envoi. Vous pouvez ensuite utiliser un outil de vérification DNS comme MxToolbox, ou envoyer un email de test à Mail-Tester pour analyser les résultats SPF et DKIM présents dans les en-têtes. Si vous venez de modifier votre zone DNS, attendez la fin de la propagation avant de conclure à un échec.

Que faire si la configuration SPF ou DKIM échoue ?

Vérifiez d’abord le nom, le type et la valeur des enregistrements publiés. Pour SPF, assurez-vous que l’infrastructure réellement utilisée pour l’envoi est autorisée et qu’aucun conflit n’oppose deux politiques. Pour DKIM, contrôlez surtout le sélecteur et la clé publique : une erreur de saisie ou un domaine ajouté deux fois dans le nom suffit à empêcher la validation.

Faut-il configurer DMARC en plus de SPF et DKIM ?

DMARC complète SPF et DKIM en ajoutant une politique et un système de reporting. Il vous aide à comprendre quelles sources utilisent votre domaine et à indiquer aux serveurs destinataires la manière de traiter les échecs. Commencez par une politique p=none pour observer vos flux d’envoi, puis renforcez progressivement vers quarantine puis reject.

Peut-on configurer SPF et DKIM sur une adresse Gmail ou Yahoo gratuite ?

Non. Publier vos propres enregistrements SPF et DKIM exige un accès à la zone DNS du domaine, ce qui est impossible avec une adresse gratuite en gmail.com ou yahoo.com. En revanche, une entreprise qui utilise Gmail via Google Workspace ou Microsoft 365 avec son propre domaine personnalisé peut tout à fait configurer SPF et DKIM sur ce domaine.

Un domaine authentifié pour une délivrabilité durable

Configurer SPF et DKIM, puis déployer DMARC, donne aux serveurs de messagerie les informations dont ils ont besoin pour vérifier l’origine et l’authenticité de vos emails. Ces protocoles constituent une base solide pour protéger votre identité de marque, limiter certaines formes d’usurpation et bâtir une infrastructure d’envoi plus fiable. Ils ne garantissent pas à eux seuls l’arrivée en boîte de réception : votre réputation d’expéditeur, la qualité de vos contacts et vos pratiques d’envoi restent déterminantes.