Le « déficit de sécurité des e-mails » : l'indicateur de cybersécurité que personne ne mesure

Chaque équipe de sécurité communique avec assurance certains chiffres : tentatives de hameçonnage bloquées, détections de logiciels malveillants, tentatives de connexion infructueuses, identifiants exposés, temps moyen de réponse. Ce que presque personne ne mentionne, c'est le travail qui aurait dû être terminé il y a des mois et qui ne cesse d'être reporté au sprint suivant.

Ce retard porte un nom qu'il convient de mentionner : la dette de sécurité des e-mails — ces problèmes non résolus d’authentification, de propriété et de configuration qui s’accumulent au sein de votre infrastructure de messagerie et dont le dénouement devient d’autant plus coûteux que votre organisation se développe autour d’eux.

Le courrier électronique est particulièrement efficace pour accumuler ce genre de problèmes. Une nouvelle plateforme SaaS commence à envoyer des e-mails en votre nom. Un enregistrement DNS est modifié lors d’une migration. Un sous-domaine « temporaire » reste actif. Un fournisseur continue d’envoyer des identifiants d’accès bien après la fin du projet. Pris isolément, chaque cas semble ne nécessiter que cinq minutes de travail pour être résolu.

À quoi ressemble réellement le « déficit de sécurité des e-mails » ?

Ce concept s'inspire de la notion de « dette technique » dans le domaine du développement logiciel. On prend un raccourci pour résoudre le problème du moment, mais on fait peser la charge de la maintenance sur son « moi futur ».

Les systèmes de messagerie accumulent rapidement ces raccourcis, car l'infrastructure d'envoi n'appartient presque jamais à une seule équipe. Le service marketing gère la plateforme de campagne. Les RH sont responsables de l'outil de recrutement. Le service d'assistance dispose du système de tickets. Les développeurs intègrent deux ou trois API d'e-mails transactionnels. Le service informatique se retrouve quant à lui chargé de gérer les enregistrements DNS qui assurent la cohésion de l'ensemble.

Symptômes typiques :

• Des services d'envoi inconnus continuent d'utiliser votre domaine ;
• Les mécanismes d'SPF s résiduels issus d'une migration qui s'est achevée il y a deux ans ;
• Des clés DKIM pointant vers des services que plus personne n'utilise ;
• Politiques DMARC en mode de surveillance, sans propriétaire clairement identifié ;
• Les sous-domaines temporaires qui n'ont jamais fait l'objet d'un nouvel examen ;
• Les prestataires tiers qui conservent un accès aux services d'envoi après l'expiration de leur contrat.

Aucun d'entre eux ne déclenche d'incident le jour même où il apparaît. C'est précisément pour cette raison qu'ils survivent.

L'authentification devient de plus en plus compliquée avec le temps

La configuration d'SPF, DKIM et DMARC sur un tout nouveau domaine est vraiment simple. Le plus difficile, c'est de veiller à ce que ces trois éléments restent corrects au fil des années, malgré les évolutions de l'infrastructure.

Prenons l'exemple de SPF. Vous commencez avec Google Workspace et un seul prestataire marketing. Puis, l'équipe commerciale ajoute une plateforme, le service de recrutement se dote de son propre système et l'équipe d'ingénierie intègre une API de messagerie. Le nombre d'enregistrements augmente, mais les anciens enregistrements sont rarement supprimés au même rythme — c'est ainsi que les domaines finissent par atteindre leurs limites de consultation, publiant des enregistrements SPF en double, ou subissent SPF des échecs que personne ne peut expliquer. Maîtriser la SPF syntaxe correctement une fois est facile ; la maintenir correcte, c'est ça la maintenance.

DKIM suit le même cycle de vie. Les clés appartiennent à des expéditeurs spécifiques, et ces derniers changent. Un sélecteur publié peut rester techniquement valide longtemps après que le service qui le sous-tend a cessé d'être utilisé au quotidien, et DKIM commence à échouer pour des raisons enfouies dans un ticket datant de 2023.

C'est là que les rapports DMARC prennent tout leur sens. Les rapports agrégés indiquent quels systèmes envoient réellement des e-mails au nom de votre domaine — et non pas ceux que vous pensez être les auteurs de ces envois. La lecture de ces rapports transforme les écarts invisibles en une liste que vous pouvez traiter, et PowerDMARC vous offre une visibilité sur les protocoles DMARC, « SPF » et DKIM dans une seule vue, au lieu d’obliger votre équipe à traiter chaque enregistrement comme une tâche DNS isolée.

Cela change la donne. La question « Le protocole DMARC est-il activé ? » n'est pas pertinente. Ce qu'il faut se demander, c'est : « Connaissons-nous tous les services qui envoient actuellement des e-mails sous notre domaine, et chacun d'entre eux a-t-il toujours sa place ici ? »

Le problème de l'expéditeur oublié

Il existe une certaine « dette de sécurité » au niveau des e-mails, même lorsque toutes les données sont techniquement correctes.

Imaginez une plateforme de webinaires mise en place il y a deux ans. L'employé qui l'avait configurée a quitté l'entreprise. Le compte n'a pas été utilisé depuis des mois. Il est pourtant toujours possible d'envoyer des e-mails authentifiés via le domaine de votre entreprise.

Du point de vue d’un pirate, « ancien » ne signifie pas « inoffensif ». Un compte oublié constitue une voie d’accès privilégiée à votre environnement de messagerie électronique, que personne ne surveille.

Une analyse rigoureuse de l'expéditeur permet de répondre à six questions concrètes :

• Quel système envoie cet e-mail ?
• À quelle équipe appartient ce compte ?
• Quel domaine ou sous-domaine utilise-t-il ?
• Est-ce qu'il respecte les règles d'alignement « SPF » et DKIM?
• À quand remonte sa dernière utilisation légitime ?
• Qui a le pouvoir de le retirer ?

Cette dernière question a tendance à entraîner davantage de retards que l'ensemble de l'étude technique. Identifier un émetteur superflu ne prend que quelques minutes. Obtenir l'autorisation de le désactiver peut prendre des semaines.

L'authentification des e-mails ne couvre pas l'intégralité de l'attaque

Une autre forme de « dette » apparaît lorsqu'une entreprise s'attend à ce qu'un seul mécanisme de contrôle permette de résoudre un problème qui dépasse son champ d'action.

Le protocole DMARC, lorsqu’il est appliqué de manière stricte, rend l’usurpation directe de domaine très difficile. Il n’empêche toutefois pas tous les messages de hameçonnage. Les attaquants se rabattent alors sur des domaines similaires, des comptes tiers compromis, des pièces jointes malveillantes et des pages convaincantes destinées à récolter des identifiants.

À ce stade, le problème dépasse le cadre de l'authentification de l'expéditeur. Dès qu'un fichier ou un lien malveillant atteint l'appareil d'un utilisateur, vous devez compter sur la détection au niveau des terminaux, la protection du navigateur, le filtrage des URL ou un solution antivirus de nouvelle génération pour détecter ce qui a réussi à passer.

Cette répartition des responsabilités revêt une importance bien plus grande qu’on ne le pense généralement. Une organisation peut appliquer strictement la politique DMARC tout en laissant ses utilisateurs exposés dès qu’ils cliquent sur un lien. Une autre peut investir massivement dans des outils de protection des terminaux, tandis qu’une douzaine de services tombés dans l’oubli restent autorisés à envoyer des e-mails considérés comme fiables depuis son domaine. La « dette de sécurité » liée aux e-mails se situe généralement dans l’écart entre ces deux situations.

Pourquoi cela apparaît-il rarement sur un tableau de bord ?

Il n'existe pas d'unité de mesure standard pour évaluer les risques liés à la sécurité des e-mails, ce qui rend leur évaluation beaucoup plus difficile que celle du taux de clics sur les e-mails de hameçonnage ou du temps moyen de résolution (MTTR).

Une présentation trimestrielle pourrait indiquer que 98 % des e-mails légitimes passent l’authentification. C’est rassurant… mais cela ne dit rien sur les quatre comptes SaaS abandonnés qui peuvent toujours envoyer des messages authentifiés. De même, atteindre p=reject sur votre domaine principal ne signifie pas pour autant que l’ensemble de votre environnement est sain. Les sous-domaines, les expéditeurs tiers et les les échecs DMARC non résolus ne sont pas pris en compte dans ce chiffre global.

Un tableau de bord plus fidèle à la réalité recense les éléments non résolus, et pas seulement ceux qui ont abouti :

• Expéditeurs non identifiés ;
• Services agréés sans propriétaire en activité ;
• Les échecs d'authentification n'ont toujours pas fait l'objet d'une enquête ;
• Les plateformes inactives sont toujours autorisées à envoyer ;
• Domaines restés en mode de surveillance au-delà d’une période convenue.

L'âge doit également figurer sur ce tableau de bord. Un expéditeur identifié hier fait l'objet d'une enquête. Le même expéditeur dont le cas n'est toujours pas résolu neuf mois plus tard représente une créance.

Attribuer un cycle de vie à chaque exception

Les programmes de sécurité des e-mails sont rarement bloqués par des problèmes majeurs. Ils sont plutôt ralentis par des exceptions temporaires, des feuilles de calcul obsolètes, des tickets abandonnés et des dossiers dont personne ne veut s'occuper car la responsabilité n'est pas clairement établie.

La solution n'a rien de spectaculaire : chaque exception liée à l'expéditeur ou à l'authentification non résolue se voit attribuer un responsable, une justification documentée et une date de révision. Ce simple changement permet de remettre en lumière une infrastructure qui avait été négligée.

Vous pouvez commencer par consulter ce qui a déjà été publié. Vérifiez votre configuration actuelle, passez votre domaine dans un outil d'analyse de domaine, puis utilisez les rapports DMARC pour comparer les envois autorisés à ceux qui sont réellement effectués.

Cet indicateur ne sera jamais parfaitement objectif, et ce n’est pas nécessaire. Son intérêt est d’ordre pratique. Les anciens expéditeurs, les enregistrements obsolètes, les déploiements DMARC inachevés et les lacunes entre la protection des e-mails et celle des terminaux cessent d’être considérés comme du bruit de fond pour devenir des tâches auxquelles vous pouvez accorder la priorité. C’est là tout l’intérêt de mettre un nom à la « dette de sécurité des e-mails » : ce qui est mesuré est planifié.

FAQ

Qu'est-ce que la « dette de sécurité » liée à la messagerie électronique ? La dette de sécurité des e-mails correspond à l’accumulation de problèmes non résolus liés à l’authentification, à la propriété et à la configuration au sein de l’infrastructure de messagerie d’une organisation : mécanismes d’ SPF s obsolètes, clés DKIM associées à des services inactifs, politiques DMARC bloquées en mode de surveillance, et expéditeurs tiers dont personne n’assume la responsabilité ni ne vérifie le contenu.

Comment mesure-t-on la dette de sécurité liée aux e-mails ? Suivez les éléments non résolus plutôt que ceux qui ont été traités avec succès : expéditeurs non identifiés, services autorisés sans propriétaire, échecs d'authentification non examinés, plateformes inactives toujours autorisées à envoyer des e-mails et domaines restés en mode de surveillance au-delà d'une date limite convenue. Ajoutez l'ancienneté de chaque élément, car c'est la durée pendant laquelle un problème reste non résolu qui distingue une enquête en cours d'une véritable dette.

Le fait d'atteindre le niveau DMARC p=reject signifie-t-il que vous n'avez plus de « dette de sécurité » en matière d'e-mails ? Non. L'application de cette politique sur votre domaine principal empêche l'usurpation directe de ce domaine, mais les sous-domaines, les services d'envoi tiers et les échecs d'authentification non résolus peuvent tous rester sans solution derrière un indicateur global satisfaisant.

• À propos de
• Derniers messages

Ahona Rudra

Expert en sécurité des domaines et des e-mails chez PowerDMARC

Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.

Derniers messages de Ahona Rudra (voir tous)

• E-mails de hameçonnage générés par l'IA : comment vérifier les e-mails rédigés par l'IA avant de leur accorder votre confiance - 31 août 2026
• La « dette de sécurité des e-mails » : l'indicateur de cybersécurité que personne ne mesure - 31 août 2026
• PowerDMARC désigné leader du marché des logiciels DMARC pour le 13e trimestre consécutif - 28 août 2026