Lire un rapport DMARC agrégé, ligne par ligne
11 min de lecture
Vous avez publié votre enregistrement DMARC. Deux jours plus tard, votre boîte reçoit un fichier compressé envoyé par noreply-dmarc-support@google.com. Vous le décompressez et vous tombez sur plusieurs centaines de lignes de XML.
Cet article décode un rapport complet, sans rien sauter. À la fin, vous saurez lire le vôtre.
Ce que vous recevez, et qui vous l’envoie
Un rapport agrégé est produit par une organisation qui reçoit vos messages, pas par vous. Google, Microsoft, Yahoo, Orange, Free et quelques centaines d’autres opérateurs de messagerie compilent chaque jour ce qu’ils ont vu passer prétendant venir de votre domaine, et vous l’envoient à l’adresse que vous avez indiquée dans le tag rua.
Trois conséquences pratiques.
Vous recevez plusieurs rapports par jour, un par organisation réceptrice. Un domaine actif en reçoit entre cinq et quarante. Ils ne sont pas fusionnés, c’est à vous de les agréger.
Ils décrivent le passé, avec un décalage de vingt-quatre à quarante-huit heures. Ce n’est pas de la surveillance en temps réel, et rien ne vous alertera d’une attaque en cours.
Ils ne couvrent que les receveurs qui jouent le jeu. Un destinataire dont le serveur n’émet pas de rapports est un angle mort permanent.
Depuis mai 2026, le format de ces rapports est décrit par la RFC 9990, qui remplace la RFC 7489 sur ce point. Les changements sont mineurs pour un lecteur humain, avec une exception notée plus bas.
Les trois blocs d’un rapport
Un rapport se compose toujours des mêmes trois parties.
Bloc 1 : les métadonnées
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>8291047562819304715</report_id>
<date_range>
<begin>1755648000</begin>
<end>1755734400</end>
</date_range>
</report_metadata>
org_name identifie qui vous parle. report_id est l’identifiant unique du rapport chez cet émetteur : c’est le couple org_name et report_id qui permet de repérer les doublons, et il y en aura, car les receveurs réémettent régulièrement les mêmes rapports.
date_range est exprimé en secondes depuis 1970. Les deux valeurs de l’exemple correspondent à une journée complète du 20 août 2026. Retenez que la fenêtre couverte est presque toujours de vingt-quatre heures.
Bloc 2 : la politique publiée
<policy_published>
<domain>entreprise.fr</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
</policy_published>
Ce bloc vous dit ce que le receveur a lu dans votre DNS au moment du traitement. Il a une vertu que l’on sous-estime : il vous montre votre politique telle qu’elle a réellement été vue, pas telle que vous croyez l’avoir publiée. Si vous avez modifié votre enregistrement récemment et que ce bloc affiche encore l’ancienne valeur, votre changement n’est pas propagé.
adkim et aspf à r indiquent un alignement relâché, la valeur par défaut. p est la politique du domaine, sp celle des sous-domaines.
Si vous lisez de la documentation antérieure à 2026, vous y verrez aussi un tag pct. Il a été supprimé par le nouveau standard, nous y revenons dans l’article sur le durcissement.
Bloc 3 : les enregistrements
C’est le cœur du rapport, et il se répète autant de fois qu’il y a de sources d’envoi distinctes. Voici trois blocs tirés d’un rapport réel, anonymisé.
Décoder trois enregistrements
Le cas conforme
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>1247</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>entreprise.fr</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>entreprise.fr</domain>
<selector>google</selector>
<result>pass</result>
</dkim>
<spf>
<domain>entreprise.fr</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
L’adresse IP appartient à Google. Le champ count indique 1247 messages, et non un seul : chaque enregistrement agrège tous les messages partageant la même source et le même résultat. C’est l’erreur de lecture la plus fréquente chez les débutants, qui comptent les blocs au lieu d’additionner les count.
Ici tout est aligné, tout passe. C’est votre messagerie Google Workspace, correctement configurée.
Notez le champ selector dans le bloc DKIM. Depuis la RFC 9990, il est obligatoire dès qu’une signature DKIM est rapportée. Sur des rapports anciens, il pouvait manquer.
Le cas qui trompe tout le monde
<record>
<row>
<source_ip>54.240.27.118</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>entreprise.fr</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>hubspotemail.net</domain>
<selector>hs1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>hubspotemail.net</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
Regardez bien. Dans auth_results, DKIM passe et SPF passe. Dans policy_evaluated, DKIM échoue et SPF échoue.
Ce n’est pas une contradiction, et c’est le point le plus important de cet article.
auth_results donne le résultat brut de l’authentification. HubSpot a signé correctement et son SPF est valide. Techniquement, ces messages sont authentifiés.
policy_evaluated donne le résultat après vérification de l’alignement. Or les domaines authentifiés sont hubspotemail.net, alors que le domaine affiché à vos clients est entreprise.fr. Aucun rapport entre les deux, donc aucun alignement, donc échec DMARC.
312 messages partis de votre CRM sont non conformes, alors que le prestataire n’a commis aucune faute technique. Il manque simplement une configuration : faire signer HubSpot en DKIM avec votre domaine, ce qui demande de publier quelques CNAME chez vous. Le mécanisme est détaillé dans notre article sur l’alignement.
La règle à retenir : votre taux de conformité DMARC se calcule sur policy_evaluated, jamais sur auth_results. Un outil qui compte les résultats bruts vous annoncera 98 % de conformité là où la réalité est à 74 %. Le chiffre sera faux, et suffisamment crédible pour que vous durcissiez votre politique en confiance, avant de bloquer vos propres factures.
Le cas inconnu
<record>
<row>
<source_ip>185.220.101.47</source_ip>
<count>47</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>entreprise.fr</header_from>
</identifiers>
<auth_results>
<spf>
<domain>entreprise.fr</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
Pas de signature DKIM du tout, SPF en échec brut, une adresse IP que vous ne reconnaissez pas. Quarante-sept messages prétendant venir de chez vous.
Deux hypothèses, et il faut trancher avant de durcir. Soit c’est une tentative d’usurpation, et votre politique la bloquera. Soit c’est un outil légitime oublié, un vieux formulaire de site, une imprimante qui envoie des scans, un prestataire dont personne ne se souvient, et votre politique le bloquera aussi.
C’est très exactement pour cette raison que l’on ne durcit pas une politique DMARC sans avoir identifié chaque source.
Le champ disposition, et pourquoi il ment parfois
disposition indique ce que le receveur a réellement fait du message : none, quarantine ou reject.
Il ne correspond pas toujours à votre politique publiée. Un receveur peut décider de ne pas appliquer votre politique, par exemple parce qu’il a identifié un transfert légitime ou parce qu’il applique ses propres règles. Dans ce cas, le rapport contient un bloc supplémentaire précisant le motif de la dérogation.
Ne vous inquiétez donc pas de voir disposition à none alors que vous êtes en p=reject : cela signifie que le receveur a estimé, ce jour-là et pour ce message, qu’il valait mieux ne pas appliquer votre politique.
Ce qu’un rapport agrégé ne contiendra jamais
Trois absences, à connaître pour ne pas chercher ce qui n’existe pas.
Aucun destinataire. Vous ne saurez jamais à qui les messages ont été adressés.
Aucun contenu. Ni objet, ni corps, ni pièce jointe.
Aucune identité d’attaquant. Vous voyez une adresse IP, pas une personne.
C’est délibéré. Les rapports agrégés sont conçus pour décrire des flux, pas des personnes, ce qui les rend exploitables sans poser de difficulté au regard du RGPD. Les rapports d’échec, qui eux transportaient des en-têtes de messages réels, ont pratiquement disparu pour cette raison : Gmail, Outlook, Yahoo, Apple et LinkedIn n’en envoient pas.
Passer de quarante rapports par jour à une seule décision
Vous savez maintenant lire un rapport. Reste le vrai problème : vous en recevez quarante par jour, chacun contenant des dizaines d’enregistrements, et l’information utile est éclatée entre tous.
Le travail consiste à additionner les count par source sur une fenêtre glissante, à dédoublonner les rapports réémis, à traduire chaque adresse IP en un nom de prestataire reconnaissable, puis à en tirer une seule réponse : puis-je durcir, et si non, qu’est-ce qui m’en empêche ?
C’est faisable à la main sur un domaine, pendant deux semaines. Cela devient impraticable au-delà.
Questions fréquentes
À quelle fréquence reçoit-on des rapports DMARC ? Chaque organisation réceptrice en envoie en général un par jour et par domaine. Un domaine actif en reçoit entre cinq et quarante quotidiennement.
Un rapport DMARC contient-il le contenu des messages ? Non. Un rapport agrégé ne contient ni destinataires, ni objets, ni corps de message, uniquement des statistiques par adresse IP émettrice.
Pourquoi les résultats SPF apparaissent-ils deux fois dans un rapport ?
Le bloc policy_evaluated donne le résultat après vérification de l’alignement, le bloc auth_results donne le résultat brut. Seul le premier détermine la conformité DMARC.
Que signifie le champ count ?
Le nombre de messages regroupés dans cet enregistrement. Pour obtenir un volume total, additionnez les count, ne comptez pas les blocs.
Puis-je lire mes rapports sans outil ? Sur un domaine et pendant quelques semaines, oui, avec de la patience et un tableur. Au-delà, le volume et la déduplication rendent l’exercice peu fiable.
Alignmarc fait ce travail à votre place : déduplication, agrégation, identification des expéditeurs par leur nom, et une réponse claire sur votre capacité à durcir. Le premier domaine est gratuit.
À lire ensuite