Déposez les fichiers XML, gzip ou zip dans lesquels arrivent vos rapports DMARC et lisez ce qu’ils disent vraiment : quelle part de votre courrier réussit, quelles sources échouent, et lesquels de ces échecs sont une plateforme d’envoi à configurer plutôt que quelqu’un à bloquer. Chaque fichier est traité dans votre navigateur, sans inscription et sans rien envoyer.
Déposez ici vos rapports agrégés DMARC
Les rapports arrivent par e-mail en pièce jointe .xml, .xml.gz ou .zip. Ajoutez-en autant que vous en avez : un rapport correspond à un destinataire pour une journée. Ils sont lus dans ce navigateur et jamais envoyés.
Créez un compte Unspam gratuit pour enregistrer vos résultats et relancer ces vérifications à tout moment, afin de repérer une configuration défaillante avant qu’elle ne vous coûte cher. Sans carte bancaire.
Dès que votre enregistrement DMARC porte une adresse rua, les fournisseurs de messagerie vous envoient chacun un fichier XML par jour. Chaque fichier liste toutes les adresses IP qui ont envoyé du courrier en se réclamant de votre domaine, combien de messages sont partis de chacune, si SPF et DKIM ont authentifié, si l’un des deux correspondait à l’adresse de l’en-tête From, et ce que le destinataire en a fait. C’est la seule vue que vous aurez jamais de qui envoie sous votre domaine, et c’est la raison pour laquelle DMARC comporte une moitié consacrée aux rapports. Ces fichiers sont aussi illisibles à l’œil nu : une seule journée d’un gros fournisseur représente des milliers de lignes de XML, dans un schéma qui vient d’être révisé, avec deux colonnes qui ressemblent à la même question sans en être une. Cet outil lit les deux révisions, additionne les nombres de messages plutôt que les lignes et garde ces deux colonnes séparées, parce que l’écart entre elles est l’écart entre un enregistrement cassé et un enregistrement qui marche mais que vous n’avez pas encore aligné.
Le résultat d’alignement, et il ne prend que deux valeurs : pass ou fail. Il répond à une seule question, celle de savoir si un identifiant authentifié correspondait au domaine de l’en-tête From. C’est là-dessus que DMARC agit, et un domaine réussit si l’une des deux jambes réussit, pas les deux.
Le résultat d’authentification brut, avec sept ou huit valeurs dont softfail, temperror et permerror. Il répond à une autre question : SPF ou DKIM ont-ils abouti, pour le domaine contre lequel ils ont été vérifiés. Une ligne avec SPF pass ici et SPF fail au-dessus n’est pas une contradiction, c’est la signature d’une plateforme qui envoie avec son propre return path.
Le nombre de messages que représente une ligne, de un à plusieurs dizaines de milliers. Tous les totaux de cette page sont des sommes de ces valeurs, jamais des comptages de lignes. Compter les lignes est la façon la plus courante de mal lire un rapport agrégé, parce que la réponse reste plausible et va dans le bon sens tout en étant fausse de ce que donne la distribution des volumes.
L’adresse qui s’est connectée. C’est la liste à parcourir : triées par volume, les premières sources sont en général votre plateforme d’e-mailing, votre site, votre outil de tickets et votre propre serveur, et les reconnaître constitue l’essentiel du chemin vers une politique que vous pourrez appliquer.
L’erreur de lecture la plus courante, et celle qui pousse à modifier un DNS déjà correct. Si le résultat SPF brut est pass et le résultat d’alignement fail, SPF a fonctionné : il a authentifié le domaine de l’enveloppe, qui appartient à la plateforme qui envoie pour vous. La solution est un return path personnalisé sur votre domaine, ou l’alignement DKIM. Rien de ce que vous ajouterez à votre enregistrement SPF n’y changera quoi que ce soit.
Un fichier, c’est un destinataire pour une journée. Un fournisseur qui n’envoie aucun rapport y est invisible, tout comme chaque message qui n’a jamais atteint le seul fournisseur dont vous tenez un rapport. Chargez deux semaines de vos plus gros destinataires avant de conclure quoi que ce soit sur une source inconnue.
Un taux élevé dit que le courrier dont vous avez connaissance est authentifié. Il ne dit rien de celui que vous avez oublié, et les systèmes qu’on oublie sont ceux qui envoient rarement : facturation, réinitialisation de mots de passe, le CRM installé il y a deux ans. Parcourez la liste des sources jusqu’à pouvoir nommer chaque entrée, puis changez la politique.
La RFC 9989 a supprimé pct de DMARC. Un destinataire qui suit la spécification actuelle applique votre politique à chaque message en échec et non à la part demandée : un enregistrement resté en p=reject avec pct=25 rejette donc aujourd’hui quatre fois plus de courrier qu’avant, sans la moindre modification du DNS. Si un rapport chargé montre une balise pct, cet enregistrement mérite d’être repris.
Les rapports agrégés contiennent des nombres, des adresses et des résultats. Ils ne contiennent ni objets, ni corps de message, ni adresses de destinataires, et c’est ce qui rend leur envoi sans risque. Si vous devez voir un message en échec lui-même, il s’agit d’un rapport d’échec, chose distincte et bien plus rare que la plupart des fournisseurs n’envoient pas.
Quand un destinataire fait autre chose que ce que demandait votre politique, il le dit et donne un motif : une liste de diffusion, un réexpéditeur en qui il a confiance, sa propre politique locale. Ces lignes ne sont pas des défauts de votre configuration, et les poursuivre coûte le temps qui rapporte davantage sur les sources au-dessus.
