Ce guide décortique un rapport DMARC agrégé, du fichier reçu en pièce jointe jusqu’à la ligne qui tranche entre un email légitime et une usurpation. Comptez 15 minutes pour un premier passage complet une fois le fichier ouvert. Un rapport DMARC est un fichier XML envoyé chaque jour par les grands fournisseurs de messagerie (Google, Microsoft, Yahoo) : il liste, pour chaque source ayant émis au nom de votre domaine, le résultat de l’authentification SPF et DKIM ainsi que l’action réellement appliquée par le destinataire. La suite suit l’ordre dans lequel ces informations apparaissent dans le fichier.
Décompresser le fichier avant de l’ouvrir
Le fichier arrive presque toujours compressé, en .gz ou en .zip selon le fournisseur qui l’envoie. Google et Microsoft livrent du .zip, la plupart des autres fournisseurs du .gz. Impossible de lire le XML sans cette étape.
- Sur Mac, double-cliquez le fichier .zip : l’Archive Utility l’extrait sans installation supplémentaire.
- Sur Mac ou Linux, pour un .gz, ouvrez un terminal et lancez gunzip nom-du-fichier.xml.gz.
- Sur Windows, 7-Zip ouvre les deux formats depuis le clic droit.
- Le résultat est un fichier .xml lisible dans n’importe quel éditeur de texte.
C’est tout pour cette étape.
Les 3 blocs qui structurent le XML
Un rapport DMARC agrégé s’organise toujours autour de la même racine feedback, définie par la RFC 7489 et actualisée depuis par la RFC 9990 (IETF, 2026). Trois blocs s’y succèdent, dans cet ordre.
Le bloc report_metadata ouvre le fichier : il donne le nom de l’organisation qui a généré le rapport (org_name, par exemple google.com), un email de contact, un report_id unique, puis la période couverte via date_range/begin et date_range/end, exprimée en timestamp Unix et correspondant en général à une fenêtre de 24 heures.
Le bloc policy_published suit : il rappelle la politique DMARC en vigueur au moment du scan, telle que lue dans votre enregistrement DNS. domain identifie le domaine concerné. p fixe la politique demandée pour le domaine principal, sp fait de même pour les sous-domaines. adkim et aspf indiquent le mode d’alignement : strict ou relaxed. pct précise le pourcentage de messages auquel la politique s’applique.
Vient enfin un ou plusieurs blocs record, un par combinaison source_ip et jour observé, chacun avec un compteur count qui indique le nombre de messages regroupés sous cette ligne. C’est là que se trouve le verdict.
policy_evaluated : le verdict qui compte réellement
Chaque policy_evaluated se niche dans un record/row et répond à une seule question : qu’a fait le serveur destinataire de ce message ? Trois champs portent l’information. disposition indique l’action concrètement appliquée par le destinataire (le tableau plus bas détaille les 3 valeurs possibles). dkim et spf indiquent chacun pass ou fail sans refléter le protocole brut à l’état pur : ils reflètent le résultat après vérification de l’alignement DMARC, c’est-à-dire la correspondance entre le domaine authentifié et le domaine affiché dans le champ From.
Alignement strict ou relaxed : ce que ça change
Le bloc identifiers précise header_from, toujours présent. envelope_from existe aussi dans le schéma mais reste optionnel : la plupart des fournisseurs le laissent vide, Microsoft étant l’un des rares à le renseigner systématiquement. Pour DKIM, auth_results donne le domain utilisé, le selector puis le result obtenu. Pour SPF, il donne le domain puis le result. En mode relaxed (la valeur par défaut si adkim ou aspf est absent), mail.exemple.fr s’aligne avec exemple.fr parce que les deux partagent le même domaine organisationnel. En mode strict, seule une correspondance exacte des deux noms complets est acceptée. Un domaine d’envoi transactionnel du type notifications.exemple.fr échoue en alignement strict, même si le SPF ou le DKIM technique est valide.
Le tableau ci-dessous résume ce que chaque disposition change côté délivrabilité, indépendamment du fournisseur qui reçoit le message.
| Disposition | Ce qui arrive au message | Quand la choisir |
|---|---|---|
| none | Livré normalement, seul un rapport est généré | Phase d’observation, avant toute application |
| quarantine | Livré en dossier spam ou indésirables | Une fois les sources légitimes toutes identifiées |
| reject | Bloqué avant remise, aucune trace côté destinataire | Domaine surveillé plusieurs semaines sans faux positif |
Passer directement en DMARC reject sans être passé par la case none saute l’étape où les sources légitimes se révèlent. Une politique quarantine mal calée pousse des emails valides vers le dossier indésirables du destinataire, une cause directe de plaintes spam sur un domaine techniquement sain.
RUA et RUF : deux rapports, deux usages
RUA désigne les rapports agrégés, ceux que la structure XML ci-dessus décrit. Ils arrivent une fois par 24 heures, résumés par source, sans jamais contenir le corps du message d’origine.
RUF désigne les rapports forensiques, envoyés en quasi temps réel à chaque échec d’authentification individuel. Un rapport RUF peut inclure des en-têtes complets, parfois un extrait du message. La majorité des grands fournisseurs de messagerie, Google et Yahoo compris, ont cessé de les envoyer par souci de confidentialité, d’après la documentation publiée par dmarcian (2026).
Dans la pratique, seul RUA reste fiable pour un monitoring continu. Configurer rua=mailto:… dans l’enregistrement DNS suffit pour la quasi-totalité des besoins de suivi.
Distinguer une attaque réelle d’un faux positif
Un volume de fail élevé sur un record n’indique pas toujours une usurpation. Trois causes expliquent la plupart des faux positifs, bien avant l’hypothèse d’une attaque.
Le transfert d’email casse le SPF dans la majorité des cas : le serveur relais n’apparaît jamais dans votre enregistrement SPF d’origine, donc la vérification échoue même si le message part bien de vous.
Les listes de diffusion posent un problème inverse : elles ajoutent souvent un préfixe au sujet ou un pied de page, ce qui casse la signature DKIM tout en laissant le SPF intact.
Les prestataires tiers non déclarés forment la 3e cause : un outil CRM, une plateforme de facturation ou un service transactionnel qui envoie au nom de votre domaine sans figurer dans votre SPF. C’est aussi la cause la plus fréquente de bounces inattendus après l’ajout d’un nouvel outil, un cas traité en détail dans notre article sur la lecture des bounces emailing.
Le transfert d’un message casse presque toujours l’alignement SPF, parce que le relais intermédiaire n’apparaît jamais dans l’enregistrement SPF d’origine. La signature DKIM, elle, survit tant que le contenu du message n’est pas modifié en chemin (documentation Valimail sur l’alignement DMARC, 2026).
Éviter de lire le XML à la main
Passé les 2 ou 3 premiers rapports, analyser un rapport DMARC à la main devient inutile pour un usage récurrent. parsedmarc, maintenu en open source sur GitHub, agrège les fichiers reçus par IMAP ou API et les restitue sous forme de tableaux et de graphiques, sans coût de licence.
Côté SaaS, EasyDMARC, PowerDMARC, MXToolbox et dmarcian proposent la même agrégation avec hébergement et alertes incluses, moyennant un abonnement mensuel. Aucun de ces outils ne change la structure XML sous-jacente. Ils se contentent de l’agréger.
- parsedmarc : gratuit et auto-hébergé, nécessite un serveur ou un conteneur pour tourner en continu
- EasyDMARC, PowerDMARC, dmarcian : SaaS, mise en route rapide, coût récurrent
- MXToolbox : ponctuel, utile pour vérifier un enregistrement DNS sans agréger l’historique
Ouvrir le rapport et lire policy_evaluated pour trancher entre attaque et faux positif : ce tri revient chaque jour et suit toujours le même schéma. C’est exactement le type de tâche qu’un agent autonome peut absorber dans un workflow n8n, pour ne remonter que les cas ambigus à un humain. Beaucoup de décideurs ont 3 POC IA en interne et aucun déployé : un flux de données aussi structuré qu’un rapport DMARC est souvent le premier candidat qui passe réellement en production.
Un rapport DMARC est lu quand la disposition et l’alignement sont clairs pour chaque source du record (spf, dkim, count). Passez au rapport du jour suivant.