toutes les fiches

// comment corriger

Comment lire les rapports agrégés DMARC (rua)

Les rapports DMARC sont des fichiers XML envoyés par Gmail, Microsoft et d'autres. Découvrez ce que signifie chaque partie et comment repérer les vrais problèmes et l'usurpation.

Ce que ça veut dire

Quand votre enregistrement DMARC contient une adresse rua=, les serveurs de réception comme Google, Microsoft et Yahoo vous envoient un résumé quotidien appelé rapport agrégé. Il liste chaque adresse IP qui a envoyé des emails avec votre domaine, le nombre d'emails, et s'ils ont passé le SPF et le DKIM.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Les rapports arrivent en pièces jointes compressées (.zip ou .gz) qui contiennent un fichier XML. Ils sont écrits pour des machines, mais vous pouvez les lire.

Pourquoi c'est important

  • Ils montrent tous vos expéditeurs, y compris ceux que vous avez oubliés : un outil de facturation, un vieux serveur, l'application d'un collègue.
  • Ils révèlent les personnes qui tentent d'envoyer de faux emails avec votre domaine.
  • Vous en avez besoin avant de faire passer le DMARC de p=none à quarantine ou reject, pour être sûr que rien de légitime ne sera bloqué.

Les grandes parties d'un rapport

Qui a envoyé le rapport

Dans report_metadata : org_name (par exemple google.com), un report_id et une date_range, en général 24 heures, écrite sous forme de timestamps Unix.

Votre politique publiée

Dans policy_published : l'enregistrement DMARC vu par le serveur de réception, comme p=none et les modes d'alignement.

Un bloc par source

Chaque record décrit une IP d'envoi :

<source_ip>203.0.113.10</source_ip>
<count>42</count>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
<header_from>yourdomain.com</header_from>
  • count : le nombre d'emails venant de cette IP.
  • disposition : ce qu'a fait le serveur de réception (none, quarantine, reject).
  • dkim et spf sous policy_evaluated : le résultat DMARC, qui exige que le domaine corresponde à celui de votre adresse From. Un seul « pass » suffit pour que le DMARC passe.
  • auth_results : les contrôles SPF et DKIM bruts, avec le domaine réellement vérifié. Comparez-le avec header_from pour comprendre les échecs d'alignement.

Comment les utiliser

  1. Identifiez chaque IP. Cherchez son nom reverse DNS ou son propriétaire. Des noms comme google.com, outlook.com ou le domaine de votre outil de newsletter sont en général les vôtres.
  2. Classez-les en trois groupes :
    • Vos services, qui passent : rien à faire.
    • Vos services, qui échouent : ajoutez-les au SPF, ou configurez le DKIM avec votre domaine dans ce service.
    • Des IP inconnues qui échouent partout : probablement de l'usurpation. Votre future politique reject les bloquera.
  3. Suivez la tendance pendant quelques semaines avant de durcir votre politique.

À noter : les emails transférés et les listes de diffusion apparaissent souvent comme des échecs venant d'IP que vous ne connaissez pas. Un petit nombre est normal.

Simplifiez-vous la vie

Lire du XML à la main devient vite fastidieux quand vous recevez beaucoup de rapports. Utilisez une boîte dédiée pour le rua, et envisagez un outil qui collecte et résume les rapports. La surveillance DMARC du tableau de bord payant le fait pour vos domaines.

Vérifiez que ça fonctionne

Analysez votre domaine sur /domain-scanner pour confirmer que l'enregistrement DMARC contient une adresse rua valide. Les rapports commencent en général à arriver sous un ou deux jours, de la part des fournisseurs qu'utilisent vos destinataires.

Vérifiez que c'est corrigé

Une modification DNS peut prendre de quelques minutes à quelques heures. Ensuite, envoyez un nouvel email de test ou scannez à nouveau votre domaine.

Fiches liées