Pourquoi l’e-mail reste usurpable par conception
Le protocole d’envoi de courrier électronique a été conçu à une époque où la confiance entre serveurs était la règle. Rien, dans le mécanisme d’origine, n’oblige l’expéditeur à prouver qu’il a le droit d’écrire au nom du domaine qu’il affiche. N’importe quel serveur peut prétendre émettre pour @votre-entreprise.fr, et le destinataire n’a, par défaut, aucun moyen de le contester. Cette permissivité native est la racine de l’usurpation de domaine, vecteur récurrent de l’hameçonnage ciblé et de la fraude au virement.
Trois mécanismes complémentaires sont venus combler cette lacune sans réécrire le protocole de base : SPF, DKIM et DMARC. Ils ne chiffrent pas le contenu et ne remplacent pas un filtrage anti-spam ; ils répondent à une question précise et limitée : ce message a-t-il réellement été émis par une source autorisée pour ce domaine ?
Comprendre ce périmètre est essentiel pour un RSSI. Ces trois standards traitent l’authentification de l’expéditeur, pas la confidentialité du message ni la totalité du risque d’hameçonnage. Ils constituent une couche indispensable, à articuler avec les autres mesures décrites dans notre guide cybersécurité entreprise et avec une stratégie de défense contre l’hameçonnage.
SPF : déclarer les émetteurs autorisés
Le Sender Policy Framework, normalisé par le RFC 7208 [1], répond à une question simple : quels serveurs ont le droit d’émettre du courrier pour mon domaine ?
Le titulaire du domaine publie, dans sa zone DNS, un enregistrement TXT qui énumère les sources légitimes : adresses IP de ses propres serveurs de messagerie, plages d’adresses de ses prestataires, inclusions des domaines d’envoi de ses outils tiers. Lorsqu’un serveur de réception reçoit un message, il extrait l’adresse d’enveloppe d’expédition, interroge le DNS du domaine correspondant et vérifie que l’adresse IP émettrice figure bien dans la liste autorisée.
Un enregistrement SPF se termine par un mécanisme qui indique le comportement attendu si l’émetteur n’est pas listé. La forme la plus stricte, le -all (hard fail), demande de considérer comme illégitime tout message provenant d’une source non déclarée. La forme intermédiaire, le ~all (soft fail), signale la non-conformité sans imposer le rejet.
SPF souffre de deux limites importantes. D’une part, il vérifie le domaine d’enveloppe, qui n’est pas celui que l’utilisateur voit dans son client de messagerie : un attaquant peut donc afficher un nom de domaine différent de celui qui est contrôlé par SPF. D’autre part, SPF se rompt lors d’un transfert de message : quand un courriel est réexpédié par un serveur intermédiaire, l’adresse IP émettrice change et la vérification échoue, alors que le message est légitime. Ces deux limites expliquent pourquoi SPF ne suffit pas seul et pourquoi DMARC introduit la notion d’alignement.
Le RFC impose par ailleurs une limite technique souvent négligée : la résolution d’un enregistrement SPF ne doit pas déclencher plus de dix recherches DNS. Au-delà, le résultat devient une erreur de configuration (permerror) qui invalide silencieusement la protection. Les organisations qui empilent de nombreuses inclusions de prestataires franchissent ce seuil sans s’en rendre compte, ce qui constitue une cause fréquente de SPF inopérant.
Un point d’attention pratique mérite d’être souligné. Beaucoup d’équipes considèrent à tort que publier un enregistrement SPF suffit à se protéger. En réalité, un SPF en ~all que personne ne durcit ne fait que documenter les émetteurs sans empêcher quoi que ce soit, car le soft fail laisse le destinataire libre de livrer le message. C’est l’alignement imposé par DMARC, et lui seul, qui transforme cette déclaration en barrière effective. SPF, pris isolément, doit donc être vu comme une brique d’information autant que de sécurité : il alimente la décision de DMARC, il ne la remplace pas.
DKIM : signer cryptographiquement le message
DomainKeys Identified Mail, normalisé par le RFC 6376 [2], apporte ce que SPF ne fait pas : une preuve cryptographique attachée au message lui-même.
Le serveur émetteur calcule une signature numérique portant sur certains en-têtes et sur le corps du message, à l’aide d’une clé privée que seule l’organisation détient. Cette signature est insérée dans un en-tête dédié. La clé publique correspondante est publiée dans le DNS du domaine, sous un sélecteur identifiant la paire de clés utilisée. Le serveur de réception récupère cette clé publique, recalcule la signature et vérifie qu’elle correspond. Si c’est le cas, deux propriétés sont établies : le message a bien été signé par le détenteur de la clé du domaine, et son contenu signé n’a pas été altéré en chemin.
L’avantage majeur de DKIM sur SPF est sa résistance au transfert. La signature voyageant avec le message, elle reste valide même lorsque le courriel transite par un serveur intermédiaire, tant que les en-têtes signés ne sont pas modifiés. C’est la raison pour laquelle DMARC accepte qu’un message soit considéré comme authentifié dès lors que soit SPF, soit DKIM réussit avec alignement.
La gestion des clés DKIM relève d’une hygiène cryptographique classique. Les clés doivent être d’une longueur suffisante, et leur rotation périodique constitue une bonne pratique pour limiter l’impact d’une éventuelle compromission. Cette logique de gouvernance des secrets s’inscrit dans la même démarche de réduction de surface que les principes décrits dans notre article sur l’architecture Zero Trust. Une clé DKIM compromise permettrait à un attaquant de signer des messages frauduleux qui passeraient l’authentification : il s’agit donc d’un secret à protéger au même titre qu’une clé de chiffrement.
DMARC : arbitrer et imposer l’alignement
DMARC, pour Domain-based Message Authentication, Reporting and Conformance, normalisé par le RFC 7489 [3], est la pièce qui donne sa cohérence à l’ensemble. Il remplit trois fonctions.
Imposer l’alignement. SPF et DKIM valident chacun un domaine, mais pas nécessairement celui que voit l’utilisateur. DMARC exige que le domaine validé par SPF ou DKIM corresponde au domaine affiché dans l’en-tête visible du message. C’est cet alignement qui ferme la faille de SPF : un attaquant peut faire passer SPF sur un domaine qu’il contrôle, mais il ne peut pas aligner ce domaine sur le vôtre sans posséder votre clé DKIM ou figurer dans votre SPF.
Décider du sort des messages non conformes. Le titulaire du domaine publie une politique dans le DNS qui indique aux serveurs de réception ce qu’ils doivent faire d’un message qui échoue l’authentification alignée. Trois valeurs sont possibles : none (ne rien faire de particulier, se contenter d’observer), quarantine (traiter le message comme suspect, généralement vers les indésirables) et reject (refuser le message avant la boîte de réception).
Produire des rapports. DMARC instaure un canal de retour : les serveurs de réception envoient au titulaire du domaine des rapports agrégés (RUA) recensant les volumes de messages reçus en son nom, leurs sources et le résultat de l’authentification. Ces rapports sont le tableau de bord du dispositif. Sans eux, il est impossible de savoir si un passage au rejet va casser un flux légitime.
L’ordre logique est donc le suivant : SPF et DKIM établissent l’authentification, DMARC en exige l’alignement, arbitre les cas d’échec et restitue la visibilité. Publier DMARC sans avoir solidement déployé les deux premiers revient à brancher un disjoncteur sur une installation non câblée.
Déployer par paliers, sans casser les flux légitimes
Le risque numéro un d’un projet DMARC n’est pas l’attaquant : c’est le faux positif. Une politique de rejet activée trop tôt bloque des courriels parfaitement légitimes, par exemple ceux envoyés par un prestataire de facturation ou une plateforme marketing dont l’émission n’avait pas été déclarée. La méthode de déploiement répond précisément à ce risque par une montée en charge progressive et documentée.
Étape 1 : inventaire des émetteurs. Avant toute publication, il faut recenser tout ce qui émet du courrier au nom du domaine. Cet inventaire dépasse largement le serveur de messagerie principal : outils marketing, plateformes de signature électronique, applications de ressources humaines, systèmes de tickets, notifications applicatives, services de facturation. Chaque source légitime devra être couverte par SPF, signée par DKIM, ou les deux. C’est l’étape la plus longue et la plus organisationnelle, et c’est elle qui conditionne le succès.
Étape 2 : publication en mode observation. L’organisation publie un enregistrement DMARC en politique none, avec une adresse de réception des rapports agrégés. À ce stade, aucun message n’est bloqué. Le dispositif se contente de collecter les rapports, qui révèlent toutes les sources émettant au nom du domaine, y compris celles oubliées lors de l’inventaire, et celles, illégitimes, qui usurpent déjà le domaine.
Étape 3 : analyse et mise en conformité. À la lecture des rapports, on corrige : on ajoute les émetteurs légitimes manquants au SPF, on active la signature DKIM là où elle fait défaut, on identifie les sources frauduleuses. Cette phase d’analyse peut s’appuyer sur une centralisation des journaux comparable à celle décrite dans notre article sur la journalisation et la détection via SIEM, afin de corréler les rapports DMARC avec les autres signaux de sécurité.
Étape 4 : durcissement progressif. Lorsque les rapports montrent que la quasi-totalité des flux légitimes passent l’authentification alignée, on bascule en quarantine, d’abord sur un faible pourcentage du trafic grâce au paramètre de pourcentage prévu par le standard, puis sur la totalité. La dernière marche est le passage en reject, qui offre la protection maximale. NIST recommande explicitement cette progression maîtrisée plutôt qu’une activation brutale [4].
Cette discipline de déploiement par paliers fait écho aux bonnes pratiques portées par l’ANSSI en matière de sécurisation de la messagerie [5], qui insistent sur la nécessité d’une mise en oeuvre vérifiée plutôt que d’une activation hâtive.
Lire les rapports : le tableau de bord du dispositif
Les rapports agrégés DMARC sont des fichiers structurés, envoyés périodiquement par les serveurs de réception. Bruts, ils sont difficiles à exploiter à la main au-delà d’un faible volume. La plupart des organisations utilisent un outil d’agrégation qui transforme ces données en vues lisibles.
Ce que l’on cherche dans ces rapports tient en quelques questions. Quelles sont toutes les sources qui émettent en mon nom ? Sont-elles toutes légitimes et reconnues ? Quel pourcentage de mon trafic passe l’authentification alignée ? Reste-t-il des flux légitimes en échec qu’il faut corriger avant de durcir ? Observe-t-on des sources clairement frauduleuses, signe d’une tentative d’usurpation active ?
Une remarque s’impose sur la nature des rapports. Les rapports agrégés (RUA) contiennent des statistiques de volume et d’authentification par source, sans contenu de message : leur exploitation ne soulève pas de difficulté particulière de confidentialité. Les rapports d’échec détaillés (RUF), plus rarement disponibles, peuvent en revanche inclure des fragments de messages réels : leur collecte doit être encadrée au regard de la protection des données personnelles, et beaucoup d’opérateurs ne les émettent plus.
ARC, BIMI et MTA-STS : les compléments
Trois mécanismes gravitent autour du triptyque principal et méritent une mention.
ARC (Authenticated Received Chain), normalisé par le RFC 8617, traite la rupture d’authentification lors des transferts. Lorsqu’un message légitime transite par une liste de diffusion ou un service de réacheminement qui modifie ses en-têtes, SPF et DKIM peuvent échouer. ARC permet aux serveurs intermédiaires de conserver une trace signée du résultat d’authentification initial, que le destinataire final peut prendre en compte. ARC n’est pas un substitut à DMARC mais un correctif au problème spécifique du transfert.
BIMI (Brand Indicators for Message Identification) permet d’associer le logo officiel d’une organisation à ses messages authentifiés dans les clients de messagerie compatibles. BIMI exige au préalable une politique DMARC en quarantine ou en reject : il constitue donc une motivation supplémentaire à mener le déploiement à son terme, en transformant une mesure de sécurité en bénéfice de marque visible.
MTA-STS sécurise le transport entre serveurs en imposant le chiffrement de la connexion. Il ne relève pas de l’authentification de l’expéditeur mais de la confidentialité et de l’intégrité du canal. Il complète utilement le triptyque sans s’y substituer. À ses côtés, le mécanisme TLS-RPT fournit des rapports sur les échecs de connexion chiffrée, offrant la même logique de visibilité que les rapports DMARC mais appliquée au transport. L’ensemble forme un écosystème cohérent où chaque standard couvre une dimension précise : l’authentification de l’origine, la résistance au transfert, la confidentialité du canal et la restitution des incidents.
Pour un RSSI, l’enjeu n’est pas de tout déployer d’un coup, mais de hiérarchiser. SPF, DKIM et DMARC constituent le socle prioritaire, car ils ferment le vecteur d’usurpation le plus exploité. ARC se justifie dès lors que l’organisation gère des listes de diffusion ou des réacheminements importants. MTA-STS et BIMI viennent ensuite, le premier pour durcir le transport, le second pour valoriser un dispositif déjà mature. Cet ordre de priorité évite la dispersion et concentre l’effort là où la réduction de risque est la plus forte.
Les erreurs récurrentes à éviter
L’expérience des déploiements fait ressortir un petit nombre d’erreurs qui reviennent presque systématiquement.
Passer en reject sans inventaire complet. C’est la faute la plus coûteuse. Bloquer des factures clients ou des notifications applicatives parce qu’un émetteur légitime n’avait pas été déclaré crée un incident métier majeur et discrédite le projet de sécurité. La règle est de ne jamais durcir avant que les rapports ne le confirment.
Dépasser la limite de dix recherches DNS sur SPF. L’empilement d’inclusions de prestataires fait silencieusement basculer SPF en erreur permanente. Un audit régulier du nombre de recherches est nécessaire, et la consolidation des inclusions parfois indispensable.
Oublier les sous-domaines et les domaines non émetteurs. Un attaquant ciblera volontiers un sous-domaine ou un domaine annexe que l’organisation n’utilise pas pour émettre du courrier et qu’elle a négligé de protéger. DMARC prévoit une politique dédiée aux sous-domaines, et les domaines qui n’émettent jamais de courrier doivent publier une politique de rejet stricte assortie d’un SPF vide, afin de fermer cette porte.
Négliger la rotation des clés DKIM. Une clé qui ne change jamais reste exploitable indéfiniment en cas de fuite. La rotation périodique est une mesure d’hygiène simple et trop souvent omise.
Croire que DMARC règle tout l’hameçonnage. DMARC neutralise l’usurpation directe du domaine. Il ne fait rien contre les domaines ressemblants, contre la manipulation du nom d’affichage, ni contre un compte interne légitime compromis. Ces vecteurs relèvent du filtrage, de la sensibilisation et de la détection, et participent du même continuum de risque que celui analysé dans notre article sur les vecteurs d’attaque par rançongiciel.
Place dans le dispositif réglementaire et de conformité
La sécurisation de la messagerie n’est pas une exigence réglementaire isolée, mais elle s’inscrit dans des obligations plus larges. La directive NIS2 impose aux entités concernées une analyse des risques et des mesures techniques proportionnées de sécurité des systèmes d’information. L’authentification de la messagerie, vecteur majeur d’intrusion initiale, fait naturellement partie des mesures attendues d’une organisation mature. La même logique se retrouve dans les référentiels d’hygiène promus en France, dont les principes sont détaillés dans notre présentation du référentiel ReCyF de l’ANSSI et dans notre guide NIS2 pour l’entreprise.
Pour un RSSI, le message à retenir est qu’un déploiement DMARC complet, jusqu’au rejet, constitue l’un des contrôles au meilleur rapport entre coût et réduction de risque. Il ne demande pas d’investissement matériel, il s’appuie sur des standards ouverts et matures, et il ferme un vecteur d’usurpation utilisé quotidiennement contre les entreprises. Le frein n’est jamais technique : il est organisationnel, et tient à la rigueur de l’inventaire et à la patience du déploiement par paliers.
Conclusion
SPF, DKIM et DMARC ne se concurrencent pas : ils s’enchaînent. SPF déclare les serveurs autorisés, DKIM signe et scelle le message, DMARC impose l’alignement, arbitre les cas d’échec et restitue la visibilité par ses rapports. Déployés ensemble et menés jusqu’au rejet, ils suppriment un vecteur entier d’usurpation de domaine. La condition de réussite n’est pas la maîtrise cryptographique mais la méthode : inventorier tous les émetteurs, publier en observation, lire les rapports, durcir progressivement. C’est à ce prix que l’on transforme une faille de conception du courrier électronique en barrière fiable.
Sources : RFC 7489 (DMARC), RFC 7208 (SPF) et RFC 6376 (DKIM) de l’IETF ; publication spéciale NIST SP 800-177r1 sur la sécurité de la messagerie ; recommandations de l’ANSSI (cyber.gouv.fr).