Comment des rapports DMARC défectueux révèlent la structure de votre infrastructure

Informations sur la sécuritéConseils techniques

Un rapport agrégé DMARC répertorie tous les serveurs ayant envoyé des e-mails via votre domaine, le volume envoyé et si ces e-mails ont satisfait aux validations SPF et DKIM. L'adresse de destination de ces rapports est généralement définie une seule fois, dans la balise « rua », puis n'est plus jamais vérifiée. Si cette adresse comporte une faute de frappe ou appartient à un domaine dont l'entreprise n'est plus propriétaire, les rapports sont envoyés à la personne qui a enregistré ce domaine.

Ce guide présente trois cas courants dans lesquels une adresse de rapport erronée se retrouve dans l'enregistrement DMARC d'une entreprise, ce que ces rapports révèlent, et comment vérifier vos propres enregistrements. Les exemples présentés dans ce guide sont tirés des recherches menées par SH Consulting sur les domaines de rapport mal saisis ou périmés. Dans chaque cas, SH Consulting a informé l’organisation concernée, n’a pas utilisé les données et a soit restitué le domaine, soit configuré celui-ci pour qu’il rejette tous les e-mails. Après la présentation de ces exemples par SH Consulting, Ash Morin apporte son point de vue sur ce que dmarcian observe du côté des fournisseurs.

Comment les terminaux de reporting tombent en panne

Les trois échecs ci-dessous ont un point commun : un point de terminaison de signalement figurant dans un enregistrement DMARC de production dont personne au sein de l'entreprise ne peut expliquer l'origine. Et dans la plupart des cas, cela n'a rien à voir avec le fournisseur DMARC auquel l'entreprise fait appel.

Une faute de frappe dans l'adresse

Les fournisseurs DMARC attribuent généralement à chaque client une adresse de rapport sur un sous-domaine. Un enregistrement pointant vers « dmarcian » se présente à peu près comme suit :

v=DMARC1; p=reject; rua=mailto:[email protected]

Une fois retapé au lieu d'être copié-collé, ce même enregistrement pourrait se présenter comme suit :

v=DMARC1; p=reject; rua=mailto:[email protected]

Il manque un point avant « dmarcian.com », ce qui signifie que l'enregistrement pointe vers « agdmarcian.com », un domaine totalement distinct de « dmarcian.com ». Un domaine de ce type est généralement libre d’enregistrement pour tout le monde. Si personne ne l’a enregistré, les rapports seront rejetés et le tableau de bord restera inactif. Si quelqu’un l’a enregistré, c’est cette personne qui recevra ces rapports. L’enregistrement mal saisi passe tout de même le contrôle syntaxique, car il ne contient aucune erreur de format. Cela signifie que tout validateur DMARC actuellement en service indiquera qu’il s’agit d’un enregistrement DMARC valide.

Au cours de ses recherches, SH Consulting a constaté que les noms de domaine agdmarcian.com et frdmarcian.com étaient disponibles à l'enregistrement ; l'entreprise les a donc enregistrés, puis les a transférés à dmarcian. Ash explique ci-dessous comment dmarcian les gère.

La même chose peut se produire avec le domaine propre à une entreprise. Adva Network Security, un éditeur allemand de solutions de sécurité, a publié des adresses de signalement sur advasecurtiy.com, une faute d’orthographe de advasecurity.com. Ce domaine, dans lequel deux lettres avaient été interverties, n’était pas encore enregistré. SH Consulting a signalé cette faute d’orthographe, puis a enregistré le domaine à titre préventif et bloqué tous les e-mails qui y étaient adressés.

Un ancien nom de domaine de l'entreprise dont l'enregistrement a expiré

Les changements de marque, les fusions et les acquisitions laissent derrière eux d’anciens noms de domaine. Les comptes auprès des bureaux d’enregistrement sont souvent liés à l’adresse e-mail d’un responsable informatique ; ainsi, lorsque ce dernier quitte l’entreprise, les noms de domaine expirent en même temps que lui. Il arrive également que la carte bancaire associée au compte expire sans que personne ne s’en aperçoive, car les notifications sont envoyées à une adresse e-mail qui n’existe plus au sein de l’entreprise. Dans tous les cas, personne ne vérifie si le DNS contient encore des entrées pointant vers ce nom.

JE Pistons et Wiseco illustrent parfaitement ce phénomène. Ces deux marques appartenaient autrefois à une société mère, plus précisément à une division dédiée au sport automobile de Dover Corporation, qui utilisait le domaine doverpmi.com. Suite à un changement de propriétaire, ce domaine a expiré, mais les enregistrements DMARC des deux marques continuaient d’y envoyer des rapports. SH Consulting a enregistré le domaine au cours de ses recherches, et des rapports quotidiens concernant ces deux marques, toujours en activité, ont commencé à lui parvenir. Des e-mails continuaient également d’être envoyés à d’anciens employés ; le domaine a donc été configuré pour rejeter tous les e-mails entrants. L’une des deux marques a depuis supprimé cette adresse, tandis que l’autre continue d’envoyer ses rapports DMARC vers ce domaine.

Une adresse ajoutée par un prestataire informatique externe

Toutes les adresses figurant dans un enregistrement DMARC n'appartiennent pas nécessairement à un fournisseur DMARC. Les prestataires informatiques et les services de filtrage des spams ajoutent parfois leur propre domaine à l'enregistrement d'un client, et celui-ci y reste même après la cessation du service.

C’est ce qui s’est produit à Eden Park, le stade national néo-zélandais. Son enregistrement DMARC mentionnait deux adresses de signalement : l’une appartenait à un fournisseur DMARC et fonctionnait comme prévu. L’autre se trouvait sur spamcontrol.co.nz, le domaine d’un service de filtrage des spams que Fujitsu a mis hors service en juin 2021. Le domaine a expiré à un moment donné, mais l’adresse est restée dans l’enregistrement d’Eden Park pendant des années. SH Consulting a enregistré le domaine au cours de ses recherches et a reçu environ un an de rapports provenant du stade. Eden Park a supprimé l’adresse en août 2026, et le domaine a depuis été transféré à Fujitsu.

Pourquoi personne ne s'en rend compte ?

Ces erreurs peuvent rester dans le DNS pendant des années, car elles n'entraînent aucun dysfonctionnement visible. Le courrier continue d'être acheminé et DMARC continue de protéger le domaine. Si l'enregistrement mentionne également un deuxième point de rapport, le tableau de bord du fournisseur continue lui aussi de s'encombrer. La seule façon de détecter le problème est de consulter l'enregistrement lui-même.

Une autre raison à cela est que de nombreuses organisations n’ont pas de prestataire DMARC. Leur enregistrement ne répertorie que leur propre boîte mail, et les rapports y parviennent sous forme de fichiers XML. Ce sont probablement les e-mails les moins lus qu’une entreprise reçoive, puisque personne ne lit le XML manuellement pour vérifier la sécurité. Lorsque les rapports cessent d’arriver, personne ne s’en aperçoit, surtout s’ils n’ont jamais été analysés pour être transformés en mises à jour régulières destinées à l’équipe. C’est là l’argument le plus convaincant en faveur d’une surveillance DMARC assurée par un tiers : la responsabilité incombe alors à quelqu’un qui comprend réellement ces données.

Quels sont les risques ?

Un rapport agrégé se présente sous la forme d’un fichier XML comportant une ligne par adresse IP d’envoi : l’adresse, le nombre de messages, les résultats SPF et DKIM, ainsi que les domaines utilisés lors de chaque vérification. En consultant ces rapports sur un mois, vous saurez quelles plateformes de messagerie, quels CRM, quels services d’assistance et quels systèmes de facturation envoient des e-mails pour un domaine donné. Vous connaîtrez également les volumes, les sous-domaines utilisés et les flux qui échouent à l’authentification.

La plupart des gens pensent que les rapports agrégés ne concernent que leurs propres expéditeurs, mais ces rapports contiennent davantage d’informations qu’on ne le croit généralement. Certains destinataires, comme Microsoft, incluent un champ facultatif « envelope_to » contenant le domaine du destinataire. Les rapports qui comportent ce champ indiquent également à qui l’entreprise envoie des e-mails : clients, distributeurs et partenaires, classés par domaine et par volume. 

Les rapports d'échec envoyés à une adresse ruf vont encore plus loin. Ils peuvent inclure les en-têtes des messages individuels, et parfois leur contenu. De nombreux grands fournisseurs de messagerie n'envoient plus de rapports d'échec, mais plusieurs dizaines de destinataires continuent de le faire.

Pour un pirate, cela constitue une liste toute prête des services tiers autorisés à envoyer des e-mails pour un domaine donné, ainsi que des points où l’authentification est faible, voire inexistante. Chacun de ces services représente une cible de grande valeur. Si un pirate parvient à prendre le contrôle du compte de l’entreprise sur l’un de ces services, qui ne sont souvent protégés que par un mot de passe (sans SSO ni MFA), il peut alors envoyer des e-mails qui passeront l’authentification.

Lorsque les rapports mentionnent les domaines des destinataires, ils constituent également des listes des clients, partenaires et fournisseurs avec lesquels l’organisation traite, chacun d’entre eux représentant une cible facile pour le hameçonnage. Les volumes, les jours d’envoi et les plateformes utilisés permettent de se faire une idée du contenu habituel des e-mails de l’entreprise, ce qui facilite l’usurpation d’identité de la marque auprès de ces contacts. Tout cela évite à un pirate de devoir effectuer un travail de reconnaissance.

Il existe deux types de protection sur lesquels les gens comptent souvent, mais qui ne sont d'aucune utilité dans ce cas précis :

• p=reject. Cette politique indique aux destinataires comment traiter les e-mails qui échouent. Elle n'a aucun effet sur la génération de rapports ; ainsi, un domaine où cette politique est pleinement appliquée présente exactement le même niveau de fuites qu'un domaine utilisant la valeur « p=none ».
  
• Vérification de la destination externe. Avant d'envoyer des rapports vers un autre domaine, le destinataire vérifie que ce domaine a bien publié un enregistrement DNS autorisant leur réception. Toute personne ayant enregistré ce domaine, qu'il s'agisse d'une faute de frappe ou d'un domaine expiré, contrôle son DNS et peut publier cet enregistrement en une minute.

Point de vue du fournisseur : Ash Morin, directeur des services professionnels chez dmarcian

Du côté des fournisseurs, ce problème est rare. Parmi tous les domaines surveillés par dmarcian, un seul publie actuellement une adresse de rapport dmarcian mal orthographiée, et le domaine vers lequel elle pointe est désormais le nôtre. Mais un seul suffit : si quelqu’un d’autre avait enregistré ce domaine, ces rapports lui auraient été directement envoyés.

dmarcian conservera indéfiniment les noms de domaine agdmarcian.com et frdmarcian.com. Même une fois que toutes les entrées pointant vers notre site auront été corrigées, une erreur qui s'est produite une fois peut se reproduire, et nous préférons ne laisser aucune faille. Si d'autres domaines contenant des fautes de frappe apparaissent, nous procéderons de la même manière.

Cependant, le fait de posséder des domaines ne couvre que les fautes de frappe dont nous avons connaissance. Aucun fournisseur ne peut enregistrer toutes les fautes d’orthographe possibles de son propre nom ; c’est pourquoi l’essentiel du travail consiste à prévenir ces erreurs. Il y a quelques années, nous avons mis en place des adresses de rapport spécifiques à chaque région, telles que ag.us.dmarcian.com, que nos clients ont tendance à moins souvent mal saisir. Notre processus d’intégration guide les clients pour qu’ils publient correctement leur enregistrement, et nous vérifions les adresses rua et ruf sur les domaines de nos clients afin de nous assurer qu’elles pointent bien vers la destination prévue.

Ces audits ne portent que sur les noms de domaine enregistrés dans notre système. Lorsqu'un client clôture son compte, il peut arriver qu'il ne mette pas à jour son enregistrement DNS pour diverses raisons. À ce stade, nous n'avons plus aucun moyen d'en assurer le suivi. Lorsque vous quittez un fournisseur, supprimez son adresse de notification. Ne la laissez pas en place.

On pense souvent que les données DMARC sont inoffensives, car les rapports agrégés contiennent peu d’informations personnelles. C’est passer à côté de l’essentiel. Le risque ne réside pas dans une ligne en particulier, mais dans la tendance qui se dégage. Au cours des dernières années, j’ai travaillé sur plus de 100 déploiements DMARC. Chacun d’entre eux comportait au moins un service tiers dont les identifiants de connexion n’étaient pas protégés par l’authentification multifactorielle (MFA) ou l’authentification unique (SSO). Il s’agit souvent d’outils mis en place par des personnes extérieures au service informatique et dont personne ne suivait l’évolution. Ce sont précisément ces comptes qu’un pirate consultant vos rapports ciblerait en premier lieu.

Comment effectuer un audit de vos points de collecte de données

1. Répertoriez toutes les adresses « rua » et « ruf » de chaque domaine et sous-domaine dont vous êtes propriétaire. N'oubliez pas d'inclure les domaines parqués ainsi que tous les domaines qui héritent d'un enregistrement partagé via un CNAME.
   
2. Vérifiez que chaque domaine est bien enregistré et identifiez son propriétaire. Si vous ne pouvez pas identifier le propriétaire ni la raison pour laquelle cette adresse figure dans les enregistrements, considérez-la comme non valide. L'outil gratuit « Dangling DNS Check » de SH Consulting signale les domaines non enregistrés présents dans les enregistrements DMARC et SPF.
   
3. Vérifiez les adresses des fournisseurs caractère par caractère en les comparant à la documentation fournie par ces derniers. Commencez par rechercher les points manquants.
   
4. Supprimez les adresses que personne ne consulte : il s'agit notamment des services que vous n'utilisez plus, des anciennes agences ou prestataires informatiques, ainsi que des anciens noms de domaine de votre entreprise.
   
5. Vérifiez votre DNS avant l'expiration d'un nom de domaine. Si un enregistrement pointe encore vers celui-ci, corrigez-le avant l'expiration du nom de domaine ou maintenez l'enregistrement du nom de domaine.

Réalisez ce processus d'audit au moins une fois par an, ainsi qu'à chaque fois que vous changez de fournisseur, que vous procédez à un changement d'image de marque ou que vous acquérez une entreprise.

---

Alex Shakhov, coauteur de cet article, est le fondateur de SH Consulting, un cabinet de conseil spécialisé dans la délivrabilité et la sécurité des e-mails. Son équipe résout les problèmes liés à l'acheminement vers la boîte de réception, aux listes noires et à l'authentification pour des expéditeurs allant des start-ups aux plateformes de messagerie multi-locataires.

Nous sommes là pour vous aider
Avec une équipe d'experts en sécurité e-mail et une mission visant à rendre l'e-mail et Internet plus fiables grâce à la sécurité des domaines, dmarcian est là pour aider à évaluer le catalogue de domaines d'une organisation, et à implémenter et gérer DMARC sur le long terme.

---

Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.