DMARC dans les questionnaires de sécurité fournisseurs

Ce que l'évaluateur vérifie réellement

La plupart des cases d'un questionnaire sont invérifiables de l'extérieur. Politique de mots de passe, chiffrement au repos, sensibilisation des équipes : l'évaluateur enregistre la déclaration, sans moyen de la contrôler. La ligne DMARC est d'une autre nature, car la politique est publiée dans le DNS public. Une requête suffit :

dig TXT _dmarc.exemple.fr +short
"v=DMARC1; p=reject; rua=mailto:dmarc@exemple.fr"

Un évaluateur outillé ne se contente pas de lire la balise p=. Il regarde si rua= est présent — des rapports collectés signalent une surveillance réelle, pas un enregistrement posé et oublié. Il vérifie que les sous-domaines sont couverts et qu'aucun sp=none discret ne vide la protection. Il repère le mode test de DMARCbis (t=y), qui suspend l'application de la politique — l'équivalent moderne de l'ancien pct=0, que le standard actuel a supprimé. Il contrôle SPF et la présence de sélecteurs DKIM sur les mêmes domaines, parfois l'existence d'une politique MTA-STS. Et tout cela s'automatise : les plateformes de notation des tiers scorent ces éléments en continu, sans même envoyer de questionnaire.

Autrement dit, la case DMARC est probablement la seule du classeur dont l'acheteur connaît déjà la réponse avant de lire la déclaration. C'est ce qui la rend si dangereuse pour qui répond vite — et si précieuse pour qui répond juste.

Répondre honnêtement, selon l'état réel

Trois situations, trois bonnes réponses.

La politique est en p=reject ou p=quarantine. La réponse est simple : oui, avec l'enregistrement DNS en pièce jointe, la liste des domaines couverts et une phrase sur la surveillance des rapports. C'est une occasion de marquer des points à peu de frais : peu de répondants documentent aussi proprement.

Le déploiement est en cours, la politique encore en p=none. La tentation du « oui » approximatif est forte — « on a DMARC », techniquement vrai puisqu'un enregistrement existe. C'est la pire option : la contradiction avec le DNS public saute aux yeux du premier évaluateur outillé, et toutes les autres réponses du classeur deviennent suspectes d'un coup. La bonne réponse est un état documenté avec trajectoire datée : « politique p=none avec collecte et analyse des rapports depuis mars ; passage en p=quarantine planifié au T4 ; p=reject visé au T1 ». Aux yeux d'un évaluateur sérieux, ce niveau de précision vaut mieux qu'un « conforme » sec : il prouve que le sujet est piloté, budgété, daté. Un p=none assumé avec un plan crédible passe le filtre ; un « oui » que le DNS dément ne le passe jamais deux fois.

Rien n'est en place. L'admettre, et joindre un engagement daté plutôt qu'une promesse vague. Les questionnaires sont rarement éliminatoires ligne à ligne ; la cohérence d'ensemble pèse davantage qu'une case isolée. La liste de contrôle de 2026 fournit la trame d'un plan crédible à annexer à la réponse — inventaire des sources, collecte de rapports, durcissement progressif.

Côté acheteur : quoi demander, et vérifier en trente secondes

Pour l'organisation qui évalue ses fournisseurs, la ligne DMARC est une aubaine : c'est la seule dont la vérification coûte moins cher que la lecture de la réponse. Encore faut-il poser la bonne question. La formule fermée « DMARC est-il en place ? » appelle un oui creux ; les formulations utiles demandent la politique effective (p=) sur le domaine principal et les domaines de marque, l'identité de l'équipe ou de l'outil qui surveille les rapports, et le traitement des domaines non émetteurs.

La vérification tient ensuite en trente secondes : une requête TXT sur _dmarc. suivi du domaine du fournisseur, depuis n'importe quel poste, ou un analyseur en ligne qui restitue d'un coup politique DMARC, SPF et DKIM. La grille de lecture est directe. Un p=reject cohérent avec la déclaration crédibilise l'ensemble du questionnaire. Un p=none déclaré « conforme » est un signal d'alerte qui dépasse la messagerie : il mesure la sincérité du répondant. L'écart entre la réponse déclarée et l'état DNS observé est l'information la plus précieuse de tout le classeur — et elle est gratuite.

Un signal de maturité au-delà de l'email

Pourquoi accorder tant de poids à une ligne parmi trois cents ? Parce qu'une politique DMARC en application ne s'improvise pas. Elle suppose un inventaire exhaustif des flux d'envoi — y compris ceux que le marketing a branchés sans prévenir —, une gouvernance DNS fonctionnelle, une coordination entre équipes internes et prestataires, puis une surveillance continue pour que la politique survive aux changements. Une organisation qui a mené ce chantier au bout démontre une capacité de pilotage transverse qui dépasse largement la messagerie.

C'est une corrélation, pas une preuve : un domaine en p=reject peut coexister avec un système d'information négligé, et l'inverse existe aussi. Mais dans un exercice d'évaluation de masse où presque tout est déclaratif, un signal public, vérifiable et difficile à truquer vaut de l'or. Les évaluateurs le savent, et c'est précisément pour cela que la ligne est là.

Préparer la réponse standard

Plutôt que de redécouvrir la question à chaque classeur, les équipes rodées tiennent prête une réponse type, révisée à date fixe. Un paragraphe de référence ressemble à ceci :

L'ensemble des domaines d'envoi de l'entreprise publie une politique DMARC p=reject, avec alignement SPF et DKIM vérifié source par source. Les domaines non émetteurs sont verrouillés (v=DMARC1; p=reject; et SPF sans mécanisme d'émission). Les rapports agrégés sont collectés et analysés en continu via une plateforme dédiée ; l'apparition d'une source d'émission inconnue déclenche une alerte. Dernière revue : [date].

Les preuves à tenir prêtes en annexe : l'export des enregistrements DNS datés, une capture du tableau de bord de surveillance, la liste des domaines couverts, et — pour un déploiement en cours — le calendrier jalonné. Un point d'attention : cette réponse se périme. Un domaine acquis lors d'une fusion, un nouvel outil d'emailing branché par une filiale, et le paragraphe ment. La revue trimestrielle du paragraphe et de ses preuves fait partie intégrante de la réponse.

En résumé

La question DMARC s'est installée dans les questionnaires fournisseurs parce que l'évaluation des tiers est devenue une obligation — NIS2, DORA, ISO 27001 — et parce que l'email du fournisseur est un vecteur d'attaque direct contre ses clients. Sa singularité : la réponse est vérifiable dans le DNS public, en trente secondes, par n'importe qui. La seule stratégie tenable est l'honnêteté documentée — un p=none assorti d'une trajectoire datée vaut mieux qu'un « oui » que le DNS dément — et, côté acheteur, la comparaison systématique entre déclaration et réalité observée, qui en dit plus long que toutes les autres cases réunies.

Avant le prochain classeur, un passage du domaine par l'analyse DMARC gratuite montre exactement ce que verra l'évaluateur : politique effective, SPF, DKIM, couverture des sous-domaines. Et si l'état constaté ne correspond pas encore à la réponse espérée, créer un compte permet d'entamer la trajectoire vers p=reject avec des jalons datés — de quoi transformer, dès le prochain questionnaire, une case embarrassante en démonstration de maturité.