Illustration représentant cinq icônes de messagerie électronique, dont cinq comportent un bouclier de sécurité et deux n'en comportent pas

Ce que révèlent 99 300 domaines sur l'authentification des e-mails et la résilience du DNS

Photo of Samuel Chenard
Catégories:

En résumé :

  • Les principaux fournisseurs de messagerie et les passerelles assurent la distribution des messages, mais ce sont les propriétaires de domaines qui sont en dernier ressort responsables de la configuration et de la maintenance des politiques DMARC visant à prévenir l'usurpation de domaine.
  • Une étude menée par Palisade portant sur 99 300 domaines a révélé que deux domaines sur cinq ne disposent pas de politique DMARC, et que plus d'un tiers des domaines dotés de DMARC restent en mode de surveillance passive au lieu d'appliquer des mesures de protection.
  • Plus de 20 % des domaines publiant des politiques DMARC omettent d'indiquer les adresses de rapport agrégées, ce qui prive les administrateurs de la visibilité nécessaire pour corriger les échecs d'authentification et passer à une application stricte de la politique.

Les entreprises considèrent souvent que le choix entre Microsoft 365, Google Workspace ou une passerelle de sécurité de messagerie constitue la principale décision à prendre pour protéger leur messagerie professionnelle. Ces services sont certes importants, mais ils ne suffisent pas à eux seuls.

La partie « domaine » d'une adresse e-mail est régie par le système de noms de domaine (DNS), et le propriétaire du domaine doit néanmoins publier une politique précisant la manière dont les systèmes destinataires traitent les messages dont l'authentification a échoué.

Cette politique s'appelle « Domain-based Message Authentication, Reporting, and Conformance » (DMARC).

DMARC relie le domaine indiqué dans la ligne « De » aux deux principaux mécanismes utilisés pour authentifier les e-mails : le Sender Policy Framework (SPF) et le DomainKeys Identified Mail (DKIM). En cas de non-conformité, une politique DMARC appliquée exige des destinataires participants qu’ils mettent le message en quarantaine ou le rejettent. En l’absence d’un enregistrement DMARC valide, les destinataires ne disposent d’aucune instruction de gestion DMARC de la part du propriétaire du domaine. Un malfaiteur peut toujours tenter de falsifier le domaine exact de l’organisation dans une facture, un avis de réinitialisation de mot de passe ou une demande émanant d’un dirigeant.

Afin d’évaluer l’étendue du déploiement de ce contrôle, mes collègues de Palisade ont analysé les enregistrements DNS publics d’un corpus fixe regroupant les 100 000 principaux domaines Web. Nous avons observé 99 300 domaines au cours d'une seule fenêtre d'analyse, le 14 août 2026, en résolvant les enregistrements DMARC, SPF, BIMI (Brand Indicators for Message Identification) et MX (Mail Exchange) via les mêmes résolveurs publics.

2 domaines sur 5 ne disposent d'aucune politique DMARC

Dans l'ensemble, les résultats ont été mitigés. Seuls 58,1 % des domaines observés publiaient une politique DMARC. Parmi ces émetteurs, 64,0 % demandaient aux destinataires de mettre en quarantaine ou de rejeter les messages non conformes. En d'autres termes, environ deux domaines observés sur cinq ne disposaient d'aucune politique DMARC, tandis que plus d'un tiers des émetteurs DMARC restaient en mode de surveillance.

Nous avons également comparé les domaines en fonction de l’infrastructure de messagerie entrante observée. Étant donné que les domaines les mieux classés peuvent présenter des profils de sécurité différents de ceux des domaines moins bien classés, nous avons harmonisé chaque groupe de fournisseurs selon la même répartition par tranche de classement. Après cet ajustement, le taux d’adoption de DMARC s’élevait à 89,4 % parmi les domaines Microsoft 365 observés et à 80,6 % parmi les domaines Google Workspace. Le taux d’application chez les émetteurs DMARC était respectivement de 68,3 % et 62,1 %. Les passerelles de messagerie reconnues affichaient un taux d’adoption de 94,7 % et un taux d’application de 76,0 %.

Diagramme à barres illustrant l'adoption et l'application du protocole DMARC par les opérateurs MX observés
Figure 1. Adoption et application de DMARC, ajustées en fonction du classement, chez les éditeurs DMARC, par opérateur MX observé. L’identifiant MX permet d’identifier l’infrastructure entrante observée et ne révèle pas nécessairement la plateforme de messagerie sous-jacente. Ces comparaisons sont de nature observationnelle et n’établissent pas de lien de causalité. Source : Palisade, « Observed MX provider benchmark 2026 », CC BY 4.0.

Il s’agit là de différences d’observation, et non de preuves indiquant que le choix d’un fournisseur particulier garantit une meilleure authentification. Un enregistrement MX indique où le courrier entrant semble être traité. Il ne révèle pas nécessairement la plateforme de messagerie sous-jacente, en particulier lorsqu’une passerelle se trouve en amont. Plus important encore, la politique DMARC relève toujours de la responsabilité du propriétaire du domaine. Le fait d’opter pour une plateforme de messagerie de premier plan ne garantit pas que cette politique soit publiée ou appliquée en toute sécurité.

Le déficit en matière de rapports pourrait être tout aussi important que le déficit en matière de politiques

DMARC permet d'envoyer des rapports agrégés au propriétaire du domaine, indiquant quels services envoient des e-mails via ce domaine et si ces messages sont conformes à celui-ci. Or, 20,7 % des émetteurs DMARC interrogés dans le cadre de cette étude ne disposaient d'aucune adresse de réception des rapports agrégés. Sans cette boucle de retour d'information, les opérateurs disposent de moins d'éléments pour identifier les expéditeurs oubliés, corriger les échecs d'authentification et passer en toute sécurité de la phase de surveillance à celle de mise en application.

Le SPF a une nouvelle fois rappelé que la résilience du courrier électronique dépend du bon fonctionnement du DNS. Parmi les domaines ayant publié des enregistrements SPF, 2,6 % ont connu des échecs de recherche récursive. Ces erreurs peuvent survenir lorsqu'un enregistrement dépend d'un trop grand nombre de services externes ou lorsqu'une de ces dépendances change. Une politique peut exister dans le DNS et néanmoins échouer lors de son évaluation.

La solution pratique ne consiste pas à rechercher à tout prix un score parfait pour les prestataires

Les propriétaires de domaines doivent tenir à jour une liste des expéditeurs légitimes, collecter les rapports DMARC, veiller à la conformité des records SPF et DKIM, et procéder de manière réfléchie à la mise en quarantaine ou au rejet des messages. Ils doivent également effectuer de nouveaux tests après toute modification du DNS ou de fournisseur, plutôt que de considérer l'authentification comme un projet ponctuel.

Les mesures publiques relatives au DNS offrent un aperçu utile du niveau de préparation, mais leur interprétation nécessite de définir des limites précises. Un enregistrement DNS ne prouve pas qu’une organisation ait été victime d’une attaque, qu’un fournisseur soit à l’origine du problème ou que chaque message soit sécurisé. Il indique toutefois si le propriétaire du domaine a publié une politique explicite, mis en place un canal de signalement et évité plusieurs erreurs de configuration courantes.

Le courrier électronique repose sur une infrastructure partagée, mais la responsabilité reste répartie. Les fournisseurs peuvent proposer des systèmes robustes ; les destinataires peuvent évaluer l'authentification ; les organismes de normalisation peuvent améliorer les protocoles. Le propriétaire du domaine doit toujours publier, surveiller et maintenir la politique. C'est cette dernière étape qui transforme un service de messagerie en une couche d'identité plus résiliente.

Samuel Chenard est PDG et cofondateur de Palisade, où il collabore avec des équipes informatiques et des prestataires de services gérés dans le domaine de l'authentification et de la délivrabilité des e-mails. Il dirige les travaux de recherche reproductibles de Palisade sur le DNS public, portant sur le déploiement des protocoles DMARC, SPF, BIMI et MX.

Les opinions exprimées par les auteurs de cet article de blog n'engagent qu'eux-mêmes et ne reflètent pas nécessairement celles de l'Internet Society.

Tags: