Lire vos rapports DMARC

Si votre domaine a un enregistrement DMARC, les grandes messageries vous envoient chaque jour un rapport — un fichier XML compressé — qui liste tous les serveurs ayant envoyé du courrier au nom de votre domaine. C’est la seule liste que vous obtiendrez jamais de tout ce qui envoie en votre nom, y compris les recoins de votre propre entreprise que vous aviez oubliés.

Chargement de l’outil…

Comment ça marche

  1. Récupérez les pièces jointes dans la boîte que désigne votre enregistrement DMARC (l’adresse rua=), ou faites-les glisser directement depuis le message.
  2. Déposez-les toutes ici d’un coup : .xml, .xml.gz et .zip sont acceptés.
  3. Regardez d’abord les sources en échec : chacune est soit quelque chose à vous qu’il faut corriger, soit quelqu’un qui usurpe votre domaine.

Pourquoi rien n’est envoyé

Toutes les opérations de cette page sont effectuées par du code qui tourne dans l’onglet de votre navigateur, avec le moteur qui affiche les pages web. Le fichier est lu depuis le disque vers la mémoire de l’onglet, transformé sur place, puis réécrit sous forme de téléchargement. Il n’est jamais envoyé où que ce soit — ni à nous, ni à un tiers.

Vérifiez-le vous-même

  1. Ouvrez les outils de développement de votre navigateur (F12) et choisissez l’onglet « Réseau ».
  2. Chargez votre fichier et lancez l’outil.
  3. Les seules requêtes que vous verrez téléchargent le code de l’outil lui-même — et, pour quelques outils lourds, leur moteur open source depuis un CDN public — plus un petit signal de visite vers loreatec.jp (adresse et titre de la page, rien de plus). Aucune ne transporte votre fichier.

La preuve que tout reste chez vous →

Questions fréquentes

Pourquoi mes rapports arrivent-ils en .gz et en .zip ?

La norme laisse le choix à chaque organisme qui édite les rapports. Google envoie du .zip, Microsoft et la plupart des autres du .xml.gz. Ce lecteur ouvre les trois dans le navigateur : le gzip par la décompression intégrée au navigateur, le zip par une bibliothèque libre embarquée.

Une source passe le SPF mais échoue au DMARC. Comment ?

C’est ce que le DMARC appelle l’« alignement ». Un SPF qui passe signifie qu’un domaine a autorisé ce serveur — mais le domaine contrôlé est l’adresse de retour cachée, pas la ligne From que vos destinataires voient. Le DMARC exige en plus que les deux correspondent. Un service d’envoi qui expédie avec sa propre adresse de retour passe le SPF pour lui-même et rate l’alignement pour vous. La solution : configurer chez ce service une adresse de retour personnalisée (return-path), ou vous appuyer sur un DKIM signé avec votre propre domaine.

Que faire avant de passer à p=reject ?

Chaque source en échec de ce tableau doit être identifiée. Certaines seront légitimes : un vieux serveur, un CRM, un prestataire de paiement, un scanner. Chacune a besoin d’un SPF ou d’un DKIM correctement configuré. Ce qui reste ensuite, c’est de l’usurpation, et la rejeter est tout l’objectif. Si vous passez à reject alors que des sources non identifiées figurent encore dans la liste, du vrai courrier sera perdu sans le moindre avertissement.

Ces fichiers quittent-ils mon navigateur ?

Non. Ils sont décompressés et analysés ici. Cela compte plus que d’habitude avec les rapports DMARC : ils contiennent les adresses IP de tout ce qui envoie en votre nom, c’est-à-dire une carte de votre infrastructure.

Et les rapports d’échec (ruf) ?

Ce ne sont pas des synthèses : chacun correspond à un seul message en échec, envoyé sous forme d’e-mail ordinaire. Ouvrez-le avec le lecteur de .eml ou l’analyseur d’en-têtes. La plupart des grands destinataires n’en envoient pas du tout, pour des raisons de vie privée.