Comment lire les rapports DMARC avant de passer à l'application

Dès que vous publiez un enregistrement DMARC avec une adresse rua=, les fournisseurs de messagerie commencent à vous envoyer des rapports quotidiens sur chaque serveur qui utilise votre domaine — et savoir lire les rapports DMARC fait toute la différence entre un passage sûr à l'application et l'envoi accidentel de vos propres factures dans les spams. Le hic, c'est que ces rapports arrivent sous forme de XML dense qu'aucun humain n'était censé parcourir. Ce guide explique précisément ce que contient un rapport agrégé, comment l'interpréter pour repérer le courrier légitime qui échoue, et là où un analyseur de rapports fait vraiment la différence.

La réponse en bref#

Les rapports agrégés DMARC (ceux déclenchés par la balise rua=) sont des fichiers XML qu'un destinataire vous envoie environ une fois par jour. Chacun regroupe par IP d'envoi le courrier qu'il a vu se réclamer de votre domaine, et pour chaque source il vous indique : combien de messages, si SPF et DKIM ont réussi et se sont alignés, et ce que le destinataire en a fait. Vous les lisez pour dresser un inventaire complet de ceux qui envoient en votre nom, et pour confirmer que chaque flux légitime s'authentifie en alignement avant de durcir votre politique de p=none vers quarantine puis reject. Le XML brut est pénible, aussi presque tout le monde le charge dans un analyseur de rapports DMARC qui le transforme en un tableau lisible.

Vous avez déjà un rapport sous la main ? Collez-le ou téléversez-le dans l'analyseur de rapports DMARC gratuit pour suivre ce guide sur vos propres données — il analyse tout dans votre navigateur, rien n'est téléversé.

Ce qui déclenche un rapport agrégé#

Le déclencheur tient à une seule balise de votre enregistrement DMARC. Lorsque vous publiez rua= sur _dmarc.yourdomain.com, vous demandez à chaque destinataire participant de vous envoyer un retour agrégé :

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

À partir de là, les grands destinataires — Google, Yahoo, Microsoft, Comcast et bien d'autres — regroupent tout ce qu'ils ont vu provenir de votre domaine sur une fenêtre de 24 heures et envoient un seul rapport XML par domaine. Le rapport arrive généralement sous forme de pièce jointe compressée (.xml.gz ou .zip) avec un nom de fichier qui encode l'émetteur du rapport, votre domaine et la plage de dates. Vous pouvez pointer rua vers plusieurs adresses, et vous pouvez même collecter les rapports d'un domaine que vous ne contrôlez pas en utilisant une destination externe, ce qui nécessite toutefois un enregistrement d'autorisation supplémentaire sur le domaine récepteur. Si vous n'avez pas encore publié d'enregistrement, commencez par le guide pas à pas de configuration DMARC ordonné — les rapports ne démarrent qu'une fois l'enregistrement en ligne.

Comment lire un rapport agrégé DMARC, ligne par ligne#

Chaque rapport agrégé suit le même schéma XML, défini dans la RFC 7489. Il comporte trois parties : qui a envoyé le rapport, quelle politique vous aviez publiée à ce moment-là, puis un ou plusieurs blocs <record> — un par source d'envoi. Voici un exemple raccourci d'un seul enregistrement :

<record>
  <row>
    <source_ip>203.0.113.42</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>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

La chose la plus importante à comprendre, c'est qu'un rapport vous donne le résultat d'authentification à deux endroits différents, et qu'ils ne signifient pas la même chose :

Le bloc auth_results indique si SPF et DKIM ont réussi tout court. Le bloc policy_evaluated indique s'ils ont réussi en alignement, ce qui est la seule chose qui compte pour DMARC. Ces deux blocs peuvent diverger, et c'est dans cet écart que se concentre l'essentiel de votre travail d'enquête.

Repérer une source légitime qui échoue#

Voici le schéma que vous recherchez, et pourquoi il compte. Imaginez un enregistrement où le source_ip appartient clairement à une plateforme marketing que vous utilisez, où le header_from est votre domaine, et où auth_results affiche spf: pass — mais où le domaine SPF indiqué est le propre domaine de rebond de la plateforme, pas le vôtre, et où policy_evaluated/spf affiche fail. Ce message s'est authentifié pour quelqu'un, mais pas pour vous d'une manière qui s'aligne. Sous p=none, la disposition reste none, donc rien n'est cassé — pour l'instant. Dès que vous passez à quarantine ou reject, chaque message de ce count commence à partir en spam ou à être rejeté.

La lecture est donc toujours la même comparaison en trois étapes :

• Identifiez la source. Faites correspondre chaque source_ip à un service réel. Un rapide reverse-DNS ou l'étiquetage intégré de l'analyseur le nomme généralement. Votre objectif est une liste complète — les rapports font régulièrement remonter un outil de facturation oublié ou une ancienne plateforme de campagne qui envoie encore en votre nom.
• Vérifiez l'alignement, pas seulement l'authentification. Regardez policy_evaluated, pas auth_results. Une source peut passer SPF ou DKIM et échouer quand même à DMARC parce que le domaine pour lequel elle s'est authentifiée ne correspond pas à votre « From ».
• Décidez : corriger, ou laisser échouer. Si la source est légitime, corrigez son alignement — ajoutez-la à SPF, ou mieux, mettez en place la signature DKIM sur votre domaine afin que le domaine signataire concorde. S'il s'agit d'un usurpateur, l'échec est exactement ce que vous voulez, et c'est la preuve que votre futur p=reject fera son travail.

L'alignement DKIM mérite généralement d'être priorisé par rapport à SPF, car une signature DKIM voyage avec le message et survit au transfert, alors que l'alignement SPF se casse dès que le courrier est relayé. Les mécanismes de l'alignement — assoupli (relaxed) contre strict, domaine organisationnel contre correspondance exacte — sont détaillés dans l' explication SPF, DKIM et DMARC si vous avez besoin de prendre le temps sur ce concept.

RUA contre RUF : deux rapports très différents#

DMARC définit deux balises de rapport, et elles ne sont pas interchangeables :

• rua — rapports agrégés. Les résumés XML quotidiens décrits ci-dessus. Ils contiennent des décomptes et des résultats regroupés par source, aucun contenu de message, et ce sont eux sur lesquels vous vous appuyez pour tout le déploiement. Tout destinataire sérieux les envoie.
• ruf — rapports forensiques (d'échec). Des rapports par message générés au moment où un message individuel échoue. Historiquement, ils pouvaient inclure les en-têtes et parfois des portions du message, ce qui signifie qu'ils peuvent contenir des données personnelles.

Comme les rapports forensiques peuvent exposer des informations sur les destinataires, la plupart des grands fournisseurs ont cessé de les envoyer il y a des années pour des raisons de confidentialité, et beaucoup d'expéditeurs ne publient jamais ruf du tout. Un enregistrement qui demande les deux ressemble à ceci :

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com"

En pratique, vous recevrez un flux régulier de rapports agrégés rua et peu ou pas de rapports forensiques ruf. Planifiez votre surveillance autour des données agrégées ; considérez les rapports forensiques que vous recevez comme un bonus occasionnel, et n'activez ruf que si vous disposez d'une base légale et d'un endroit où stocker ce qui peut être des données personnelles.

Pourquoi vous voulez un analyseur, pas une simple boîte de réception#

Vous pouvez ouvrir le XML à la main, et pour un seul domaine avec deux ou trois expéditeurs, c'est supportable pendant un temps. Cela cesse vite de passer à l'échelle. Un domaine actif génère des dizaines de rapports par jour provenant de différents destinataires, chacun listant de nombreuses IP sources, et le signal intéressant — un expéditeur légitime qui échoue discrètement à l'alignement — est enfoui dans des balises horodatées en temps Unix et des adresses IP non étiquetées.

Un analyseur de rapports DMARC ou un tableau de bord de surveillance ingère les rapports à une adresse dédiée, décompresse et analyse le XML, résout les IP en noms de service reconnaissables, et consolide le tout dans un tableau que vous pouvez réellement lire : les sources d'un côté, les volumes de réussite et d'échec de l'autre, les tendances dans le temps. Les bons signalent les sources nouvelles ou nouvellement en échec pour que vous remarquiez un changement sans relire chaque fichier. Que vous utilisiez un service hébergé ou un analyseur auto-hébergé, le travail est le même — transformer une pile de XML en « voici qui envoie en votre nom, et voici qui n'est pas encore aligné ». Cette clarté est ce qui rend les rapports exploitables plutôt que simplement archivés.

Comment cela s'intègre au déploiement sûr#

Lire les rapports n'est pas une corvée distincte de la configuration de DMARC — c'est le milieu du déploiement, et le sauter est la façon dont on enterre son propre courrier. La séquence :

1. Publiez p=none avec rua. Rien ne change dans la manière dont votre courrier est traité ; la remontée de rapports s'active simplement.
2. Lisez les rapports agrégés pendant un cycle d'envoi complet. Deux semaines au minimum, plus longtemps si vous avez des flux à faible fréquence comme des relevés mensuels. Construisez l'inventaire complet des sources.
3. Corrigez chaque source légitime qui échoue à l'alignement. C'est là que passe le vrai temps, et là où les rapports vous orientent.
4. Passez à quarantine, puis à reject. Seulement une fois que les rapports montrent que chaque flux authentique passe en alignement. p=reject est le réglage qui arrête réellement l'usurpation et satisfait les règles pour les gros expéditeurs des exigences des expéditeurs Google et Yahoo.

Les rapports continuent de justifier leur place même après avoir atteint reject — c'est ainsi que vous détectez un nouvel outil SaaS qui se met à envoyer en votre nom, ou une campagne d'usurpation qui monte en puissance contre votre marque. Les surveiller en parallèle de vos plaintes des boucles de rétroaction et de votre réputation d'expéditeur globale vous donne un système d'alerte précoce plutôt qu'une tâche de configuration ponctuelle.

Une limite qu'il faut reconnaître honnêtement : réussir DMARC en alignement prouve qui vous êtes, pas que vous êtes un bon expéditeur. Un domaine parfaitement aligné qui envoie à des adresses mortes ou à des pièges à spam atterrit quand même dans les spams — l'authentification est le billet d'entrée, et ce sont la qualité de la liste et l'engagement qui décident du placement. Cette image plus large fait l'objet du guide de délivrabilité, et c'est la raison la plus courante pour laquelle un courrier légitime finit encore en spam même avec des rapports impeccables.

Foire aux questions#

Que contiennent réellement les rapports agrégés DMARC ?#

Un rapport agrégé (rua) est un fichier XML qui regroupe, par adresse IP d'envoi, le courrier qu'un destinataire a vu provenir de votre domaine. Pour chaque source, il indique le nombre de messages, les résultats bruts SPF et DKIM ainsi que les domaines sur lesquels ils ont été évalués, le verdict aligné DMARC, et la disposition appliquée par le destinataire selon la politique que vous avez publiée. Il n'inclut jamais les objets, les corps de messages ni les adresses des destinataires — uniquement des décomptes agrégés et des résultats d'authentification, ce qui le rend respectueux de la vie privée.

Quelle est la différence entre les rapports RUA et RUF ?#

rua demande des rapports agrégés quotidiens : des décomptes synthétisés et des résultats pass/fail regroupés par source, sans contenu de message. ruf demande des rapports forensiques ou d'échec, générés pour chaque message en échec et historiquement capables d'inclure les en-têtes et les données du message. Comme les rapports forensiques peuvent contenir des données personnelles, la plupart des grands destinataires ne les envoient plus ; vous devez donc construire votre surveillance sur les rapports agrégés et considérer toute donnée forensique comme un extra occasionnel.

Pourquoi une source affiche-t-elle SPF pass mais DMARC fail dans mon rapport ?#

Parce que DMARC exige l'alignement, et pas seulement l'authentification. Un message peut passer SPF pour le domaine propre du service d'envoi alors que votre domaine figure dans le « From » visible — SPF passe, mais les domaines ne concordent pas, donc DMARC échoue. Lisez le résultat policy_evaluated plutôt que les auth_results bruts : le premier reflète l'alignement. Pour corriger cela, il faut généralement ajouter la source à votre enregistrement SPF ou, de façon plus robuste, activer la signature DKIM sur votre propre domaine afin que le domaine signataire concorde.

Ai-je besoin d'un analyseur DMARC, ou puis-je lire les rapports moi-même ?#

Pour un seul domaine avec deux ou trois expéditeurs, vous pouvez lire le XML brut pendant un temps. Cela cesse vite d'être praticable, car un domaine actif reçoit des dizaines de rapports par jour, remplis d'IP et d'horodatages non étiquetés. Un analyseur ou un tableau de bord de surveillance décompresse et analyse les rapports, nomme les sources et consolide les données dans un tableau lisible avec des tendances — c'est ce qui transforme les rapports en décisions plutôt qu'en un dossier jamais ouvert.

Les rapports agrégés vous disent qui envoie en votre nom ; ils ne vous disent pas si la liste derrière ce courrier est saine. Passez vos adresses au vérificateur d'e-mails gratuit pour éliminer les domaines morts, les fautes de frappe et les pièges à spam avant qu'ils ne génèrent des rebonds — car un domaine parfaitement aligné a quand même besoin d'une liste saine pour gagner la boîte de réception.