Résumé

  • Pour obtenir pass, DMARC exige qu’au moins un domaine authentifié par SPF ou DKIM soit aligné sur le domaine du champ RFC5322.From. Le reçu concerne l’usage autorisé du domaine auteur, pas l’identité humaine ou le contenu.
  • L’échec n’est pas la preuve inverse. Un transfert, une liste de diffusion ou un autre intermédiaire légitime peut rompre l’alignement SPF ou la signature DKIM avant l’arrivée chez le destinataire.
  • Les valeurs p, sp et np sont des préférences de traitement demandées dans le DNS. Le récepteur conserve sa politique locale : il peut bloquer un message conforme ou accepter un échec après analyse d’autres signaux.

Partir de la décision, puis remonter vers la preuve

Le dernier acte appartient au récepteur : remettre, mettre en quarantaine, rejeter, différer ou acheminer autrement. DMARC intervient avant cet acte, mais ne se confond pas avec lui. Cette chronologie est le meilleur moyen de lire la RFC 9989, publiée en mai 2026 sur le Standards Track, codirigée par Todd M. Herr et John Levine et destinée à remplacer les RFC 7489 et 9091.

Le propriétaire d'un domaine publie des données sur ses émetteurs et une préférence concernant les échecs. Le récepteur observe le message qui lui est réellement parvenu. Il réalise SPF et DKIM, compare les domaines, consulte le DNS, puis associe ces résultats à sa réputation locale, à ses outils antimalware, au contexte de l'utilisateur et à ses propres obligations. La RFC ne donne à aucun de ces acteurs la totalité du pouvoir descriptif.

Son énoncé central est d'une précision rare : un pass confirme seulement que l’usage du domaine auteur a été validé comme autorisé par son propriétaire. Cette autorisation n’énonce aucune valeur, explicite ou implicite, sur le message ou sur le propriétaire du domaine. Elle ne garantit pas qu’une livraison dans la boîte de réception soit sûre ou souhaitable.

SPF et DKIM n'authentifient pas la même scène

SPF part de la transaction SMTP. Le domaine publie quels hôtes peuvent employer son identité MAIL FROM ou HELO ; DMARC retient le domaine MAIL FROM. DKIM part du message signé. Une signature valide rattache les octets couverts à un domaine de signature. Dans les deux cas, le domaine authentifié peut être différent de celui du champ From que lit l'utilisateur.

DMARC ajoute donc une relation d'alignement. Le domaine extrait de RFC5322.From devient le domaine auteur. Un identifiant SPF ou DKIM valide doit être identique à ce domaine en mode strict, ou partager le même domaine organisationnel en mode souple. Les balises aspf et adkim expriment le choix du propriétaire ; la RFC observe que le mode souple suffit à presque tous les déploiements.

Une seule signature DKIM valide et alignée peut produire le pass, même si d’autres signatures ne passent pas. Du côté SPF, un résultat valide pour le domaine d’un transitaire ne suffit pas si ce domaine n’est pas aligné sur le From visible. Le verdict est donc un calcul de relation, pas un halo de confiance posé sur toute l’enveloppe.

Le domaine est prouvé ; le reste garde ses propres horloges

Dans une adresse qui associe la partie locale direction au domaine example.com, DMARC traite example.com. Il ne valide pas direction, ne prouve pas la possession de la boîte et n’atteste pas que la directrice a rédigé le texte. Le nom visible peut être celui d’une personne réelle alors que l’adresse appartient à un autre domaine. Un domaine ressemblant peut exploiter un caractère voisin. La RFC 9989 place explicitement les attaques par nom d’affichage et les domaines visuellement similaires hors de sa solution.

L'analyse du contenu est également hors champ. Un service autorisé peut être compromis. Un compte légitime peut envoyer un lien piégé. Un fraudeur peut enregistrer son propre domaine, en autoriser correctement les serveurs et signer proprement ses messages. Dans ces cas, DMARC fonctionne. Le contrôle qui manque se trouve ailleurs.

Il faut donc conserver plusieurs temps : moment de la signature, observation SPF, résolution DNS, calcul d’alignement, analyse du contenu, décision de la passerelle, placement dans le dossier et action ultérieure de l’utilisateur. Réduire ces temps au mot pass efface la provenance de la décision.

Pourquoi le courrier indirect produit des échecs honnêtes

La RFC 7960 montre que l'échec peut naître d'un trajet légitime. Un transfert qui conserve le MAIL FROM original émet depuis une adresse IP absente du SPF de l’expéditeur. S’il remplace ce MAIL FROM, son propre SPF peut passer mais ne plus être aligné sur le domaine auteur. Une liste de diffusion qui ajoute un préfixe d’objet, un pied de page ou transforme le MIME peut casser la signature DKIM initiale.

Le récepteur final ne voit pas forcément l’état qui existait au départ. Il voit les traces restées intactes après les médiateurs. fail signifie alors qu’aucun identifiant authentifié observé n’a satisfait l’alignement applicable ; il ne signifie pas que toute utilisation antérieure du domaine était nécessairement usurpée.

Cette asymétrie interdit deux raccourcis : accorder une confiance globale au pass et prononcer une culpabilité globale au fail. Les deux résultats doivent rester attachés à leurs entrées et à leur point d’observation.

Le DNS exprime une préférence, pas une prise de contrôle

La découverte de politique suit un ordre. Le récepteur interroge d’abord le domaine auteur exact, puis son domaine organisationnel et enfin son domaine suffixe public. Selon l’emplacement du record et l’existence du sous-domaine, la politique applicable provient de p, sp ou np. L’IANA les décrit comme des politiques demandées ; les balises plus anciennes pct, rf et ri sont désormais historiques dans le registre capturé.

Cette hiérarchie ne transforme pas le propriétaire du domaine en administrateur de la passerelle distante. La RFC 9989 dit que le traitement final relève toujours de la politique locale du récepteur. Celui-ci peut refuser un message qui passe, si les autres signaux sont mauvais. Il peut accepter un message qui échoue malgré p=reject, notamment pour protéger un flux indirect connu. Le texte recommande de ne pas rejeter uniquement à cause de cette valeur.

Une panne DNS rend la limite encore plus visible. Sans résultat complet, le message n’est ni pass ni fail et la préférence du domaine ne peut être appliquée comme si elle avait été découverte. Le récepteur choisit de livrer, de différer ou d’employer un autre traitement.

Dans The Policy Mirror, Heng Lu propose de demander à toute règle partagée si elle protège l’invariant technique nécessaire ou si elle capture une décision qui devrait rester locale. La RFC 9989 offre ici son propre exemple : rendre la demande distante lisible, tout en laissant le levier à l’opérateur qui supporte le risque de livraison.

La boucle de rapports reste incomplète par conception

Les rapports agrégés peuvent révéler des sources frauduleuses et, souvent plus utilement, les défauts d’authentification des flux légitimes du propriétaire. Mais un récepteur n’est pas tenu d’envoyer tout ce qui a été demandé. L’agrégé est recommandé ; le rapport message par message est facultatif, souvent censuré ou abandonné pour préserver la vie privée.

La présence de rua ou ruf prouve donc la destination souhaitée. Seul un rapport effectivement reçu prouve qu’un récepteur a communiqué une observation pendant une période. Même alors, il ne s’agit ni d’un recensement universel ni de la preuve que chaque message a subi le traitement demandé.

Une montée de p=none vers quarantine ou reject doit par conséquent reposer sur la cartographie des sources, les essais de transferts et de listes, la couverture réelle des rapports et une possibilité de retour en arrière. Le DNS n’absorbe pas le travail opérationnel.

Attribuer Todd Herr sans fabriquer un souverain du protocole

La photographie publique et la fiche IETF établissent l’identité publique de Todd Herr à la date de capture. La fiche mentionne RFC 9989 et un rôle de relecteur au sein de l’ART Area Review Team. Le document attribue l’édition à Herr, alors chez Valimail, et à John Levine, chez Standcore LLC. Ses remerciements montrent la profondeur du travail collectif remontant au consortium DMARC et à la RFC 7489.

Le profil d’une personne doit préserver cette distribution. Herr a contribué à un texte qui rend le bord du résultat particulièrement clair ; il n’a pas inventé seul DMARC, ne valide pas chaque signature et ne décide pas du sort des messages chez les récepteurs. La bonne attribution ne consiste pas à agrandir son autorité, mais à montrer la discipline que le texte a rendue publique.

Un registre de preuves que l'on peut auditer

Le journal utile rattache le message reçu à son From exact ; conserve chaque résultat SPF et DKIM, le domaine et le sélecteur ; indique le mode d’alignement et l’identifiant décisif ; enregistre le chemin DNS et la balise de politique ; décrit les transformations indirectes ; sépare réputation et contenu ; puis nomme la décision locale et son auteur opérationnel.

Ce registre empêche les héritages abusifs. Le domaine n’est pas la personne. L’alignement n’est pas la sincérité. Le pass n’est pas la sûreté. p=reject n’est pas l’exécution. L’acceptation SMTP n’est pas le dossier de réception. Et la réception ne prouve pas l’absence de dommage.

DMARC conserve alors toute sa force réelle : réduire l’usurpation exacte d’un domaine, stabiliser l’objet auquel attacher la réputation et fournir un retour sur les flux. Un petit reçu bien nommé vaut mieux qu’un verdict universel que le protocole ne saurait défendre.

Sources