Outil gratuit

Analyseur de rapports DMARC gratuit

Name: Analyseur de rapports DMARC
Author: DMARCTrust

Déposez un rapport agrégé et cet analyseur DMARC transforme le XML brut en un résumé lisible : IP sources, résultats SPF et DKIM, alignement et l'action prise par chaque destinataire. Il utilise le même analyseur open source que nous employons pour lire les vrais rapports de nos clients. Votre rapport ne quitte jamais votre navigateur.

Déposez votre rapport DMARC ici

ou cliquez pour sélectionner un fichier

Analyser le rapport

Supporte les fichiers .xml, .xml.gz et .zip

Prêt à analyser

Analyse du rapport

Messages totaux

Taux de réussite DMARC

SPF

Réussi Échoué

DKIM

Réussi Échoué

Disposition des messages

Aucune (délivré)

Quarantaine

Rejet

Informations du rapport

Émetteur du rapport
Période du rapport
Domaine signalé

Votre politique DMARC

Politique (p)
Politique sous-domaine (sp)
Politique sous-domaines inexistants (np)
Pourcentage (pct)
Mode test (t)
Méthode de découverte
Alignement DKIM
Alignement SPF

Principales sources d'envoi

IP source	Messages	Réussi	Échoué	Méthodes auth.

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

Un rapport DMARC agrégé, aussi appelé rapport rua, est un fichier XML qu'un destinataire d'emails comme Gmail, Microsoft ou Yahoo vous envoie environ une fois par jour pour chacun de vos domaines. Il résume les messages prétendant provenir de votre domaine ce jour-là : quelles adresses IP les ont envoyés, si SPF et DKIM ont réussi et étaient alignés, et ce que le destinataire a fait des emails ayant échoué. Le format est né à l'annexe C de la RFC 7489. La RFC 9989 (DMARCbis) remplace désormais la RFC 7489 comme norme principale, et la RFC 9990 spécifie le schéma du rapport agrégé : pct a quitté l'enregistrement, et les éléments np, testing et discovery_method ont été ajoutés.

Il existe deux types de rapports DMARC, et cet analyseur en lit un seul. Les rapports agrégés (rua) sont les résumés XML statistiques quotidiens décrits ci-dessus. Ils portent des comptes, pas le contenu des messages. Les rapports d'échec (ruf), anciennement appelés rapports forensiques et désormais spécifiés par la RFC 9991, sont un format distinct, par message, envoyé dès qu'un message échoue. Cet outil analyse les rapports agrégés, ce que presque tous les destinataires envoient et ce dont vous avez besoin pour voir comment votre domaine est utilisé.

DMARCbis, publié en mai 2026, a remanié cet ensemble à travers les RFC 9989, 9990 et 9991. Notre guide DMARCbis détaille ce qui a changé.

Comment lire un rapport DMARC, champ par champ

Chaque rapport agrégé est un élément <feedback> en trois parties : qui a envoyé le rapport, la politique que vous avez publiée, et un enregistrement par groupe de messages au même résultat. Voici ce que signifie chaque champ, dans l'ordre où l'analyseur ci-dessus les lit.

<report_metadata>, qui a envoyé ce rapport et quand

org_name: Le destinataire qui a généré le rapport, par exemple google.com.
email: La boîte de réception émettrice chez ce destinataire.
report_id: Un identifiant unique de ce rapport. Utilisez-le pour dédupliquer si vous stockez vos rapports vous-même.
date_range / begin, end: La fenêtre de 24 heures couverte par le rapport, en secondes Unix (epoch). L'analyseur les convertit en dates lisibles pour vous.

<policy_published>, la politique DMARC active ce jour-là

domain: Le domaine auquel s'applique la politique.
p: Votre politique principale : none, quarantine ou reject. C'est l'évaluation que vous publiez pour les emails qui échouent à DMARC.
sp: La politique pour les sous-domaines, si vous en avez défini une.
np: La politique pour les sous-domaines inexistants. La RFC 9989 (DMARCbis) a ajouté le tag np à l'enregistrement, et la RFC 9990 en transporte la valeur comme élément du rapport. L'analyseur ne l'affiche que s'il est présent.
pct: Le pourcentage d'emails en échec auquel s'applique la politique. La RFC 9989 a retiré pct de l'enregistrement DMARC au profit du tag t (mode test), donc l'analyseur n'affiche pct que lorsqu'un rapport hérité le porte encore, et n'invente jamais de valeur par défaut.
adkim / aspf: Mode d'alignement DKIM et SPF : r pour relaxed (les domaines organisationnels doivent correspondre), s pour strict (les domaines complets doivent correspondre).
testing: L'élément du rapport qui transporte la valeur du tag t (mode test) de la RFC 9989. Quand il vaut yes, le destinataire évalue DMARC mais ne l'applique pas, ce qui vous permet d'observer avant d'activer la politique. Les rapports continuent d'arriver pendant le test.
discovery_method: Un champ de rapport de la RFC 9990 qui indique comment le destinataire a trouvé votre politique : psl (Public Suffix List) ou treewalk (le nouveau DNS Tree Walk).

<record>, une ligne par groupe de messages au même résultat

Chaque enregistrement comporte quatre blocs enfants. Les deux premiers portent le verdict ; les deux derniers portent les preuves.

row / source_ip, count: L'adresse IP qui a envoyé les emails et combien de messages elle a envoyés dans ce groupe. count est le nombre par lequel vous multipliez tout le reste.
policy_evaluated / disposition: Ce que le destinataire a réellement fait : none signifie délivré, quarantine signifie dirigé vers les spams, reject signifie bloqué.
policy_evaluated / dkim, spf: Le verdict DMARC que le destinataire a déjà calculé pour chaque mécanisme, pass ou fail, après alignement. C'est le résultat qui décide si DMARC a réussi.
identifiers / header_from: Le domaine présent dans l'en-tête From visible, l'adresse que DMARC protège.
auth_results / dkim, spf: La vérification SPF et DKIM brute (domaine, sélecteur, résultat) avant l'application de l'alignement. C'est là que vous diagnostiquez pourquoi un verdict est tel qu'il est. Avec la RFC 9990, le sélecteur DKIM est requis dès qu'une signature DKIM est rapportée.

Pour la signification de chaque tag dans la politique que vous publiez (les valeurs p, sp, adkim, aspf ci-dessus), consultez notre guide des tags DMARC, ou construisez un enregistrement avec le générateur d'enregistrement DMARC.

Exemple concret : un vrai rapport, décodé

Voici un rapport sain lu ligne par ligne. C'est un échantillon synthétique (les IP et l'identifiant de rapport ne sont pas réels), mais c'est exactement la forme que Google envoie. Déposez-le dans l'analyseur ci-dessus et vous obtenez le résumé ci-dessous.

Un rapport d'exemple tronqué (un des deux enregistrements affiché) :

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>14987236590123456789</report_id>
    <date_range><begin>1717200000</begin><end>1717286400</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>reject</p><sp>reject</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.41</source_ip>
      <count>128</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
  </record>
</feedback>

Lecture en clair

google.com a envoyé ce rapport pour example.com, couvrant une journée.
La politique publiée est p=reject avec un alignement relaxed (adkim=r, aspf=r).
Enregistrement un : 198.51.100.41 a envoyé 128 messages. DKIM et SPF ont tous deux réussi et étaient alignés, donc DMARC a réussi.
Enregistrement deux (non affiché ci-dessus) : 198.51.100.12 a envoyé 47 messages, eux aussi tous réussis.
Total : 128 + 47 = 175 messages, un taux de réussite DMARC de 100%.

Remarquez que chaque disposition est none alors même que la politique est p=reject. C'est correct, pas une contradiction. p=reject est l'évaluation qu'un destinataire applique aux emails qui échouent à DMARC. Tous les messages ici ont réussi, donc le destinataire n'avait aucune raison d'agir et les a délivrés normalement.

Une tentative d'usurpation a une autre allure. Vous verriez un source_ip inconnu avec dkim=fail et spf=fail dans policy_evaluated, et comme la politique est reject, sa disposition afficherait généralement reject. Cette ligne, c'est un email que quelqu'un a envoyé au nom de votre domaine et que le destinataire a bloqué. Ce sont les lignes à surveiller.

policy_evaluated vs auth_results, ce que la plupart des outils ratent

Un rapport porte le résultat SPF et DKIM deux fois, et les deux ne sont pas la même chose. Dans auth_results, vous avez la vérification brute : SPF a-t-il autorisé l'IP émettrice, la signature DKIM a-t-elle été validée. Dans policy_evaluated, vous avez le verdict DMARC : le destinataire a pris ce résultat brut et a aussi vérifié si le domaine authentifié s'aligne avec le domaine de l'en-tête From visible. DMARC réussit quand SPF ou DKIM réussit et s'aligne avec ce domaine From.

C'est pourquoi un SPF brut peut afficher pass alors que DMARC échoue. Un message envoyé via un redirecteur ou un hébergeur d'emails de masse non configuré peut réussir le SPF simple sur le propre domaine de l'hébergeur, et pourtant échouer à DMARC parce que ce domaine n'est pas aligné avec le vôtre. Le verdict aligné dans policy_evaluated est celui qui décide du traitement, c'est donc le nombre que compte cet analyseur.

Nous sommes précis sur ce que fait l'outil : il rapporte le verdict aligné que le destinataire a déjà calculé dans policy_evaluated. Il ne refait pas l'alignement sur vos résultats bruts. Cela correspond à la RFC 7489 Section 7.2 (reprise dans la RFC 9989), où c'est le destinataire qui évalue l'alignement des identifiants, pas le lecteur de rapport.

Pourquoi utiliser un analyseur de rapports DMARC ?

Vérifier vos sources d'envoi

Identifiez quelles adresses IP envoient des emails au nom de votre domaine, et si elles y sont autorisées.

Surveiller SPF et DKIM

Suivez les taux de réussite pour que vos vrais emails restent authentifiés à mesure que vous avancez vers p=reject.

Détecter l'usurpation

Repérez les expéditeurs inconnus qui tentent d'envoyer des emails au nom de votre domaine, et confirmez que votre politique fait son travail.

100% dans votre navigateur, rien n'est téléversé

Votre rapport ne quitte jamais votre machine. L'analyseur lit le fichier avec le DOMParser intégré à votre navigateur et décompresse les archives .gz et .zip en mémoire avec fflate. Pas de téléversement, pas d'aller-retour serveur, pas de journalisation. L'analyseur ne fait aucun appel réseau, ce que vous pouvez vérifier vous-même : il est open source sous licence MIT. C'est la différence entre cet outil et les analyseurs qui vous demandent d'abord de téléverser un rapport sur leurs serveurs.

Vous souhaitez une surveillance DMARC automatisée ?

Lire un rapport à la main, c'est faisable. De nouveaux rapports arrivent chaque jour de chaque destinataire, et cela ne tient pas à l'échelle. DMARCTrust les collecte, les analyse et les suit pour vous automatiquement, avec ce même analyseur côté serveur.

Démarrer la surveillance gratuite Créer un enregistrement DMARC Créer un enregistrement SPF

Open source et auto-hébergeable

Le moteur de cet analyseur est open source sous licence MIT, et c'est le même analyseur qui lit les vrais rapports de nos clients. Il fonctionne entièrement dans votre navigateur : vos rapports ne quittent jamais votre machine. Consultez le code, hébergez-le sur votre propre infrastructure ou proposez une pull request.

Voir sur GitHub

Questions fréquentes

Mes données de rapport DMARC sont-elles sécurisées ?

Oui. L'analyseur fonctionne entièrement dans votre navigateur. Votre rapport est lu localement avec le DOMParser intégré et n'est jamais téléversé, enregistré ni envoyé à un serveur.

Quels formats de fichiers puis-je analyser ?

.xml brut, .xml.gz ou .gz compressés en gzip, et archives .zip. Dans un .zip, le premier fichier XML est utilisé. La taille maximale est de 10 Mo, bien supérieure à tout rapport agrégé réel.

Que contient un rapport DMARC agrégé ?

Un résumé quotidien des emails prétendant provenir de votre domaine : l'hébergeur d'emails émetteur et la période, la politique que vous avez publiée, et un enregistrement par groupe de messages au même résultat, chacun portant l'IP source, le nombre de messages, les verdicts SPF et DKIM, et la disposition appliquée par le destinataire.

Comment ouvrir un rapport DMARC .gz ou .zip ?

Déposez le fichier directement sur l'analyseur tel qu'il est arrivé dans votre boîte de réception. Il décompresse automatiquement les .gz et .zip dans votre navigateur, vous n'avez donc pas besoin de le décompresser au préalable.

Pourquoi la disposition est-elle none alors que ma politique est reject ?

Parce que p=reject est l'évaluation qu'un destinataire applique uniquement aux emails qui échouent à DMARC. Un message qui a réussi SPF ou DKIM et qui est aligné réussit à DMARC, donc le destinataire le délivre et enregistre la disposition none. Vous ne voyez reject que sur les lignes qui ont réellement échoué.

Quelle est la différence entre rapports agrégés et rapports d'échec ?

Les rapports agrégés (rua) sont des résumés XML statistiques quotidiens avec des comptes, pas le contenu des messages. Les rapports d'échec (ruf), anciennement appelés rapports forensiques et désormais spécifiés par la RFC 9991, sont un format distinct, par message. Cet analyseur lit les rapports agrégés, ce que presque tous les destinataires envoient.

Pourquoi SPF réussit-il dans auth_results alors que DMARC échoue ?

auth_results contient la vérification SPF brute, qui peut réussir sur le propre domaine d'un hébergeur d'emails. DMARC exige aussi l'alignement avec le domaine de votre en-tête From. Si le domaine qui réussit n'est pas aligné avec le vôtre, DMARC échoue. Le verdict aligné dans policy_evaluated est celui qui compte.

À quelle fréquence les destinataires envoient-ils des rapports DMARC ?

En général une fois par jour et par domaine pour chaque destinataire, par exemple un rapport quotidien de Google et un de Microsoft. DMARCbis (RFC 9989 §8) recommande désormais un intervalle quotidien et a supprimé l'ancien tag ri, même si un destinataire peut en envoyer plus ou moins souvent. Comme des rapports arrivent chaque jour de chaque destinataire, les lire à la main cesse vite d'être tenable, et c'est ce que résout la surveillance automatisée.

Protégez la réputation de vos emails

La surveillance DMARC n'a pas à être compliquée. Laissez-nous gérer les détails techniques pendant que vous vous concentrez sur votre activité.

Démarrer la surveillance Voir les tarifs