DMARC analyzer : comment lire ses rapports et identifier les expéditeurs qui échouent l’authentification

Vous avez posé rua=mailto:dmarc@votredomaine.com il y a six mois. Combien de rapports non lus dans votre inbox ? Pour la plupart des postmasters, la réponse dépasse les 500 fichiers. Chaque provider majeur (Gmail, Yahoo, Microsoft, Comcast) envoie un rapport XML par jour et par domaine. L’accumulation est rapide et l’essentiel finit ignoré.

Un rapport DMARC agrégé dit quelle IP a envoyé des emails au nom de votre domaine, combien ont passé SPF et DKIM avec alignement correct et ce que le provider a fait des messages qui ont échoué. Six champs suffisent pour lire n’importe quel RUA. Maîtriser ces six champs, c’est passer de « je stocke des rapports » à « je pilote mon infrastructure mail ».

L’adoption de DMARC a bondi de 27,2 % à 47,7 % entre 2023 et 2025 chez les domaines du top mondial, soit une hausse de 75 % en deux ans (Prospeo, 2026). Google et Yahoo ont exigé l’authentification DMARC pour tout envoi dépassant 5 000 emails par jour en février 2024 ; Microsoft a suivi avec des exigences similaires en mai 2025. Les domaines qui collectent des rapports sans les analyser exposent maintenant leurs expéditeurs tiers à une politique p=reject imposée par les providers, sans avoir jamais audité qui envoie réellement en leur nom.

Ce que contient vraiment un fichier RUA

Un rapport RUA est un fichier XML compressé en .gz. Son contenu se répartit en trois blocs : les métadonnées du rapport (qui l’a généré, pour quelle période), la politique publiée dans votre DNS au moment de l’envoi, puis une liste de record, un par combinaison d’IP source et de résultats d’authentification.

C’est ce troisième bloc qui compte. Chaque record contient le champ source_ip, un compteur de messages (count), les résultats SPF et DKIM bruts dans auth_results et les résultats d’alignement dans policy_evaluated. La distinction entre ces deux niveaux est l’angle mort classique : SPF peut afficher pass dans auth_results et simultanément fail dans policy_evaluated si le domaine d’enveloppe ne correspond pas au domaine de la balise From.

Le champ disposition clôt chaque enregistrement avec trois valeurs : none (livré), quarantine (spam folder) ou reject (bloqué). Un rapport avec 10 000 messages en disposition: none et policy_evaluated dkim: fail signifie que votre politique est encore à p=none. Les messages passent malgré l’échec, mais la réputation de l’IP s’en ressent sur la durée.

Les champs policy_evaluated : où les vrais échecs se cachent

Septembre 2024. Un postmaster constate que ses taux d’ouverture Gmail chutent, mais les logs de son MTA ne montrent aucun rebond. Les rapports DMARC révèlent 3 400 messages par jour depuis une IP qu’il ne reconnaît pas, tous en policy_evaluated dkim: fail. L’IP appartient à son outil de marketing automation, configuré six mois plus tôt par une agence, sans DKIM correctement signé sur le domaine principal.

auth_results reporte les résultats bruts SPF et DKIM tels que le serveur receveur les a évalués. policy_evaluated indique si ces résultats sont alignés avec le domaine du champ From. Un ESP qui signe DKIM avec son propre domaine (d=esp-provider.com au lieu de d=votredomaine.com) affichera dkim: pass dans auth_results et dkim: fail dans policy_evaluated. C’est ce second niveau que les analyzers visualisent en rouge — l’angle mort classique de tout diagnostic DMARC superficiel.

Identifier les expéditeurs fantômes par IP source

Le champ source_ip liste l’adresse IP du serveur qui a effectivement transmis le message. Un domaine correctement inventorié a une liste de plages IP connues : les IPs de son propre MTA, les ranges de ses ESPs, les IPs de ses outils SaaS. Tout ce qui sort de cette liste est un expéditeur non autorisé ou un service oublié.

En pratique, les rapports révèlent régulièrement plusieurs catégories d’expéditeurs inattendus. D’abord, les services SaaS signés par des équipes métier sans coordination IT : formulaires de contact, outils de survey, plateformes de e-commerce tierces. Ensuite, les anciens ESPs jamais décommissionnés dont les accès SMTP sont encore actifs. Et parfois, des IPs qui correspondent à des tentatives de spoofing, souvent identifiables par leur volume anormalement bas (1 à 5 messages) et leur absence totale de résultat DKIM.

Pour traiter une IP inconnue : faire un reverse DNS (dig -x [IP]), consulter les listes Spamhaus SBL/XBL/PBL et rechercher le range dans les ASN connus des ESPs. Une IP appartenant au range d’un service légitime mais avec policy_evaluated spf: fail indique généralement un service configuré sans alignement SPF strict. Ajout au TXT SPF requis ou signature DKIM sur votre domaine côté provider.

Un cas fréquent sur les domaines B2B avec plus de dix ans d’historique : une IP dans les rapports dont le reverse DNS pointe vers un ancien prestataire d’hébergement mail, jamais formellement décommissionné parce que personne n’avait le mot de passe du panneau de configuration. L’IP envoie 2 ou 3 messages par mois, trop peu pour déclencher une alerte volume côté MTA, suffisamment pour apparaître en rouge dans l’analyzer. Le compte SMTP actif depuis 2018 consomme tranquillement votre réputation de domaine. Identifier ce type de source via source_ip est impossible sans un rapport DMARC ; les logs MTA ne voient que le trafic sortant depuis vos propres serveurs.

RUF vs RUA : pourquoi les forensic reports ne sont pas la priorité

Les rapports forensic (RUF, champ ruf= dans le DNS) promettent une alerte en temps réel sur chaque message en échec, avec les headers complets. En pratique, Valimail documente plusieurs problèmes structurels qui limitent leur valeur opérationnelle.

La plupart des grands providers ont abandonné l’envoi de RUF : Gmail n’a jamais envoyé de RUF, Yahoo les a progressivement réduits et le support global s’est érodé. Les RUF peuvent aussi contenir des fragments de contenu des messages originaux, un risque de conformité RGPD réel pour les organisations européennes. En cas de campagne de spoofing active, ils peuvent générer des milliers d’emails par heure et saturer la boîte de réception de rapport au point de la rendre inutilisable. Les RUA agrégées couvrent 95 % des besoins opérationnels : elles identifient les IPs, les volumes et les patterns d’échec sans exposer le contenu des messages. La plupart des équipes postmaster sérieuses désactivent le ruf= et concentrent leur monitoring sur le rua=.

Si votre organisation doit activer les RUF pour un audit légal ponctuel, router ces rapports vers une boîte dédiée isolée de votre inbox principale, avec rétention limitée à 30 jours. Certains outils comme PowerDMARC proposent une gestion des RUF avec anonymisation automatique du contenu des messages. Pour le monitoring quotidien de la conformité DMARC, les RUA suffisent, sans les risques RGPD associés.

Comment passer de p=none à p=reject sans casser l’envoi

L’objection revient souvent : « J’ai lu toute la documentation des postmasters, je sais ce que disent les guides. » Le problème, c’est que les guides décrivent la progression linéaire (none, quarantine, reject) sans dire quand les rapports confirment qu’il est sûr de changer.

1. Pendant 2 à 4 semaines en p=none, extraire toutes les IPs uniques des rapports RUA. Un analyzer comme dmarcian ou EasyDMARC automatise cet inventaire. Chaque IP doit être assignée à un service connu et aligner SPF ou DKIM sur votre domaine.
2. Un taux de conformité DMARC supérieur à 95 % sur 14 jours consécutifs est le signal standard pour envisager le passage à p=quarantine. En dessous, des sources légitimes échouent encore.
3. Passer à p=quarantine; pct=10 d’abord. La directive pct applique la politique à 10 % des messages en échec seulement. Si une source est oubliée, l’impact reste limité. Surveiller les rapports pendant 7 jours avant d’augmenter le pourcentage.
4. Avant p=reject, vérifier que vos flux de redirection (mailing lists, aliases, forwards) bénéficient de l’ARC sealing chez les fournisseurs intermédiaires. Un message redirigé sans ARC échouera DMARC à l’arrivée même si l’envoi initial était conforme.

Le passage à p=reject sans avoir traité les flux de redirection est la cause principale des régressions après déploiement. Les rapports RUA post-reject montrent les victimes : des IPs légitimes en disposition: reject qui envoyaient depuis des mailing lists ou des alias de forwarding.

Choisir un DMARC analyzer : critères opérationnels

Valimail Monitor et le tier gratuit de dmarcian suffisent pour démarrer. Parsedmarc pousse les données vers Elasticsearch pour une analyse locale. Un seul critère d’évaluation : combien de clics pour trouver une IP inconnue ? Plus de trois, c’est trop lent.

Un angle mort persistant : un domaine peut afficher 99 % de conformité globale tout en ayant une source en full reject sur un sous-domaine transactionnel, parce que le volume de cette source est trop faible pour peser sur la moyenne. Les sous-domaines doivent avoir leur propre enregistrement DMARC avec rua= séparé.

Le standard DMARC date de 2015 ; ses mécanismes n’ont pas changé. Ce qui change, c’est la tolérance des providers envers les domaines qui collectent des rapports sans agir.