Résumé

  • RFC 9991 permet au propriétaire d’un domaine de solliciter des rapports détaillés sur les échecs DMARC ; le serveur destinataire reste libre de produire ou non ces rapports et responsable des données qu’il transmet.
  • La vérification d’une adresse externe confirme qu’elle accepte une relation de reporting. Elle n’approuve ni le corps intégral, ni chaque identité, ni la conservation, ni les usages ultérieurs.
  • Un dispositif sûr conserve séparément l’échec observé, la demande DNS, la décision de divulgation, la réduction des données, l’envoi, l’interprétation et toute mesure prise contre un compte.

Une plateforme de messagerie détecte un échec DMARC sur un courriel légitime passé par une liste de diffusion. Le domaine visible a publié une adresse ruf chez un sous-traitant. Le rapport détaillé aiderait sans doute à comprendre l’altération de la signature. Il pourrait aussi révéler la liste des destinataires, l’objet de la discussion et le chemin suivi par le message.

Le protocole ne doit pas répondre à cette tension par une fiction. L’échec d’alignement est un fait technique. La transmission d’une communication à un tiers est un autre acte, avec une autre autorité et une autre preuve.

Trois acteurs, trois décisions

RFC 9991, publié en mai 2026 sur le Standards Track de l’IETF, décrit le rapport d’échec DMARC. Contrairement au rapport agrégé, il peut documenter un message particulier ou un groupe de messages échouant pour la même cause et arriver presque immédiatement.

Le propriétaire du domaine configure la demande. RFC 9989 porte les paramètres ruf et fo : destination souhaitée et conditions de l’échec. Cette publication DNS exprime un besoin de diagnostic. Elle ne réquisitionne pas les systèmes des destinataires.

Le Mail Receiver détient la deuxième décision. RFC 9991 prévoit qu’il génère le rapport lorsque le domaine le demande et qu’il est disposé à le fournir. Il choisit, selon sa politique et le cas rencontré, quel type de rapport transmettre, s’il en transmet un. C’est lui qui possède le message reçu, sert l’utilisateur final et connaît ses obligations de confidentialité.

Le Report Consumer détient la troisième décision. Recevoir un fichier ne prouve ni son authenticité complète, ni l’exactitude de toutes ses affirmations, ni la légitimité d’une sanction. Il doit valider l’origine, le format, le contexte et confronter les données à ses propres journaux.

Le partage des rôles n’affaiblit pas DMARC. Il empêche le domaine expéditeur de devenir, par une balise DNS, l’autorité de divulgation d’un autre opérateur.

Le rapport détaillé change la nature des données

RFC 9990 agrège des observations par période, adresse source, résultat et politique. Il donne une vue statistique utile pour trouver des émetteurs légitimes mal configurés ou une campagne d’usurpation.

Le rapport d’échec repose sur l’Abuse Reporting Format. RFC 5965 organise un message multipartite : explication lisible, champs exploitables par machine et copie du message original ou de ses en-têtes complets. RFC 6591 définit les données propres aux échecs d’authentification ; RFC 9991 les adapte à DMARC.

Cette granularité fait sa valeur forensique. Elle peut montrer une signature, l’identité DKIM, le résultat SPF, le chemin SMTP et le contenu qui a réellement échoué. Mais elle peut aussi transporter des données personnelles, des informations non publiques, une invitation d’agenda, une rupture de contrat ou la destination cachée d’un transfert.

La défaillance ne rend pas tout le message nécessaire. Une analyse peut exiger le domaine, le sélecteur et les résultats d’alignement sans exiger le corps. Une enquête temporaire peut justifier un échantillon là où un flux permanent serait disproportionné. RFC 9991 recommande justement un usage ciblé et limité dans le temps, la validation des URI, la minimisation, la caviardisation et un transport sûr. Il constate que de grands fournisseurs restreignent ou désactivent ces rapports et préfèrent souvent les agrégats.

Le choix utile n’est donc pas « tout ou rien ». Il faut une échelle : agrégat, métadonnées minimales, en-têtes sélectionnés, échantillon caviardé, puis contenu plus complet pour une enquête bornée et approuvée.

Autoriser l’adresse externe ne vaut pas autoriser le contenu

Le ruf peut viser un domaine extérieur : prestataire de délivrabilité, filiale, centre de réponse ou simple erreur. RFC 9991 reprend la procédure de vérification externe de RFC 9990. Le destinataire cherche l’autorisation publiée par le domaine externe avant d’émettre les rapports.

Cette réciprocité empêche qu’un domaine inscrive un tiers à son insu et qu’un attaquant transforme les serveurs du monde entier en générateurs de trafic vers une victime. Elle prouve que l’adresse accepte des rapports pour le domaine concerné.

Elle ne décrit pas le mandat du prestataire. Rien dans ce contrôle DNS ne fixe les champs lisibles par ses employés, la zone de stockage, la durée, les transferts secondaires ou les modèles analytiques alimentés. Une adresse qui redirige ensuite le courrier peut même cacher la destination finale.

Il faut donc superposer un contrat vérifiable : domaine demandeur, domaines destinataires, consommateur réel, finalité, profil de données, sous-traitants, durée, suppression et notification d’incident. La DNS doit concorder avec cet inventaire, pas le remplacer.

La règle applicable aux Public Suffix Domains est révélatrice. Un ruf publié avec psd=y ne doit pas être pris en compte sans accords spécifiques entre les parties intéressées. Plus la position dans la hiérarchie est large, moins il est acceptable de transformer une demande générique en collecte détaillée par défaut.

Identity-Alignment n’est pas un verdict sur une personne

RFC 9991 ajoute le champ Identity-Alignment. Le registre IANA MARF Parameters indique qu’il énumère les mécanismes n’ayant pas authentifié un identifiant aligné, ou none si toutes les tentatives ont réussi.

Le champ répond précisément à une question DMARC : DKIM, SPF ou les deux ont-ils échoué sur l’alignement ? Il ne répond pas à « qui a écrit ? », « qui a fraudé ? » ou « pourquoi le transfert a-t-il cassé la signature ? ».

Une interface qui réduit Identity-Alignment: dkim à « identité frauduleuse » fabrique une assertion absente du rapport. Le nom complet, les domaines évalués, le serveur d’évaluation, l’heure et les résultats bruts doivent accompagner toute interprétation.

Caviarder sans créer un identifiant parallèle

RFC 6590 propose une transformation cohérente des données privées. Deux valeurs identiques peuvent produire le même pseudonyme, ce qui permet de regrouper des rapports sans révéler immédiatement l’adresse.

Cette capacité de corrélation doit être gouvernée. Un jeton stable pendant plusieurs années devient un identifiant transversal. La clé, l’époque, le périmètre du consommateur et la durée de stabilité déterminent ce qu’il devient possible d’apprendre.

Surtout, le caviardage n’est pas l’anonymat. Message-ID, date, sujet rare, chemin Received ou journaux d’un autre acteur peuvent réidentifier le message. Un filtre automatique ne reconnaîtra jamais toutes les informations privées écrites dans une langue humaine. RFC 6590 le dit explicitement.

Un audit doit donc enregistrer le profil exact : champs supprimés, champs transformés, méthode, époque de clé, tests, exceptions et risque résiduel. Une simple mention « anonymisé » serait aussi trompeuse qu’un simple « DMARC pass » utilisé comme preuve d’identité humaine.

Le rapport lui-même peut être hostile

RFC 5965 avertit que les champs ARF sont des affirmations, pas des vérités automatiquement vérifiables. Le format ne garantit pas l’exactitude du générateur. Un rapport bien formé peut être faux ; un rapport authentifié peut contenir une pièce jointe malveillante ; un champ dérivé peut résulter d’une implémentation défectueuse.

Avant toute automatisation, le consommateur doit authentifier la relation de reporting, vérifier la structure et les tailles, isoler le contenu, comparer avec ses journaux et distinguer correction technique, restriction de compte et accusation. RFC 6449 traite les feedback loops comme des relations opérationnelles assorties d’attentes, non comme des boîtes publiques dotées d’un pouvoir de sanction.

RFC 9991 impose aussi un rate limit. Sans budget, un attaquant envoie des milliers de messages usurpant un domaine, fait échouer SPF et DKIM, puis laisse les destinataires amplifier les rapports vers ce domaine ou son prestataire. Le regroupement par condition et le champ Incidents permettent d'informer sans préserver la fiction d’un rapport par message.

Les liens actifs devraient être neutralisés et les pièces jointes supprimées. Le consommateur doit isoler le flux, mettre le contenu en bac à sable, segmenter le traitement et limiter l’accès. Les rapports devraient eux-mêmes être alignés DMARC afin d’éviter qu’un échec de rapport n’engendre une boucle de nouveaux rapports.

La réalité ne tient pas dans une seule case

La doctrine des couches de réalité de Heng Lu sépare ici sept faits : échec d’authentification, demande DNS, décision du destinataire, octets du rapport, livraison, interprétation et action. Une preuve à l’étage inférieur ne confère pas automatiquement le mandat du suivant.

Le principe de spécification initiale minimale et de décision future localisée justifie un standard commun pour les balises, les champs et la vérification externe, tout en laissant la divulgation à l’opérateur responsable du message et de l’utilisateur.

Enfin, la primauté du code en fonctionnement exige de retrouver l’exécution : évaluateur utilisé, politique chargée, branche de génération, transformateur, réponse DNS, hash transmis, consommateur réel et conséquence observée.

RFC 9991 rend le diagnostic plus précis. Sa précision la plus importante est institutionnelle : demander, divulguer, recevoir et agir ne sont pas un seul pouvoir.