Lecteur de rapports DMARC

Les rapports DMARC arrivent en pièces jointes XML compressées qu’aucune application de messagerie ne sait afficher. Déposez-les ici pour obtenir un tableau de chaque serveur qui a envoyé des e-mails au nom de votre domaine, trié selon ce que vous devez en faire.

Les rapports sont ouverts et lus dans votre navigateur. Les fichiers ne sont pas envoyés et rien n’est conservé.

Un décompte quotidien de chaque fournisseur de messagerie

Un enregistrement DMARC est une ligne dans le DNS de votre domaine. L’une de ses balises, rua=mailto:reports@yourdomain.com, demande à chaque fournisseur qui reçoit du courrier prétendant venir de votre domaine d’envoyer un résumé à cette adresse. Google, Microsoft, Yahoo et bien d’autres le font, en général toutes les 24 heures.

Ces rapports « agrégés » ne contiennent ni texte de message ni nom de destinataire, seulement des décomptes. Chaque ligne dit qu’une adresse IP a envoyé un certain nombre de messages avec votre domaine dans la ligne From et comment ces messages ont été notés :

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>312</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>yourdomain.com</header_from></identifiers>
  <auth_results>…</auth_results>
</record>

Un seul domaine avec quelques services d’envoi reçoit facilement plusieurs fichiers par jour, chacun avec des dizaines de lignes. Le lecteur les additionne pour que vous n’ayez pas à le faire.

Pourquoi un succès peut quand même échouer : l’alignement

DMARC repose sur deux vérifications plus anciennes. SPF demande si le serveur expéditeur a le droit d’envoyer pour le domaine de l’adresse de retour cachée. DKIM demande si le message porte une signature valide d’un domaine quelconque. Ni l’un ni l’autre ne regarde la ligne From qu’une personne lit.

DMARC établit ce lien. Un message réussit DMARC quand SPF ou DKIM réussit pour un domaine qui correspond à la ligne From. Cette correspondance s’appelle l’alignement. Un service de newsletter peut réussir SPF pour son propre domaine et signer chaque message avec sa propre clé DKIM, tout en échouant à DMARC pour vous, parce qu’aucun de ces résultats ne mentionne votre domaine.

Dans un rapport, policy_evaluated contient les résultats alignés et auth_results les résultats bruts avec les domaines concernés. Le lecteur utilise le premier pour ses étiquettes « Aligné » et affiche le second en petites notes dessous, pour que vous voyiez quel domaine a réussi.

Comment le lecteur trie les expéditeurs

Les lignes sont fusionnées par adresse IP sur tous les fichiers déposés, puis regroupées par service. Si l’option de nommage est activée, notre serveur cherche le nom DNS inverse et le propriétaire du réseau de chaque adresse. Une trentaine de services courants, de Google et Microsoft 365 à SendGrid, Mailchimp et Amazon SES, sont reconnus par ces noms. Chaque adresse reçoit l’une de cinq étiquettes :

ÉtiquetteRègle
À vous, conformeChaque message de cette adresse avait un SPF aligné ou un DKIM aligné.
À vous, partiellement conformeCertains messages étaient alignés, d’autres non. Souvent c’est un service dont deux flux de courrier sont configurés différemment.
À vous, à corrigerRien n’était aligné, mais l’adresse appartient à un service reconnu, réussit pour un autre domaine, ou a un nom inverse sous votre propre domaine. C’est presque sûrement un outil que vous utilisez et qui n’a jamais été configuré pour votre domaine.
Probable transfertRien n’était aligné, mais le message portait une signature DKIM de votre domaine. Il a été envoyé correctement, puis modifié ou relayé par une liste de diffusion ou un transfert automatique.
Probable usurpationRien n’était aligné et rien ne relie l’adresse à vous.

Le résumé en haut donne le volume total, la part conforme (vert à partir de 98 %, orange à partir de 75 %), le nombre de messages d’expéditeurs inconnus et la politique que les rapports disent que vous publiez.

Les deux dernières étiquettes sont des déductions tirées de noms et de signatures, ne les prenez donc pas pour des faits. Un petit fournisseur de messagerie régional peut être inconnu du lecteur et pourtant être le vôtre. Avant de traiter une source comme hostile, regardez son volume, son nom inverse et les domaines From qu’elle a utilisés.

Du tableau à une politique appliquée

  1. Corrigez chaque groupe « à corriger ». Dans les réglages du service, cherchez « authentification du domaine », « domaine d’envoi » ou « DKIM ». Il vous donnera deux ou trois enregistrements DNS à publier, généralement des CNAME. Une fois en place, le service signe avec votre domaine et les lignes passent au vert dans les rapports suivants.
  2. Laissez les transferts tranquilles. Vous ne pouvez pas réparer ce qu’un tiers relaie. Ces lignes restent petites.
  3. Durcissez la politique. Quand vos propres expéditeurs sont conformes depuis deux à quatre semaines, changez p=none en p=quarantine, puis plus tard en p=reject. Une balise pct inférieure à 100 n’applique la politique qu’à cette part des e-mails en échec. Retirez-la à la fin.

Pour examiner l’enregistrement lui-même, il y a le bilan SPF, DKIM et DMARC. Pour en écrire un nouveau, utilisez le générateur d’enregistrements.

Le format a ses limites. Un rapport ne couvre que les fournisseurs qui envoient des rapports et que la période de sa plage de dates et il ne dit jamais à quelle personne ou campagne appartenait un message. Le lecteur accepte jusqu’à 200 fichiers à la fois, de 50 Mo chacun et ignore les doublons.

Questions fréquentes

Comment ouvrir un rapport XML DMARC ?

Enregistrez la pièce jointe de l’e-mail de rapport et déposez-la telle quelle sur cette page. Le lecteur décompresse lui-même les archives .zip et .gz et accepte de nombreux fichiers à la fois.

Pourquoi mon rapport montre-t-il SPF réussi mais DMARC échoué ?

SPF a réussi pour le domaine du return-path, qui appartient au service qui a envoyé le message, pas pour votre domaine. DMARC exige un succès aligné avec l’adresse From. Le correctif habituel est d’activer DKIM pour votre propre domaine dans ce service.

Qui sont les adresses IP inconnues de mon rapport DMARC ?

C’est l’une de trois choses : un service que vous utilisez et que vous avez oublié, un transitaire qui relaie vos vrais e-mails, ou quelqu’un qui falsifie votre domaine. Le nom inverse et le propriétaire du réseau affichés sous chaque adresse vous le disent généralement.

Combien de temps rester à p=none ?

Assez longtemps pour voir chaque expéditeur légitime apparaître dans les rapports et le rendre conforme, ce qui prend en général quelques semaines. N’oubliez pas les envois mensuels et trimestriels, comme les factures ou les newsletters, avant de durcir.

Mes rapports DMARC sont-ils envoyés sur votre serveur ?

Non. Votre navigateur fait la décompression et l’analyse. Si vous laissez l’option de nommage cochée, la liste des adresses IP expéditrices est envoyée à notre serveur pour qu’il cherche leurs noms et rien n’est conservé.

Quelle est la différence entre les rapports rua et ruf ?

rua demande les rapports agrégés que lit cette page, qui sont des décomptes quotidiens par adresse expéditrice. ruf demande des rapports forensiques sur des messages individuels en échec. Peu de fournisseurs en envoient, pour des raisons de vie privée et ce lecteur ne les gère pas.

Vérifications liées