SPF, DKIM, DMARC : la triple authentification e-mail qui protège votre domaine
SPF, DKIM et DMARC forment le standard le plus solide pour protéger votre nom de domaine contre l'usurpation et le phishing, et garantir que vos e-mails arrivent en boîte principale. Explications concrètes pour les dirigeants et responsables IT.
Chaque jour, des organisations reçoivent des e-mails qui semblent provenir de votre domaine — mais que vous n’avez jamais envoyés. Des fournisseurs, des clients, des partenaires reçoivent de faux messages signés avec votre nom, votre adresse, votre marque. C’est l’usurpation de domaine (domain spoofing), et c’est l’un des vecteurs d’attaque les plus utilisés dans les campagnes de phishing et de fraude au virement.
La réponse technique à ce problème existe, elle est standardisée, et elle repose sur trois mécanismes complémentaires : SPF, DKIM et DMARC. Ensemble, ils constituent ce qu’on appelle la triple authentification e-mail — le niveau le plus élevé de protection pour un nom de domaine.
Pourquoi votre domaine peut être usurpé sans protection
Le protocole e-mail d’origine (SMTP, conçu dans les années 1980) n’intègre aucun mécanisme d’authentification. N’importe qui peut techniquement envoyer un e-mail en revendiquant n’importe quelle adresse d’expéditeur. Sans contre-mesures, un attaquant peut expédier un message avec From: contact@votreentreprise.fr depuis n’importe quel serveur de la planète.
Les serveurs de messagerie modernes (Gmail, Microsoft 365, OVH…) ont intégré des filtres pour détecter ces abus — mais seulement si le domaine d’origine a correctement configuré SPF, DKIM et DMARC. Sans ces enregistrements, vos e-mails légitimes peuvent finir en spam, et vos e-mails frauduleux peuvent arriver en boîte principale chez vos interlocuteurs.
SPF — Qui est autorisé à envoyer en votre nom ?
SPF (Sender Policy Framework) est un enregistrement publié dans le DNS de votre domaine. Il liste explicitement les serveurs e-mail autorisés à envoyer des messages depuis votre domaine.
Concrètement, quand un serveur de messagerie reçoit un e-mail prétendant venir de @votreentreprise.fr, il interroge le DNS de votre domaine et vérifie : “L’adresse IP de ce serveur est-elle dans la liste des expéditeurs autorisés ?”
votreentreprise.fr. TXT "v=spf1 include:_spf.google.com include:_spf.ovh.net ~all"
Un SPF mal configuré — ou absent — signifie que n’importe quel serveur peut se revendiquer expéditeur légitime de votre domaine.
Limites du SPF seul : SPF vérifie uniquement le serveur d’envoi, pas le contenu du message. Et il ne couvre pas les cas de transfert d’e-mail (email forwarding), où l’adresse IP légitime change en transit. C’est pourquoi SPF seul est insuffisant.
DKIM — La signature cryptographique du message
DKIM (DomainKeys Identified Mail) ajoute une signature numérique à chaque e-mail sortant. Cette signature est générée avec une clé privée détenue par votre serveur de messagerie, et vérifiable par n’importe qui grâce à une clé publique publiée dans votre DNS.
Quand un destinataire reçoit votre e-mail, son serveur vérifie la signature :
- Il récupère votre clé publique dans le DNS
- Il recalcule la signature à partir du contenu du message
- Si ça correspond : le message n’a pas été altéré en transit, et il vient bien d’un serveur qui détient votre clé privée
mail._domainkey.votreentreprise.fr. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhk..."
DKIM résiste au email forwarding là où SPF échoue — la signature voyage avec le message, quelle que soit la route empruntée.
Limite de DKIM seul : DKIM authentifie le message, mais ne dit pas quoi faire si la vérification échoue. Un attaquant peut très bien envoyer un e-mail sans signature DKIM depuis votre domaine — le serveur de réception constate l’absence de signature, mais sans instruction claire, il peut quand même laisser passer le message.
DMARC — La politique qui donne les ordres
DMARC (Domain-based Message Authentication, Reporting and Conformance) est le chef d’orchestre. Il s’appuie sur SPF et DKIM, et définit la politique à appliquer quand un message échoue les vérifications.
Un enregistrement DMARC ressemble à ceci :
_dmarc.votreentreprise.fr. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@votreentreprise.fr; pct=100"
La directive clé est p= (policy) :
p=none— mode observation : on collecte des rapports, aucune action n’est prise sur les messages qui échouentp=quarantine— les messages qui échouent SPF et DKIM sont envoyés en spam/quarantainep=reject— les messages qui échouent sont refusés et ne sont pas délivrés
p=reject est l’objectif. C’est le seul mode qui garantit qu’aucun e-mail usurpant votre domaine ne sera délivré aux destinataires.
DMARC ajoute aussi une notion d’alignement : non seulement SPF et DKIM doivent passer, mais le domaine vérifié doit correspondre au domaine affiché dans le champ From: visible par le destinataire. C’est ce qui ferme la porte aux techniques de spoofing qui passent SPF sur un sous-domaine différent.
Les rapports DMARC
DMARC permet de recevoir des rapports agrégés (quotidiens) et des rapports forensiques de chaque serveur qui traite vos e-mails. Ces rapports indiquent :
- Quels serveurs envoient des e-mails depuis votre domaine
- Combien de messages passent ou échouent les vérifications
- Si des tentatives d’usurpation sont en cours
Ces rapports sont essentiels pour configurer SPF et DKIM correctement avant de passer en mode reject — sans eux, on risque de bloquer des e-mails légitimes (newsletters, outils tiers, formulaires).
La démarche recommandée : progresser par étapes
Passer directement à p=reject sans préparation peut bloquer des flux e-mail légitimes que vous ignorez (un outil marketing, un logiciel de facturation, un ERP qui envoie des alertes). La bonne pratique est de procéder par étapes :
- Auditer les flux existants — identifier tous les services qui envoient des e-mails depuis votre domaine
- Configurer SPF et DKIM pour chacun de ces services
- Déployer DMARC en
p=none— collecter les rapports sans bloquer - Analyser les rapports pendant 2 à 4 semaines — identifier les sources légitimes manquantes et les tentatives d’usurpation
- Passer à
p=quarantine— les anomalies vont en spam, vos flux légitimes continuent - Passer à
p=reject— protection maximale activée
Ce que ça change concrètement
Pour vos interlocuteurs : Personne ne peut envoyer de faux e-mails en se réclamant de votre organisation. La fraude au fournisseur, la fraude au président, les campagnes de phishing ciblées sur vos clients — tous ces scénarios deviennent considérablement plus difficiles.
Pour vos propres e-mails : Les grandes messageries (Gmail, Microsoft 365, Yahoo…) favorisent la délivrabilité des domaines correctement authentifiés. Vos e-mails arrivent en boîte principale, pas en spam.
Pour votre réputation de domaine : Un domaine qui passe DMARC en reject est identifié comme fiable par les infrastructures de messagerie mondiales. C’est un signal de maturité qui joue sur l’ensemble de vos communications.
Ce que ça ne remplace pas
SPF, DKIM et DMARC protègent votre domaine contre l’usurpation — ils ne protègent pas contre la compromission de votre compte e-mail lui-même. Si un attaquant obtient les identifiants d’une vraie boîte mail de votre organisation, il n’a pas besoin d’usurper votre domaine : il envoie depuis le vrai compte, et DMARC laisse passer.
La protection contre la compromission de compte passe par d’autres mesures : authentification forte (MFA résistant au phishing), surveillance des connexions inhabituelles, détection des règles de transfert automatique. Ces couches sont complémentaires, pas substituables.
La triple authentification e-mail est aujourd’hui un prérequis, pas une option avancée. C’est l’une des premières vérifications effectuées lors d’un diagnostic cyber — et l’une des plus simples à corriger quand elle est absente. Si vous ne savez pas si votre domaine est correctement protégé, c’est une question à poser maintenant.
Un diagnostic DigitalSpoon couvre l’ensemble de votre exposition e-mail : configuration DNS, flux d’envoi non déclarés, politique DMARC, et recommandations priorisées.