Analyseur DMARC : les fonctions qui comptent vraiment

Critère 3 — La tendance dans le temps, pas une photo

Un rapport isolé est un instantané. Il montre l'état d'un jour. Le problème : beaucoup de sources n'émettent pas tous les jours. La plateforme qui envoie la newsletter mensuelle, l'outil RH qui édite les bulletins de paie une fois par mois, le prestataire événementiel qui n'écrit que deux fois par an — aucun n'apparaîtra dans un instantané pris le mauvais jour. Durcir une politique sur la foi d'une seule photo, c'est risquer de casser une source légitime tout simplement pas encore vue.

Un vrai analyseur conserve un historique et montre l'évolution : les sources qui apparaissent, celles qui se dégradent lentement, celles qui n'émettent qu'épisodiquement. Sans historique, la décision de passer en reject ne se prend pas en confiance, faute de savoir si les rapports sont propres durablement ou juste propres aujourd'hui. C'est aussi ce qui permet de comparer un avant/après à chaque modification de configuration : une clé DKIM est publiée, et la courbe d'alignement doit remonter dans les jours qui suivent.

Ce critère compte davantage à mesure que l'écosystème se complexifie. Un domaine avec deux sources quotidiennes verra vite si tout est propre ; un domaine avec des sources mensuelles a besoin de plusieurs semaines d'historique avant toute décision.

Critère 4 — La remédiation actionnable, pas un dump XML

C'est le critère qui sépare vraiment les outils matures des visualiseurs. Beaucoup d'analyseurs s'arrêtent à « voici les données, joliment mises en forme ». C'est mieux que du XML brut, mais tout le travail d'interprétation reste à faire. Un outil mature dit quoi faire : « la plateforme marketing signe en DKIM avec son propre domaine, pas celui de l'expéditeur — voici l'enregistrement à publier » ou « cette source SPF déborde la limite de lookups, il faut aplatir l'enregistrement ».

La différence en pratique : sans conseil, on constate qu'une source échoue et il reste à deviner pourquoi et comment la réparer — souvent en cherchant sur le web pendant une heure. Avec conseil, l'outil livre la correction précise, dans l'ordre de priorité. C'est exactement là que le copilote de DMARC.com, Thomas, se distingue : il n'ajoute pas un tableau de bord de plus, il transforme les données en plan d'action aligné sur le chemin de p=none à p=reject. La visualisation dit quoi ; le conseil dit quoi faire. Les deux ne jouent pas dans la même catégorie.

Ce critère compte pour tout le monde, et particulièrement pour qui n'a pas d'expert DMARC sous la main. Un expert maison se contente de bonnes données ; à défaut, le conseil vaut de l'or.

Critère 5 — Les alertes sur les événements qui comptent

DMARC n'est pas un projet ponctuel, c'est un monitoring continu. Or personne ne se connecte à un tableau de bord tous les jours. C'est pour ça que l'alerte est un critère structurant : l'outil doit prévenir quand quelque chose mérite l'attention, sans qu'il faille aller le chercher. Deux événements comptent particulièrement. Le premier : une nouvelle source apparaît — un service jamais vu se met à envoyer au nom du domaine. C'est soit un nouveau prestataire légitime à aligner, soit une tentative d'usurpation. Dans les deux cas, l'information est urgente. Le second : une source connue qui commence à échouer — une clé DKIM qui a expiré, un enregistrement SPF qui a changé, et voilà une source jusque-là propre qui se met à tomber.

Un outil sans alerte condamne à découvrir les problèmes par hasard, ou pire, quand un client se plaint de ne pas avoir reçu un email. Un outil qui alerte se comporte comme un bon système d'alarme : silencieux quand tout va bien, audible quand quelque chose cloche. D'où une question à poser à l'évaluation : sur quels événements l'outil sait-il alerter, et par quel canal (email, webhook, intégration) ?

Ce critère prend de l'importance avec la taille du parc. Un domaine unique très stable peut vivre sans alertes ; dès que plusieurs domaines entrent en jeu, l'alerte devient la seule façon réaliste de ne pas rater un incident sur un domaine secondaire.

Critère 6 — La couverture multi-domaines et sous-domaines

Un domaine unique sans sous-domaines actifs rend ce critère sans objet. Sinon, il est décisif. Deux dimensions se cachent derrière. D'abord le multi-domaines : tous les domaines (filiales, marques, domaines parqués) se supervisent-ils depuis une vue consolidée, ou faut-il jongler entre autant d'interfaces que de domaines ? Un incident sur un domaine secondaire passe inaperçu si chaque domaine est isolé dans son propre silo. Ensuite les sous-domaines : DMARC gère la politique des sous-domaines via les balises sp (sous-domaines existants) et np (sous-domaines inexistants). Un attaquant qui ne peut plus usurper exemple.fr tentera mail.exemple.fr. Un bon analyseur montre le trafic par sous-domaine et aide à régler sp et np, pas seulement la politique racine.

Pour un prestataire ou une grande organisation, c'est souvent le critère de choix numéro un. Pour un artisan avec un seul domaine, c'est du superflu. Mieux vaut être honnête sur sa situation avant de payer pour une couverture dont personne n'a l'usage.

Critère 7 — La gestion des rapports forensiques (RUF) dans le respect de la vie privée

Les rapports RUF (forensiques) sont une autre bête que les RUA (agrégés). Là où le RUA ne contient que des IP et des statistiques, le RUF peut embarquer des en-têtes de messages réels — donc potentiellement des données personnelles. Tous les outils ne les gèrent pas, et parmi ceux qui les gèrent, tous ne le font pas proprement. Un bon analyseur, s'il traite le RUF, doit le faire avec des garde-fous : rédaction des données sensibles, rétention courte et paramétrable, hébergement maîtrisé. Un outil qui aspire des rapports forensiques bruts et les stocke indéfiniment sur un cloud opaque crée un problème de conformité qui n'existait pas.

À noter : beaucoup d'écosystèmes réduisent aujourd'hui l'usage du RUF, et il est parfaitement défendable de le laisser désactivé. Le point de vigilance à l'achat, c'est : si l'outil propose le RUF, comment protège-t-il ces données ? Ce critère pèse surtout pour les organisations soumises à des exigences de confidentialité fortes (secteur public, santé, finance). Pour un usage simple, le RUA suffit amplement.

Critère 8 — La rétention des données et l'export

Deux questions à poser à tout candidat. Combien de temps l'outil conserve-t-il l'historique ? Et les données sont-elles exportables à volonté ? La rétention détermine la capacité à détecter les dérives lentes : une source qui se dégrade sur trois mois ne se voit pas sur sept jours d'historique. Beaucoup d'offres gratuites plafonnent à 7 ou 30 jours ; pour un vrai suivi, viser 90 à 180 jours est plus sain. L'export, lui, est l'assurance anti-enfermement : changer d'outil, verser les données dans un SIEM, ou simplement garder une archive suppose de pouvoir sortir les rapports. Un outil qui séquestre les données est un outil dont on devient prisonnier.

Ce critère compte pour tout le monde, mais la barre monte avec les exigences de conformité. Dès qu'il faut prouver une posture dans le temps à un auditeur, une rétention courte devient un handicap réel.

Critère 9 — Le signalement de l'aptitude à BIMI

Dernier critère, plus prospectif. Quand afficher son logo dans les boîtes de réception (BIMI) fait partie des objectifs, l'outil idéal situe l'avancement sur ce chemin. BIMI exige une politique d'application (quarantine ou reject, souvent reject) plus, pour le badge vérifié, un certificat. Un analyseur qui annonce « le domaine est en reject, l'étape BIMI est accessible » ou « il manque encore ceci » transforme un objectif marketing en checklist concrète. Ce n'est pas un critère éliminatoire, mais c'est un bel indicateur de maturité : un outil qui pense à BIMI est un outil qui pense au-delà du simple parsing.

Ce critère parle surtout aux marques pour qui la visibilité en boîte a une valeur business. Pour les autres, c'est un bonus, pas une nécessité.

Un exemple concret : deux analyseurs, un même domaine

Rien ne vaut une comparaison. Prenons un domaine réel : une PME qui envoie depuis son tenant Microsoft 365 et depuis une plateforme d'emailing pour ses campagnes. Deux sources, un objectif : passer en reject sans casser les campagnes.

Le premier analyseur reçoit les rapports, les parse, et affiche un tableau bien présenté : « 1 240 messages analysés, 78 % de conformité DMARC », avec un camembert et la liste des IP émettrices. C'est propre. C'est lisible. Et ça n'avance à rien : les 22 % d'échecs sont visibles, mais rien ne dit ni d'où ils viennent précisément, ni pourquoi, ni comment les corriger. Du XML brut troqué contre du XML joli. Le travail d'interprétation, lui, reste entièrement à faire.

Le second analyseur regarde les mêmes rapports et livre un verdict en français : « La plateforme marketing et le tenant M365 envoient tous les deux sans alignement. Pour M365 : le SPF passe mais DKIM n'est pas activé — la signature DKIM est à activer dans le centre d'administration. Pour la plateforme marketing : elle signe en DKIM avec son propre domaine ; l'ajout de cet enregistrement CNAME à la zone DNS alignera sa signature sur le domaine expéditeur. Une fois ces deux corrections en place, l'alignement atteindra ~99 % et le durcissement vers reject se fera sans risque. » Voilà la différence. Le premier montre un problème ; le second tend la solution, dans l'ordre, avec l'enregistrement DNS exact à publier.

Lequel choisir ? La réponse est évidente dès qu'on la pose ainsi. Le second économise des heures de recherche et, surtout, il fait avancer vers reject. Le premier laisse au point de départ, avec de plus belles couleurs. C'est exactement ce que recouvre le critère 4 : la visualisation n'est pas de la remédiation. Pour approfondir la manière de comparer plusieurs candidats, comment choisir son outil DMARC déroule une méthode complète, et outil DMARC gratuit ou payant aide à trancher entre le gratuit qui suffit et le moment de passer à la caisse.

Les signaux d'alarme à l'évaluation

Certains indices doivent faire reculer. En vrac, les principaux drapeaux rouges :

• L'outil montre des IP sans jamais les nommer. Laisser deviner à qui appartient 40.107.22.15, c'est laisser le plus dur du travail. Critère 1 non rempli, candidat écarté.
• Aucun détail SPF/DKIM par source. Un chiffre de conformité global sans décomposition est joli mais inactionnable. Le quoi corriger restera un mystère.
• Pas d'historique, juste l'instant présent. Sans tendance, la décision de politique se prend sur une photo — et une source mensuelle jamais vue finit cassée.
• Zéro alerte. Un outil qui ne prévient de rien laisse découvrir les incidents par la plainte d'un client. Un tableau de bord qu'on oublie ne sert à rien.
• Rétention opaque ou export impossible. Ignorer combien de temps les données restent, et comment les récupérer, c'est signer pour un enfermement.
• RUF stocké sans garde-fou. Un outil qui aspire des rapports forensiques bruts et les garde indéfiniment sur un cloud flou fabrique un risque RGPD de toutes pièces.
• Que du conseil générique. « Publiez un enregistrement DMARC » sans regarder les sources réelles, c'est un article de blog déguisé en produit. Le conseil doit être ancré dans les données du domaine.
• Impossible de tester sans carte bancaire. Un bon analyseur laisse voir ses propres sources avant de réclamer un paiement. Un engagement à l'aveugle est un mauvais signe.

Aucun outil ne coche parfaitement toutes les cases, mais deux ou trois de ces drapeaux rouges cumulés désignent un jouet, pas un outil de travail.

En une phrase

Un vrai analyseur DMARC identifie les sources, décompose leur alignement, garde l'historique, et désigne quoi corriger — pas seulement à quoi ressemble le problème. Le choix se fait en fonction d'une réalité concrète : un domaine unique et stable se contente de l'essentiel, un parc multi-domaines exige alertes et couverture large. Et « payant » ne veut pas dire « meilleur » : le bon outil est celui adapté au contexte, gratuit compris. À l'échelle du web, l'Observatoire DMARC donne une idée des tendances de posture bien au-delà d'un seul domaine.

Le plus rapide pour s'en faire une idée : passer un domaine à l'analyseur DMARC gratuit et regarder ce qu'un outil montre vraiment de sources réelles. Quelques secondes suffisent à voir si l'identification, le détail par source et le conseil sont bien là — la grille de ce guide fournissant le barème. Un résultat qui débouche sur un plan d'action clair vers p=reject est la signature du bon type d'outil. Reste ensuite à aligner les sources pour de bon : créer un compte et laisser Thomas mener le domaine jusqu'à reject.