Analyseur de rapports DMARC

Déposez les fichiers de rapports agrégés que les destinataires vous envoient — .xml, .xml.gz ou un .zip qui en contient plusieurs — et récupérez ce que le XML enfouit : quelles sources envoient sous votre domaine, quelle part réussit l’alignement SPF et DKIM, ce qui a échoué aux deux et quoi corriger en premier, en langage clair. Tout est décompressé et analysé dans votre navigateur ; les fichiers ne quittent jamais votre navigateur, car un rapport DMARC est une carte de qui envoie votre courrier — et de qui fait semblant.

Ou déposez les fichiers n’importe où dans ce cadre. Les rapports de destinataires différents et de jours différents fusionnent en un seul tableau, groupés par source.

L’exemple est inventé : un expéditeur sain, un réexpéditeur, une plateforme marketing désalignée, une source inconnue qui échoue à tout.

Ce qu’est réellement un rapport agrégé

DMARC a deux moitiés. La première est l’enregistrement que vous publiez — politique, modes d’alignement, adresse de rapport — et c’est la moitié que tout vérificateur peut lire, y compris la vérification de délivrabilité des e-mails de ce site. La seconde moitié est la boucle de retour : chaque grand destinataire qui voit du courrier prétendant venir de votre domaine résume ce qu’il a vu et envoie le résumé à votre adresse rua, en général une fois par jour, en XML. Ce fichier est la seule preuve de qui d’autre envoie sous votre nom. Campagnes d’usurpation, plateforme marketing branchée par un collègue il y a deux ans, service de supervision qui utilise encore un serveur mis hors service — tout cela apparaît dans les rapports agrégés des semaines avant d’apparaître ailleurs, si quelqu’un les lit. Presque personne ne les lit, car le XML brut avec ses éléments policy_evaluated imbriqués est presque illisible, et les fichiers s’entassent compressés dans une boîte aux lettres. C’est le vide que comble cet analyseur : le même fichier, transformé en un tableau de sources et de verdicts, avec chaque échec traduit en la correction qu’il lui faut. Le guide associé, lire vos rapports DMARC, explique le vocabulaire du format — disposition, alignement, la différence entre un résultat d’authentification et un résultat aligné — avec un exemple entièrement traité.

Deux habitudes donnent plus de valeur aux rapports. D’abord, lisez-les avant d’appliquer la politique : une politique p=none avec rapports est un système de surveillance, et les semaines pendant lesquelles elle tourne vous apprennent chaque expéditeur légitime, de sorte que le passage en quarantaine puis en rejet ne casse rien de réel. Ensuite, traitez chaque source inconnue comme un ticket, pas comme une curiosité — identifiez-la, alignez-la ou regardez l’application la tuer —, mais ne laissez jamais un flux non reconnu dans le tas « probablement sans danger », car c’est exactement dans ce tas que se cache l’usurpation. Notez ce que les rapports agrégés ne contiennent délibérément pas : ni corps de message, ni objets, ni adresses de destinataires. Ce sont des comptages et des verdicts par source, et c’est pourquoi ils peuvent être partagés avec l’équipe d’assistance d’un fournisseur — comme un fichier que vous remettez délibérément, et non comme un téléversement vers un outil. Cette page conserve cette propriété : l’analyse a lieu là où le fichier se trouve déjà, sur votre machine.

Questions fréquentes

Qu’est-ce qu’un rapport agrégé DMARC ?

C’est le fichier de retour quotidien que les destinataires (Google, Microsoft, Yahoo et les autres) envoient à l’adresse de la balise rua de votre enregistrement DMARC. Pour chaque source qui a envoyé du courrier prétendant venir de votre domaine, le rapport liste l’IP source, le nombre de messages, la disposition appliquée par le destinataire et si SPF et DKIM étaient alignés avec votre domaine From. C’est le seul endroit où l’usurpation de votre domaine devient visible sous forme de données, plutôt que comme la plainte d’un client perplexe. Le guide lire vos rapports DMARC parcourt un vrai rapport ligne par ligne.

Comment obtenir ces rapports pour mon propre domaine ?

Publiez un enregistrement DMARC avec une adresse de rapport — v=DMARC1; p=none; rua=mailto:[email protected] — et les destinataires commenceront à envoyer sous un jour environ. Si vous n’avez pas encore d’enregistrement, ou si vous voulez vérifier celui que vous avez, lancez d’abord la vérification de délivrabilité des e-mails : elle lit l’enregistrement, la politique et si une adresse de rapport est publiée. Les rapports arrivent sous forme de petits fichiers XML, en général compressés en gzip ou regroupés dans un zip, ce qui est exactement ce que cet analyseur ouvre.

Est-il sûr d’ouvrir un rapport ici ? Où va le fichier ?

Nulle part. Le fichier est décompressé et analysé dans votre navigateur, dans cette page ; rien n’est téléversé, transmis ni stocké. C’est un choix délibéré, car les rapports agrégés sont une carte de votre infrastructure de messagerie — chaque service d’envoi que vous utilisez, chaque IP, et toute usurpation dirigée contre vous. Téléverser cette carte sur le serveur d’un inconnu, ou la coller dans un chat IA qui conserve des journaux, remet la carte à des personnes auxquelles elle n’a jamais été destinée.

Une source que je ne reconnais pas échoue à la fois en SPF et en DKIM. Est-ce de l’usurpation ?

C’est soit de l’usurpation, soit un expéditeur dont personne ne vous a parlé — et le rapport seul ne peut pas séparer les deux, c’est pourquoi l’analyseur le formule comme une question à élucider, pas comme un verdict. Travaillez dans l’ordre : l’IP appartient-elle à un fournisseur que votre organisation paie (un CRM, un service d’assistance, un vieil outil marketing, un service de supervision oublié) ? Le volume est-il stable et faible (un système interne mal configuré) ou en rafales et élevé (une campagne) ? Tant que votre politique est p=none, ce courrier est livré de toute façon ; une fois chaque source légitime alignée et la quarantaine ou le rejet appliqués, le flux non reconnu sera refusé, qu’il ait été l’un ou l’autre.

Mon propre courrier légitime échoue. Que corriger en premier ?

L’alignement, presque toujours chez le fournisseur. SPF ne s’aligne pas quand le fournisseur envoie depuis son propre domaine de rebond — corrigez-le avec un sous-domaine personnalisé de chemin de retour, pour que le domaine d’enveloppe soit le vôtre. DKIM ne s’aligne pas quand le fournisseur signe avec son propre domaine ou ne signe pas du tout — corrigez-le en activant la signature DKIM avec votre domaine dans les réglages du fournisseur. Un seul mécanisme aligné suffit pour réussir DMARC, mais DKIM est le plus robuste des deux car il survit à la réexpédition. Corrigez les expéditeurs par ordre de volume, regardez les rapports suivants devenir propres, et seulement alors renforcez la politique.