Analyse de rapports DMARC
Collez un rapport DMARC agrégé (RUA) ou déposez le .xml, .gz ou .zip reçu. Tout est analysé dans votre navigateur. Le fichier n’est jamais envoyé.
Ce que dit vraiment un rapport DMARC
Chaque destinataire qui reçoit des e-mails se réclamant de votre domaine peut renvoyer un rapport agrégé quotidien : la liste des IP d’envoi, le nombre de messages de chacune, l’alignement ou non de SPF et DKIM sur votre domaine From, et l’action du destinataire. Lus ensemble, ces rapports dressent l’inventaire complet de qui envoie en votre nom, y compris les services oubliés et les usurpateurs.
Le hic, c’est le format. Les rapports arrivent en XML compressé, un par destinataire et par jour : une semaine d’e-mails sur quelques domaines, ce sont des centaines de fichiers. En lire un à la main est faisable ; les suivre tous ne l’est pas, d’où une plateforme de surveillance ou un outil auto-hébergé comme parsedmarc. Cet outil couvre l’entre-deux : un rapport, ouvert maintenant, lisible en quelques secondes, sans confier vos données d’envoi à personne.
Lire un rapport XML DMARC, preuve par preuve
| Preuve | Ce qu’elle indique | Quoi en faire |
|---|---|---|
| Métadonnées | L’organisation émettrice, l’ID du rapport et la plage de dates UTC indiquent qui a produit le fichier et sur quelle période. | Vérifiez la plage de dates et gardez l’ID pour comparer des fichiers en double ou en retard. |
| Politique publiée | Le rapport note la politique DMARC trouvée par le destinataire, modes d’alignement et sous-domaines compris. | Comparez-la à l’enregistrement public actuel avant de supposer que ce résultat passé reflète la politique du jour. |
| IP source et volume | Chaque ligne regroupe les messages par source et donne le nombre observé sur la période. | Traitez d’abord les sources inconnues ou en échec à fort volume, puis trouvez leur service avant tout changement. |
| Alignement DMARC | La ligne évaluée montre si SPF et DKIM étaient alignés et quelle disposition le destinataire a appliquée. | Un SPF valide et aligné, ou un DKIM valide et aligné, suffit pour réussir DMARC. |
| Authentification sous-jacente | Les résultats auth montrent les domaines et sélecteurs SPF et DKIM sous la décision DMARC résumée. | Servez-vous-en pour retrouver l’expéditeur exact ; un SPF valide non aligné ne vaut pas un DMARC réussi. |
Pourquoi disposition et politique peuvent différer
La disposition est l’action notée par le destinataire pour cette ligne. Elle peut différer de la politique publiée si le message a réussi DMARC, si le destinataire a appliqué sa propre règle ou si le rapport couvre une ancienne politique. Le XML est une preuve du destinataire, pas un journal de messages ni la preuve qu’une IP inconnue est malveillante.
D’un fichier XML au suivi continu
Un rapport suffit pour enquêter sur une source ou valider la structure du fichier. Pas pour inventorier chaque expéditeur légitime ni juger un passage à l’application. Couvrez un cycle d’envoi complet, regroupez une même source entre destinataires et confirmez les flux importants avec de vrais en-têtes avant de changer la politique. Utilisez le test DMARC pour vérifier l’enregistrement public du rapport.
Pour aller plus loin
Base de connaissances e-mail
Qu’est-ce qu’un analyseur de rapports DMARC ?
C’est un lecteur des rapports agrégés (RUA) que les serveurs destinataires renvoient sur votre domaine. Ils arrivent en XML compressé (un par organisation et par jour) et listent chaque IP qui a envoyé en votre nom, son nombre de messages et l’alignement de SPF et DKIM. L’analyseur rend cela lisible : quels services envoient avec votre domaine, lesquels échouent à l’authentification et ce qu’en a fait le destinataire.
Cet analyseur est-il gratuit ?
Oui, sans compte ni limite. Il tourne entièrement dans votre navigateur (aucun envoi, aucun serveur), il n’y a donc rien à compter.
Envoyer un rapport DMARC à un analyseur en ligne est-il sûr ?
Un rapport DMARC contient vos IP d’envoi, vos volumes et les services qui envoient pour vous : des informations utiles à un concurrent ou à un attaquant, mieux vaut savoir où elles vont. Cet outil lit le fichier localement dans votre navigateur : rien n’est envoyé, journalisé ni stocké, ce que confirme l’onglet réseau de votre navigateur pendant l’analyse. La plupart des analyseurs en ligne envoient le fichier : vérifiez avant de coller.
Comment recevoir mes rapports ?
Les rapports partent à l’adresse de la balise rua de votre enregistrement DMARC, par exemple rua=mailto:dmarc@yourdomain.com. Les destinataires les envoient chaque jour, en pièces jointes .zip ou .gz contenant du XML. Sans balise rua, vous n’en recevez aucun : en ajouter une est la première étape. S’ils arrivent dans une boîte que personne ne lit, c’est là qu’il faut regarder.
Pourquoi une ligne en échec SPF réussit DMARC ?
DMARC n’a besoin que d’un identifiant aligné. Si DKIM réussit et que son domaine est aligné sur le From, le message réussit DMARC malgré l’échec SPF. C’est normal pour un e-mail transféré, qui casse SPF par nature mais garde la signature DKIM intacte, et c’est la partie la plus mal lue d’un rapport agrégé.
Pourquoi une IP inconnue apparaît-elle dans une ligne ?
Trois explications courantes. Un service légitime oublié qui envoie pour vous : facturation, outil de tickets, plateforme marketing. Un relais qui transfère votre courrier. Ou quelqu’un qui usurpe votre domaine. Le volume les distingue souvent : les vrais services envoient régulièrement, l’usurpation procède par pics. Tant que chaque source légitime n’est pas identifiée et alignée, passer à p=reject risque de bloquer vos propres e-mails.
Puis-je analyser mes rapports avec un logiciel open source ?
Oui. parsedmarc est l’option open source de référence : Apache 2.0, auto-hébergé, il alimente Elasticsearch ou OpenSearch avec des tableaux de bord Kibana ou Grafana. Idéal pour garder l’historique vous-même si gérer l’infrastructure ne vous gêne pas. Cet outil sert quand vous avez un rapport sous les yeux et voulez le lire tout de suite.
Quels formats sont acceptés ?
Du .xml brut collé, ou un fichier .xml, .gz ou .zip. Les fichiers gzip et les ZIP à un seul fichier (le format réel des envois) sont décompressés dans le navigateur. Si une archive inhabituelle est refusée, extrayez le .xml et collez-le.
Quelle différence entre rapports agrégés (RUA) et forensiques (RUF) ?
Les rapports agrégés sont les synthèses statistiques quotidiennes que lit cet outil : volumes par source, résultats d’authentification, aucun contenu de message. Les rapports forensiques sont des exemples de messages en échec envoyés à l’adresse ruf ; ils peuvent inclure les en-têtes, parfois le contenu, et la plupart des grands destinataires n’en envoient pas, par confidentialité. Un déploiement DMARC repose sur les rapports agrégés.
Que faire des échecs affichés ?
Parcourez la liste par volume. Pour chaque source en échec, décidez si elle est à vous. Si oui, corrigez l’alignement : ajoutez-la à SPF ou, mieux, faites-la signer avec une clé DKIM alignée. Si non, et que le volume compte, c’est de l’usurpation : un argument pour aller vers l’application. Ne montez la politique de none à quarantine puis reject qu’une fois chaque source légitime en réussite.
Les balises et termes d’un rapport agrégé.
- vVersion
- La balise Version est indispensable dans un DMARC et doit valoir strictement « DMARC1 ». Si la valeur est incorrecte ou la balise absente, l’enregistrement DMARC n’est pas valide et il est ignoré.
- pPolitique DMARC
- La balise de politique DMARC accepte trois valeurs pour le courrier qui échoue : none ne demande aucune application, quarantine un traitement suspect, reject le rejet. Les destinataires décident en dernier et peuvent filtrer ou rejeter via d’autres contrôles en p=none. Les rapports agrégés se demandent à part, via la balise rua.
- ruaDestination des rapports agrégés
- La destination des rapports agrégés est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour envoyer les rapports agrégés. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- rufDestination forensique
- La destination des rapports forensiques (d’échec) est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour livrer les rapports d’échec. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- spSous-domaines
- Par défaut, la politique des sous-domaines hérite de la balise de politique du domaine principal (p=), décrite plus haut, sauf mention contraire. Comme pour le domaine, les valeurs possibles sont « none », « quarantine » ou « reject ». Cette option reste toutefois peu utilisée en pratique.
- adkimAlignement DKIM
- Cette balise fixe l’alignement de la signature DKIM, c’est-à-dire la correspondance entre le domaine DKIM et le domaine d’origine du « Header From ». Valeurs possibles : « r » (relaxed) et « s » (strict). Par défaut, « r » accepte une correspondance partielle entre ces domaines, tandis que « s » exige qu’ils soient identiques.
- aspfAlignement SPF
- Cette balise fixe l’alignement SPF, c’est-à-dire la compatibilité entre le domaine SPF (l’expéditeur) et le domaine du « Header From ». Deux valeurs : « r » (relaxed) et « s » (strict). Par défaut, « r » tolère une correspondance partielle entre les domaines. À l’inverse, « s » exige une correspondance exacte des domaines.
- foOptions forensiques
- Les options des rapports forensiques sont « 0 », « 1 », « d » et « s ». Par défaut, « 0 » déclenche un rapport seulement quand les alignements SPF et DKIM échouent tous deux. « 1 » en déclenche un dès que SPF ou DKIM ne passe pas. « d » produit un rapport pour les échecs de validation DKIM, « s » pour les problèmes SPF. Pour recevoir ces rapports forensiques, il faut renseigner la balise « ruf ».
- rfFormat des rapports
- Le format des rapports d’échec peut valoir « afrf » ou « iodef », les deux seules options autorisées.
- pctPourcentage (historique)
- L’ancienne balise Pourcentage demandait d’appliquer quarantine ou reject à une partie seulement du courrier en échec DMARC. La RFC 9989 a retiré pct, l’application partielle étant mise en œuvre de façon inégale. Les nouveaux enregistrements l’omettent et échelonnent via les rapports agrégés, des politiques entières et des sous-domaines à faible volume.
- riFréquence des rapports
- L’intervalle des rapports indique, en secondes, la fréquence des rapports XML. La valeur standard est 86400 secondes, soit un rapport par jour. Notez toutefois que, quel que soit l’intervalle indiqué, les fournisseurs d’accès (FAI) envoient en général ces rapports selon leur propre calendrier, le plus souvent une fois par jour également.