En bref : SPF, DKIM et DMARC sont trois protocoles d’authentification email complémentaires. SPF déclare quels serveurs ont le droit d’envoyer pour votre domaine. DKIM ajoute une signature cryptographique à chaque message. DMARC définit la politique à appliquer quand l’un ou l’autre échoue. Configurer les trois correctement, c’est la condition minimale pour atteindre la boîte de réception en B2B.

Configuration SPF, DKIM, DMARC : guide complet pour sécuriser vos envois

Vos emails arrivent en spam alors que votre contenu est propre, votre base qualifiée, vos objets travaillés. Le problème ne vient probablement pas de votre message. Il vient de votre domaine. En clair, vos enregistrements DNS ne disent rien de convaincant au serveur en face. Il ne vous reconnaît pas comme expéditeur légitime.

Depuis février 2024, Google et Yahoo ont durci le jeu : tout expéditeur de masse doit avoir configuré SPF, DKIM et DMARC correctement. Microsoft a suivi en avril 2025 avec des exigences similaires pour Outlook.com. Ce n’est plus une recommandation. C’est un prérequis technique, et les serveurs de messagerie qui reçoivent vos campagnes B2B vérifient ces enregistrements à chaque message reçu.

Dans ce guide, on passe en revue chaque protocole, la configuration pas à pas, et surtout les erreurs qu’on voit régulièrement plomber la délivrabilité chez les expéditeurs B2B. Si vous cherchez une vision d’ensemble sur le sujet, consultez notre guide complet de la délivrabilité.

Pourquoi l’authentification email est devenue incontournable

A l’origine, dans les années 70, personne n’a pensé à intégrer un mécanisme d’authentification dans le protocole email. Résultat : n’importe qui pouvait envoyer un message en se faisant passer pour quelqu’un d’autre. Et c’est toujours techniquement possible aujourd’hui. Le phishing et le spoofing reposent exactement là-dessus.

Les fraudes par email ont explosé, et les fournisseurs de messagerie ont fini par réagir. SPF est arrivé en 2006, DKIM a suivi, DMARC est apparu en 2012. Pendant longtemps, ces protocoles restaient optionnels. Un « nice to have » que les équipes techniques configuraient quand elles avaient le temps.

La donne a changé. Gmail, Outlook, Yahoo rejettent maintenant les emails non authentifiés. Ou ils les classent en spam, ce qui revient au même. Si vous faites de l’emailing B2B sans SPF, DKIM et DMARC en place, vos messages n’arriveront tout simplement pas. Le facteur a beau être de bonne volonté, sans adresse de retour il finit par jeter le courrier.

Et puis il y a la question de la réputation de domaine. Tous les emails qui partent depuis votre domaine comptent dans votre réputation : ceux de la plateforme emailing, du CRM, du helpdesk, des postes de vos collaborateurs. Tout. Et sans authentification, impossible de savoir qui utilise votre domaine. Un type mal intentionné pourrait très bien envoyer du spam sous votre nom et détruire votre réputation. Vous ne le sauriez même pas.

SPF : déclarer les serveurs autorisés à envoyer pour votre domaine

SPF, pour Sender Policy Framework, est le plus ancien des trois et aussi le plus facile à appréhender. Vous déclarez dans votre DNS quels serveurs ont le droit d’envoyer pour votre domaine. Quand un message arrive, le serveur en face va consulter cette liste et vérifier que le serveur d’envoi y figure bien.

La syntaxe d’un enregistrement SPF

Un enregistrement SPF est un enregistrement DNS de type TXT placé sur votre domaine. Voici un exemple concret :

v=spf1 include:spf.ediware.net include:_spf.google.com ip4:203.0.113.42 -all

Décomposons :

v=spf1 : indique qu’il s’agit d’un enregistrement SPF (obligatoire, toujours en premier)
include:spf.ediware.net : autorise les serveurs déclarés dans le SPF d’Ediware, votre plateforme emailing
include:_spf.google.com : autorise les serveurs Google Workspace si vous utilisez Gmail professionnel
ip4:203.0.113.42 : autorise une adresse IP spécifique, par exemple votre serveur applicatif
-all : refuse tout serveur non listé (politique stricte)

La différence entre ~all et -all

Le suffixe fait toute la différence :

-all (hard fail) : tout serveur non autorisé est rejeté. C’est la politique recommandée une fois votre configuration stabilisée.
~all (soft fail) : le serveur non autorisé n’est pas rejeté mais marqué comme suspect. Utile en phase de test pour ne pas bloquer des envois légitimes que vous auriez oubliés.
?all (neutre) : aucune indication. Autant ne pas avoir de SPF.

Les limites techniques de SPF

SPF a une contrainte technique importante : la limite de 10 lookups DNS. Chaque directive « include » ou « redirect » génère un lookup. Si votre enregistrement dépasse cette limite, il est invalide. Et un SPF invalide, c’est pire que pas de SPF du tout, car certains filtres le traitent comme un échec.

En pratique, cette limite pose problème aux entreprises qui utilisent beaucoup de services tiers : plateforme emailing, CRM avec envoi d’emails, outil de signature email, helpdesk, outil de facturation. Chacun demande son « include » et on atteint vite les 10 lookups.

La parade : regrouper les IP dans un seul sous-domaine dédié ou utiliser un service de « SPF flattening » qui remplace les includes par les IP résolues. Attention cependant, le flattening nécessite une mise à jour régulière car les IP des services tiers changent.

DKIM : la signature numérique qui certifie l’intégrité du message

SPF vérifie le serveur d’envoi. DKIM, lui, va un cran plus loin : il authentifie le message lui-même. DomainKeys Identified Mail, c’est son nom complet, ajoute une signature cryptographique dans l’en-tête de chaque email. Le serveur qui reçoit le message récupère votre clé publique dans le DNS, et s’en sert pour confirmer deux choses : le contenu n’a pas bougé en transit, et l’expéditeur est bien autorisé.

Comment fonctionne DKIM

Concrètement, ça fonctionne avec une paire de clés asymétriques :

Votre plateforme emailing génère deux clés : une clé privée qui reste secrète sur le serveur d’envoi, et une clé publique que vous publiez dans votre DNS.
A chaque envoi, le serveur prend certains éléments du message, le corps, des en-têtes comme le From ou le Subject, et les signe avec la clé privée.
La signature obtenue est insérée dans l’en-tête DKIM-Signature.
En réception, le serveur va chercher votre clé publique dans le DNS pour vérifier que la signature correspond.

Si la signature correspond, le message est authentifié. Si quelqu’un a modifié le contenu en route, la vérification échoue.

Configuration DNS pour DKIM

L’enregistrement DKIM est un enregistrement TXT placé sur un sous-domaine spécifique :

selecteur._domainkey.votredomaine.fr

Le « sélecteur » est un identifiant choisi par votre service d’envoi. Ediware utilise par exemple un sélecteur spécifique à chaque compte. En pratique, la valeur de l’enregistrement a cette tête :

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

Où la partie après « p= » est votre clé publique encodée en base64. La plupart des plateformes emailing vous fournissent directement l’enregistrement à copier-coller dans votre gestionnaire DNS.

Rotation des clés et bonnes pratiques

En théorie, il faudrait changer vos clés DKIM tous les 6 à 12 mois. La procédure : générer une nouvelle paire, publier la clé publique fraîche dans le DNS, basculer le serveur d’envoi sur la nouvelle clé privée, et après propagation, supprimer l’ancien enregistrement.

Dans les faits, presque personne ne le fait. Mais si votre clé privée fuite un jour, un attaquant pourra signer des messages frauduleux à votre place. La rotation réduit cette fenêtre de risque. Et tant qu’on parle de clés, optez pour du RSA 2048 bits. Le 1024 bits est considéré comme trop faible depuis un bon moment déjà.

DMARC : le chef d’orchestre qui définit la politique d’authentification

DMARC, pour Domain-based Message Authentication, Reporting & Conformance, c’est la couche qui vient chapeauter les deux autres. Il ne remplace ni SPF ni DKIM. Son rôle : dire au serveur destinataire quoi faire quand un message rate les vérifications SPF et DKIM.

Sans DMARC, chaque fournisseur fait ce qu’il veut. Gmail rejette, Yahoo classe en spam, un autre laisse passer. C’est la loterie. Avec DMARC, c’est vous qui fixez les règles.

L’alignement : le concept clé de DMARC

DMARC introduit la notion d’« alignement ». Pour qu’un message soit validé par DMARC, le domaine qui apparaît dans le champ « From » doit correspondre au domaine vérifié par SPF ou DKIM. C’est là que DMARC change la donne par rapport à SPF seul : SPF vérifie le domaine de l’enveloppe SMTP, pas celui que le destinataire voit dans sa boîte de réception.

Exemple : votre email affiche « contact@votreentreprise.fr » dans le From. DMARC va vérifier que le domaine SPF ou DKIM colle bien avec « votreentreprise.fr ». En mode « relaxed », les sous-domaines passent, mail.votreentreprise.fr sera accepté. En mode « strict », il faut que ce soit exactement le même domaine, sans variante.

Syntaxe d’un enregistrement DMARC

L’enregistrement DMARC est un enregistrement TXT placé sur le sous-domaine _dmarc :

_dmarc.votredomaine.fr

Exemple de valeur :

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@votredomaine.fr; pct=100; adkim=r; aspf=r

Les paramètres :

v=DMARC1 : identifiant du protocole
p= : la politique à appliquer. Trois valeurs possibles :
- none : ne rien faire, juste collecter les rapports. C’est le point de départ recommandé.
- quarantine : placer en spam les messages non conformes.
- reject : rejeter purement et simplement les messages non conformes.
rua= : adresse email où envoyer les rapports agrégés (quotidiens). Ces rapports XML vous indiquent qui envoie des emails depuis votre domaine et quels messages échouent.
pct= : pourcentage de messages soumis à la politique. Vous pouvez commencer à 10% et augmenter progressivement.
adkim= et aspf= : mode d’alignement pour DKIM et SPF (r=relaxed, s=strict).

La montée progressive en politique DMARC

Ne passez jamais directement à « reject ». La bonne approche en trois étapes :

p=none pendant 2 à 4 semaines : vous collectez les rapports sans bloquer quoi que ce soit. Vous identifiez tous les services qui envoient pour votre domaine, y compris ceux que vous aviez oubliés.
p=quarantine avec pct=25 puis 50 puis 100 : vous montez progressivement. Les messages non conformes sont placés en spam. Vous surveillez les rapports pour vous assurer qu’aucun envoi légitime n’est affecté.
p=reject : une fois que tous vos flux sont authentifiés et alignés, vous passez en rejet. À ce stade, tout email non conforme est bloqué.

Comptez entre 1 et 3 mois pour cette montée progressive. Ca demande de la patience, mais le jeu en vaut la chandelle. Un DMARC en reject protège votre domaine contre le spoofing et, on l’a constaté chez nos clients, améliore nettement la délivrabilité des campagnes.

Les erreurs courantes qui sabotent votre authentification

En plus de vingt ans de support technique chez Ediware, on a vu passer les mêmes erreurs des dizaines de fois. Voici celles qui reviennent le plus souvent.

Plusieurs enregistrements SPF sur le même domaine. La norme RFC 7208 est formelle : un domaine ne doit avoir qu’un seul enregistrement SPF. Si vous en avez deux, le résultat est imprévisible. Les serveurs destinataires peuvent choisir l’un ou l’autre, ou considérer le SPF comme invalide. Quand vous ajoutez un nouveau service, il faut ajouter son « include » dans votre enregistrement existant, pas créer un second enregistrement.

Dépasser la limite des 10 lookups DNS en SPF. Chaque include génère un lookup et la norme autorise 10 lookups au maximum. Dépassez ce seuil et votre SPF est considéré comme en erreur permanente (PermError). Le pire, c’est que tout semble normal quand vous testez avec un outil basique qui ne compte pas les lookups imbriqués.

Oublier d’aligner le domaine d’envoi. Vous avez configuré SPF et DKIM sur votredomaine.fr mais votre plateforme emailing envoie depuis mail.votredomaine.fr. Si DMARC est en mode strict, l’alignement échoue. Vérifiez toujours que le domaine du champ From correspond au domaine authentifié, ou utilisez un alignement relaxed.

Ne pas surveiller les rapports DMARC. Publier un enregistrement DMARC en mode « none » sans jamais lire les rapports, c’est comme installer une caméra de surveillance sans regarder les images. Ces rapports vous révèlent les tentatives de spoofing, les services oubliés qui envoient pour votre domaine, les erreurs de configuration. Il existe des outils gratuits et payants pour les analyser : dmarcian, Postmark DMARC, URIports.

Utiliser une clé DKIM trop courte. Les clés RSA 1024 bits sont encore acceptées mais de plus en plus de filtres les pénalisent. Passez en 2048 bits. Ça ne coûte rien et ça renforce la sécurité de vos signatures.

Les outils pour vérifier votre configuration

Vous pensez que tout est bon ? Vérifiez avant de passer à autre chose. Voici les outils qu’on recommande.

MXToolbox (mxtoolbox.com) : c’est un peu le couteau suisse du diagnostic DNS. Vous entrez votre domaine, il vous sort les résultats SPF, DKIM, DMARC et pointe du doigt les erreurs de syntaxe, les lookups en trop, les incohérences. On l’utilise quotidiennement chez Ediware.

Mail-Tester (mail-tester.com) : vous envoyez un email à une adresse temporaire et vous obtenez une note sur 10. SPF, DKIM, DMARC mais aussi le contenu, les blacklists, bref un diagnostic complet en une seule manip. Pratique pour avoir une vue d’ensemble rapide.

Google Postmaster Tools : gratuit, et franchement sous-utilisé. Si vous envoyez vers Gmail, vous y verrez votre taux d’authentification SPF/DKIM/DMARC, la réputation de votre domaine et de vos IP, plus les erreurs de livraison. Pour le suivi au long cours, il n’y a pas mieux.

DMARC Analyzer ou dmarcian : parce que personne ne va lire des rapports XML à la main, ces services les transforment en tableaux de bord lisibles. Qui envoie depuis votre domaine, quels messages échouent, pourquoi. La version gratuite de dmarcian fait le travail pour commencer.

L’en-tête du message : la méthode la plus directe, et souvent oubliée. Dans Gmail, « Afficher l’original » vous donne les résultats SPF, DKIM, DMARC tels que le serveur les a vus. Pass, fail, neutral. Pas d’interprétation, juste la réalité brute de ce qui s’est passé à la réception.

Ce qu’il faut retenir pour votre configuration

Les trois protocoles fonctionnent ensemble, il ne sert pas à grand-chose d’en configurer un en laissant les deux autres de côté. SPF déclare vos serveurs autorisés. DKIM certifie que le contenu n’a pas bougé. DMARC tranche quand quelque chose cloche.

La marche à suivre pour un domaine qui part de zéro :

Listez tous les services qui envoient des emails pour votre domaine : plateforme emailing, CRM, helpdesk, facturation, signatures email.
Créez un enregistrement SPF unique qui inclut tous ces services, en restant sous la limite de 10 lookups.
Configurez DKIM pour chaque service d’envoi avec des clés RSA 2048 bits.
Publiez un enregistrement DMARC en mode « none » avec une adresse de rapport.
Analysez les rapports pendant 2 à 4 semaines.
Montez progressivement vers « quarantine » puis « reject ».
Vérifiez régulièrement avec MXToolbox ou Mail-Tester.

Si la sécurité des emails vous préoccupe, et franchement elle devrait préoccuper toute entreprise qui communique par email, ces trois protocoles sont le minimum syndical. Mieux vaut passer quelques heures sur la configuration maintenant que des semaines à comprendre pourquoi vos campagnes atterrissent en spam.

Chez Ediware, on accompagne nos clients sur ces sujets depuis des années. La plateforme génère automatiquement les enregistrements DKIM et SPF qu’il faut publier dans votre DNS. Vous les copiez-collez, vous configurez DMARC en suivant la méthode progressive qu’on vient de décrire, et c’est réglé.