Lire les rapports DMARC

Module 4: Délivrabilité : SPF, DKIM et DMARC en pratique · Temps de lecture : 12 minutes

Objectif pédagogique : Après cette leçon, vous saurez ouvrir et lire un rapport agrégé DMARC, déterminer pour chaque ligne de quelle source il s'agit et pourquoi elle réussit ou échoue, et décider ce que vous devez réparer, ce que vous pouvez ignorer et quand vous pouvez durcir votre politique.

Notions clés : rapport agrégé (aggregate report, RFC 9990), rua, XML, gzip ou zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, sélecteur, rapport d'échec (ruf, RFC 9991), service de rapport, confidentialité

Ce que vous recevez

Si vous avez indiqué une adresse rua dans votre enregistrement DMARC (leçon 4.4), les grands destinataires comme Google, Microsoft et Yahoo vous envoient environ chaque jour un rapport agrégé. Il s'agit d'un e-mail avec une pièce jointe, généralement un fichier XML compressé avec un nom du type :

receiver.example!example.com!1793923200!1794009599.xml.gz

Cela signifie : du destinataire receiver.example, concernant votre domaine example.com, pour la période comprise entre les deux horodatages (secondes depuis 1970 ; ici le 6 novembre 2026, toute la journée en UTC).

Un rapport ne contient aucun contenu d'e-mail, aucun objet et généralement aucune adresse de destinataire. Il contient, par serveur d'envoi, le nombre de messages et le résultat de SPF, DKIM et DMARC. C'est donc un aperçu fiable de qui envoie des e-mails au nom de votre domaine, y compris des sources que vous aviez oubliées, et des fraudeurs.

La structure d'un rapport

Un rapport comporte trois parties. Voici ci-dessous les éléments principaux du fichier exemple de cette leçon (dmarc-rapport-1.xml).

1. Qui fait le rapport, sur quelle période

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Quelle politique le destinataire a trouvée chez vous

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Vérifiez toujours ceci : si ce qui est indiqué ici ne correspond pas à ce que vous pensez avoir dans votre DNS, c'est que le destinataire a lu un autre enregistrement (ou un ancien).

3. Par source : un enregistrement

Chaque record porte sur une adresse IP d'envoi avec une combinaison de résultats :

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

La différence essentielle : auth_results face à policy_evaluated

C'est ici que se trouve l'essentiel de la lecture. Dans l'exemple ci-dessus, auth_results indique deux fois pass : DKIM a réussi pour mailer.example et SPF a réussi pour bounce.mailer.example. Pourtant, policy_evaluated indique deux fois fail. Ce n'est pas une contradiction : policy_evaluated ne compte qu'un contrôle réussi qui est aligné avec header_from. Aucun des deux domaines ne correspond à example.com, donc DMARC échoue.

Voici comment lire chaque ligne :

1. Regardez policy_evaluated. Y a-t-il un pass pour dkim ou spf ? Alors DMARC réussit et cette source est en ordre.
2. Tout échoue ? Regardez les domaines dans auth_results. S'agit-il d'un service qui vous appartient mais qui réussit pour son propre domaine ? Vous devez alors activer DKIM avec votre propre domaine chez ce service (leçon 4.3).
3. Cela échoue aussi dans auth_results, ou DKIM est totalement absent ? Recherchez à qui appartient l'adresse IP (DNS inverse, leçon 5.1, ou une recherche whois). S'il s'agit de l'un de vos systèmes : réparez-le. Si elle est inconnue et que les volumes sont suspects : il s'agit probablement d'une usurpation.

Des schémas récurrents

Attention aussi à l'IPv6 : un serveur propre qui envoie parfois via IPv6, alors que votre SPF ne mentionne que l'adresse IPv4, donne un softfail sur ces lignes. Avec une signature DKIM, DMARC réussit tout de même, mais c'est le signe que votre SPF est incomplet.

Du rapport à la décision

Vous êtes prêt à durcir votre politique (de none vers quarantine, puis vers reject) si :

• chaque source qui vous appartient obtient au moins un pass dans policy_evaluated ;
• c'est le cas depuis déjà quelques semaines, chez tous les grands destinataires ;
• ce qui échoue encore n'est que de l'e-mail transféré avec une signature DKIM valide (qui réussit tout de même) ou clairement de l'usurpation.

Si une grande source vous appartenant échoue, comme dans l'exemple le service de newsletter avec 1250 messages, il est trop tôt. Avec p=reject, le destinataire refuserait ces 1250 newsletters.

Rendre les rapports lisibles

Un seul rapport dans un éditeur de texte, c'est faisable. Vingt par jour, non. Il existe trois méthodes :

• Un service de rapport (il en existe beaucoup, y compris des versions gratuites). Vous indiquez leur adresse dans rua et ils en font des graphiques et des listes. Attention : vous donnez alors à ce service une visibilité sur les serveurs qui envoient en votre nom, et l'adresse de rapport se trouve sur leur domaine (voir l'autorisation via _report._dmarc à la leçon 4.4). Choisissez un service en qui vous avez confiance et qui respecte le RGPD.
• Un outil maison : il existe des programmes open source qui récupèrent les rapports dans une boîte mail et en font une synthèse.
• Lire vous-même avec une visionneuse XML ou un navigateur, pour un usage occasionnel.

Les rapports d'échec (ruf, RFC 9991) sont différents : par e-mail en échec, parfois avec des extraits de l'e-mail inclus. Presque aucun grand destinataire ne les envoie, justement pour des raisons de confidentialité. Vous n'en avez pas besoin pour bien déployer DMARC.

En pratique : voici à quoi cela ressemble

Chez WebOké, vous pouvez renseigner l'adresse de rapport dans l'assistant DMARC de DirectAdmin ou de Mon WebOké (voir leçon 4.4), et vous choisissez vous-même une boîte mail où les rapports arrivent ; une adresse distincte comme dmarc@ avec son propre dossier évite que vos e-mails habituels soient noyés. Pour la lecture, utilisez un service ou un programme de votre choix. Cela fonctionne de la même manière chez tous les fournisseurs : le rapport suit un format standard.

Résumé

• Un rapport agrégé est un fichier XML quotidien (souvent compressé) par destinataire, indiquant pour chaque IP d'envoi le nombre de messages et les résultats.
• auth_results donne le résultat brut de SPF et DKIM ; policy_evaluated indique uniquement ce qui a réussi de manière alignée. Un pass dans auth_results peut correspondre à un fail dans DMARC.
• L'e-mail transféré se reconnaît à un DKIM pass avec SPF fail ; l'usurpation à un échec complet depuis une IP inconnue.
• Ne durcissez votre politique que lorsque toutes vos propres sources réussissent depuis quelques semaines.
• Les rapports d'échec (ruf) sont rares et non nécessaires.

Quiz

Exercice

Exercice Z4.5: Lire un rapport DMARC. Ouvrez le fichier exemple dmarc-rapport-1.xml (un rapport agrégé concernant example.com, avec des données fictives). Répondez aux questions : quelle politique le destinataire a-t-il trouvée, combien de messages figurent au total dans le rapport, combien d'entre eux ont échoué à DMARC, quelle ligne correspond au service de newsletter et que faut-il faire, quelle ligne correspond à un e-mail transféré, quelle ligne est probablement une usurpation, que faut-il modifier dans l'enregistrement SPF selon la ligne 6, quelle ligne réussit uniquement grâce à DKIM chez un service avec son propre Return-Path, et le domaine peut-il désormais passer à p=quarantine ? Le programme vérifie vos réponses à l'aide d'un corrigé et explique, pour chaque question, quelle ligne du rapport donne la réponse.

Pour aller plus loin

Les étapes de ces articles s'appliquent aux panneaux de WebOké ; chez d'autres fournisseurs, cela fonctionne de manière similaire.

• Qu'est-ce que le DMARC ? Explication en termes simples
• Guide DirectAdmin 5.9: DMARC instellen
• Cours DNS gratuit 4.5: DMARC : que doivent faire les destinataires avec les faux e-mails
• RFC 9990 (DMARC Aggregate Reporting), avec le rapport exemple en annexe B ; RFC 9991 (Failure Reporting)