En bref : SPF, DKIM et DMARC sont les trois protocoles qui prouvent aux serveurs de réception que vos emails sont légitimes. Depuis 2024, Google, Yahoo et Microsoft les exigent. Sans eux, vos campagnes emailing risquent tout simplement de ne pas arriver. Ce guide vous accompagne dans leur configuration, étape par étape.
L’authentification email n’est plus optionnelle
Pendant longtemps, configurer SPF, DKIM et DMARC relevait de la bonne pratique. Un « plus » que les entreprises les plus rigoureuses mettaient en place, sans urgence particulière. Ce n’est plus le cas.
Depuis février 2024, Google et Yahoo exigent que tout expéditeur envoyant plus de 5 000 emails par jour ait configuré ces trois protocoles. Microsoft a suivi en mai 2025 avec des exigences similaires. En clair : si votre domaine n’est pas correctement authentifié, vos messages n’arrivent plus en boîte de réception. Ils sont filtrés, mis en spam, ou purement rejetés.
Le contexte explique cette accélération. D’après le rapport 2024 de Cybermalveillance.gouv.fr, 60% des cyberattaques en France commencent par un email frauduleux. Le phishing reste la menace numéro un, et les chiffres continuent de grimper : selon Factoria Groupe, 43% des TPE-PME françaises ont été victimes d’hameçonnage en 2025, contre 24% un an plus tôt. Presque le double.
Face à cette réalité, les fournisseurs de messagerie ont musclé leurs règles. Gmail a réduit de 65% le volume de messages non authentifiés depuis l’entrée en vigueur de ces exigences, d’après PowerDMARC. Le signal est sans ambiguïté : l’authentification n’est plus un sujet technique qu’on remet à plus tard. C’est la condition de base pour que vos campagnes emailing atteignent leurs destinataires.
SPF : déclarer qui a le droit d’envoyer vos emails
SPF, pour Sender Policy Framework, est le premier des trois protocoles à configurer. Son principe est simple : vous publiez dans les DNS de votre domaine la liste des serveurs autorisés à envoyer des emails en votre nom.
Quand un serveur de réception reçoit un email de votre domaine, il consulte votre enregistrement SPF pour vérifier que le serveur expéditeur figure bien sur la liste. Si c’est le cas, le message passe le contrôle. Sinon, il est signalé comme suspect.
En pratique, l’enregistrement SPF est une ligne de texte ajoutée dans la zone DNS de votre domaine, sous forme d’enregistrement TXT :
v=spf1 include:spf.ediware.net include:_spf.google.com ip4:192.168.1.1 ~all
Chaque élément a un rôle précis :
v=spf1indique qu’il s’agit d’un enregistrement SPFinclude:autorise les serveurs d’un service tiers, votre plateforme emailing ou votre messagerie d’entrepriseip4:autorise une adresse IP spécifique~allindique que tout serveur non listé doit être traité avec méfiance (soft fail)
Deux points méritent une attention particulière. D’abord, la limite des 10 lookups DNS. Chaque include génère une requête DNS, et certains include en appellent d’autres en cascade. Un enregistrement qui semble contenir quatre entrées peut en réalité générer douze lookups. Au-delà de dix, l’enregistrement SPF entier est invalidé. Pas partiellement. Totalement.
Ensuite, la différence entre ~all (soft fail) et -all (hard fail). Le soft fail est recommandé pendant la phase de déploiement, car il laisse passer les messages tout en les signalant. Le hard fail est plus strict mais risque de bloquer des emails légitimes si la configuration n’est pas parfaitement complète.
D’après l’Afnic, 74,4% des domaines de la zone .fr publient une politique SPF en 2025, contre 57,8% en 2023. La progression est nette. Mais cela signifie aussi qu’un quart des domaines français n’ont toujours pas fait cette configuration de base.
DKIM : prouver que vos messages n’ont pas été altérés
Si SPF vérifie qui envoie le message, DKIM vérifie que le message lui-même n’a pas été modifié en chemin. DKIM, pour DomainKeys Identified Mail, repose sur un principe de signature cryptographique.
Votre serveur d’envoi appose une signature numérique sur chaque email sortant. Cette signature est générée à partir d’une clé privée que seul votre serveur connaît. La clé publique correspondante est publiée dans vos DNS. Quand le serveur du destinataire reçoit le message, il récupère la clé publique, vérifie la signature, et s’assure que rien n’a été modifié entre l’envoi et la réception.
L’enregistrement DKIM dans vos DNS prend cette forme :
selecteur._domainkey.votredomaine.com → enregistrement TXT contenant la clé publique
Le « sélecteur » est un identifiant qui permet d’avoir plusieurs clés DKIM pour un même domaine. Chaque service d’envoi utilise généralement son propre sélecteur : votre plateforme emailing en a un, votre messagerie Google Workspace en a un autre.
Sur la taille des clés, Google recommande 2048 bits. Les clés de 1024 bits fonctionnent encore, mais elles sont considérées comme insuffisantes. Si votre configuration DKIM date de quelques années, il y a de bonnes chances que les clés soient trop courtes. Vérifiez et mettez à jour si nécessaire.
Un point souvent négligé : la rotation des clés DKIM. Comme pour un mot de passe, renouveler ses clés périodiquement est une bonne pratique. Tous les six mois à un an, c’est une fréquence raisonnable. Votre plateforme emailing gère généralement cette rotation de manière transparente, mais mieux vaut s’en assurer.
DMARC : décider du sort des emails non conformes
DMARC, pour Domain-based Message Authentication, Reporting and Conformance, est le troisième maillon de la chaîne. Son rôle : indiquer aux serveurs de réception ce qu’ils doivent faire quand un email échoue aux vérifications SPF et DKIM.
Sans DMARC, chaque fournisseur de messagerie applique ses propres règles, de manière opaque. Avec DMARC, c’est vous qui définissez la politique à suivre. Trois options :
- p=none : ne rien faire de particulier, mais recevoir les rapports. C’est le mode d’observation.
- p=quarantine : envoyer les messages suspects en spam.
- p=reject : rejeter purement et simplement les messages non conformes.
L’enregistrement DMARC se publie dans vos DNS, comme SPF :
_dmarc.votredomaine.com → v=DMARC1; p=none; rua=mailto:dmarc-rapports@votredomaine.com
Le paramètre rua indique l’adresse où recevoir les rapports agrégés. Ces rapports, envoyés au format XML par les fournisseurs de messagerie, vous montrent qui envoie des emails avec votre domaine, combien passent l’authentification, combien échouent. Une mine d’informations pour repérer les problèmes de configuration ou les tentatives d’usurpation.
Un point technique souvent mal compris : l’alignement. DMARC vérifie que le domaine visible dans le champ « From » de l’email correspond au domaine authentifié par SPF ou DKIM. Si votre email affiche « contact@votreentreprise.com » mais que le SPF authentifie un domaine différent, DMARC considère l’email comme non conforme, même si SPF passe techniquement.
Il existe aussi un second type de rapport, les rapports forensiques (paramètre ruf), qui fournissent des détails sur chaque email individuel ayant échoué. Ces rapports sont plus précis mais aussi plus sensibles en termes de données personnelles, raison pour laquelle tous les fournisseurs ne les envoient pas.
Malgré l’efficacité prouvée du protocole, l’adoption reste faible à l’échelle mondiale. Selon le rapport EasyDMARC 2025, seuls 5,2% des domaines utilisent la politique p=reject. La grande majorité en reste à p=none, ce qui revient à observer sans vraiment agir. Dans le secteur du retail français, dmarcian constate que seulement 32% des 100 principaux domaines ont une politique DMARC au niveau de l’application. Les 68% restants sont exposés.
Mettre en place SPF, DKIM et DMARC pas à pas
La configuration suit un ordre logique. Brûler les étapes expose à des blocages qu’on aurait pu éviter.
Étape 1 : inventorier tous vos flux d’envoi. Avant de toucher aux DNS, listez l’ensemble des services qui envoient des emails pour votre domaine. Votre plateforme emailing, votre messagerie d’entreprise (Google Workspace, Microsoft 365), votre CRM, votre outil de facturation, votre site web avec ses formulaires de contact et ses notifications. Chaque service oublié sera potentiellement bloqué une fois l’authentification active.
Étape 2 : configurer SPF. Créez un enregistrement TXT dans votre zone DNS qui autorise tous les services identifiés. Vérifiez que vous ne dépassez pas les 10 lookups DNS. Si c’est le cas, regroupez certaines entrées ou utilisez une technique appelée « SPF flattening » qui remplace les include par les adresses IP correspondantes.
Étape 3 : activer DKIM. Pour chaque service d’envoi, générez une paire de clés DKIM depuis son interface d’administration. Publiez la clé publique dans vos DNS. Activez la signature dans les paramètres du service. Vérifiez que la clé fait bien 2048 bits.
Étape 4 : publier DMARC en mode observation. Commencez avec p=none. C’est la recommandation de Google et de la M3AAWG, l’organisation de référence en matière de lutte contre les abus par email. À ce stade, aucun message n’est bloqué. Vous collectez simplement les données.
Étape 5 : analyser les rapports. Patientez deux à quatre semaines pour accumuler suffisamment de données. Les rapports DMARC en XML sont illisibles à l’oeil nu. Des outils gratuits comme MXToolbox ou dmarcian les transforment en tableaux compréhensibles. Identifiez les services qui échouent et corrigez leur configuration.
Étape 6 : durcir progressivement la politique. Une fois que tous vos flux légitimes passent correctement, passez à p=quarantine. Surveillez encore quelques semaines. Si tout est stable, basculez vers p=reject. Cette montée en puissance est indispensable pour ne pas couper vos propres envois.
Google recommande d’attendre 48 heures entre la mise en place de SPF/DKIM et la publication du DMARC, le temps que les enregistrements DNS se propagent correctement.
Les erreurs de configuration qui passent inaperçues
Certaines erreurs sont fréquentes et peuvent rester invisibles pendant des mois. Le temps qu’un problème de délivrabilité remonte, des campagnes entières auront été dégradées sans que personne ne s’en aperçoive.
Dépasser les 10 lookups SPF. L’erreur la plus répandue. Chaque include déclenche une requête DNS, et certains en appellent d’autres en cascade. Un enregistrement qui semble contenir quatre include peut en réalité générer douze lookups. Au-delà de dix, l’enregistrement SPF entier devient invalide. Pas partiellement, totalement. Vérifiez avec un outil comme MXToolbox SPF Checker.
Oublier un service d’envoi. Votre comptabilité envoie des factures par email, votre support technique envoie des notifications, votre site WordPress envoie des confirmations de formulaire. Si ces services ne figurent pas dans votre SPF et ne signent pas en DKIM, leurs emails échoueront systématiquement. D’où l’importance de l’inventaire initial.
Utiliser des clés DKIM obsolètes. Les clés de 512 ou 1024 bits ne sont plus considérées comme sûres. Si votre DKIM a été mis en place il y a plusieurs années, les clés sont probablement trop courtes. La mise à jour prend quelques minutes mais elle change tout.
Passer trop vite à p=reject. La tentation est forte de vouloir verrouiller rapidement. Mais si un service d’envoi légitime n’est pas correctement authentifié, ses emails seront rejetés sans préavis. Et vous ne le saurez peut-être pas tout de suite. La progression none → quarantine → reject doit se faire sur plusieurs semaines, rapports à l’appui.
Ne pas activer les rapports DMARC. Publier un enregistrement DMARC sans le paramètre rua revient à naviguer sans instruments. Sans rapports, impossible de savoir ce qui passe, ce qui échoue, ou qui tente d’usurper votre domaine.
Ignorer le forwarding. Quand un email est transféré par un intermédiaire, le SPF casse. Le serveur qui transfère n’est pas dans votre liste d’expéditeurs autorisés. DKIM résiste mieux au forwarding car la signature reste intacte. C’est une raison supplémentaire de configurer les deux protocoles et de ne pas se reposer uniquement sur SPF.
Vérifier et surveiller votre authentification
Configurer SPF, DKIM et DMARC ne suffit pas. La vérification initiale et la surveillance continue font partie du processus.
Les outils de vérification immédiate. Plusieurs services en ligne testent votre configuration en quelques secondes. MXToolbox vérifie vos enregistrements SPF, DKIM et DMARC et signale les erreurs. Mail-Tester donne un score de délivrabilité après l’envoi d’un email test. Google Admin Toolbox permet de vérifier spécifiquement les enregistrements DNS. Pour aller plus loin, consultez notre guide complet sur l’authentification email SPF, DKIM et DMARC.
Google Postmaster Tools. Si vous envoyez des volumes significatifs vers des adresses Gmail, cet outil gratuit est indispensable. Il affiche votre taux de spam, votre réputation de domaine, le taux d’authentification SPF/DKIM/DMARC, et les erreurs de livraison. C’est le tableau de bord que Google met à la disposition des expéditeurs pour surveiller leur santé d’envoi.
La lecture des rapports DMARC. Les rapports agrégés arrivent au format XML dans la boîte email configurée. Ils contiennent le volume de messages envoyés depuis votre domaine, les résultats d’authentification pour chaque source d’envoi, et les actions prises par les serveurs destinataires. Des outils comme dmarcian ou MXToolbox DMARC Report Analyzer convertissent ces fichiers en tableaux compréhensibles.
Ce qu’il faut surveiller régulièrement :
- Le taux de spam signalé, que Google recommande de maintenir sous 0,10% avec un seuil critique à 0,3%
- Les sources d’envoi non identifiées dans vos rapports DMARC, qui peuvent signaler une tentative d’usurpation
- La validité de vos enregistrements DNS après toute modification de votre infrastructure
L’authentification email n’est pas un projet ponctuel qu’on coche et qu’on oublie. C’est un processus continu. À chaque ajout de service d’envoi, changement de prestataire ou modification DNS, une vérification s’impose.
L’authentification au service de votre délivrabilité B2B
SPF, DKIM et DMARC ne sont pas que des protocoles de sécurité. Ce sont les fondations de votre réputation d’expéditeur. Et en emailing B2B, la réputation conditionne directement la délivrabilité de vos emailing B2B.
Les fournisseurs de messagerie évaluent chaque domaine expéditeur selon plusieurs critères : taux de plaintes, taux de hard bounces et soft bounces, engagement des destinataires, et authentification. Un domaine correctement authentifié part avec un avantage. Un domaine sans authentification part avec un handicap, quelle que soit la qualité de son contenu.
Pour les entreprises qui font de la prospection par email ou qui gèrent des campagnes de nurturing, l’enjeu est concret. Un email qui n’arrive pas en boîte de réception ne sera jamais lu, jamais cliqué, et ne générera jamais de lead. L’authentification est la condition préalable à tout le reste : objet travaillé, contenu pertinent, segmentation fine. Tout cela n’a de valeur que si le message arrive.
Et il ne s’agit pas seulement des grands volumes. Même une entreprise qui envoie quelques centaines d’emails par semaine bénéficie d’une authentification correcte. Les filtres anti-spam ne font pas de distinction : un domaine sans SPF ni DKIM est un domaine suspect, point. Par ailleurs, si un tiers usurpe votre domaine pour envoyer du spam, c’est votre réputation d’expéditeur qui en pâtit directement, avec des conséquences sur la délivrabilité de vos propres campagnes.
Le paysage réglementaire continue d’évoluer vers plus de rigueur. Après Google et Yahoo en 2024, Microsoft en 2025, la norme PCI DSS v4.0 rendra DMARC obligatoire en 2026 pour les organisations traitant des données de cartes bancaires. La tendance est claire et ne s’inversera pas.
Si vous n’avez pas encore configuré SPF, DKIM et DMARC sur votre domaine, c’est le moment de le faire. La mise en place prend quelques heures au plus, et les bénéfices sur votre délivrabilité sont immédiats. Et si la configuration est déjà en place, vérifiez qu’elle est à jour : clés DKIM en 2048 bits, politique DMARC qui progresse vers p=quarantine ou p=reject, tous vos flux d’envoi correctement déclarés.
