Résumé

  • Un résultat DMARC positif valide l'usage autorisé de l'Author Domain ; il ne certifie ni le contenu, ni l'intention, ni l'innocuité du message.
  • p=reject reste une préférence du Domain Owner. RFC 9989 confie le traitement final au Mail Receiver, qui doit pouvoir expliquer ses dérogations.

Prenons deux messages. Le premier passe DMARC, mais des signaux locaux indiquent une campagne abusive. Le second échoue après son passage légitime par une liste de diffusion. Une passerelle qui transforme « pass » en « sûr » et « fail » en « frauduleux » automatise deux erreurs opposées.

Publié en mai 2026 sur le Standards Track de l'IETF, RFC 9989 remplace les RFC 7489 et 9091. Sa notice, son historique IETF et ses errata fixent l'autorité documentaire, pas l'état d'un déploiement.

SPF relie une source SMTP à une identité autorisée. DKIM vérifie une signature de domaine. DMARC ajoute l'alignement, strict ou au niveau de l'Organizational Domain, avec le domaine visible dans RFC5322.From. Un identifiant authentifié et aligné suffit au pass ; sans identifiant aligné, le résultat est fail.

RFC 9989 borne aussitôt cette conclusion : le pass confirme seulement que l'usage de l'Author Domain a été autorisé. Il n'émet aucun jugement de valeur sur le message ou son propriétaire. Le destinataire peut donc bloquer un pass. Inversement, un fail ne prouve pas une fraude : RFC 7960 montre comment transferts, alias et listes peuvent casser l'authentification ou l'alignement d'un courrier légitime.

Le registre IANA DMARC consigne les paramètres du protocole. none, quarantine et reject sont des évaluations publiées par le Domain Owner. Elles renseignent utilement le destinataire, mais ne lui transfèrent ni le service rendu à l'utilisateur, ni ses données de réputation, ni les conséquences de l'acte.

Les sections 5.3.6 et 5.4 placent donc le traitement sous la politique locale du Mail Receiver. Celui-ci peut tenir compte de la préférence à sa discrétion. Le texte lui recommande même de ne pas rejeter uniquement parce que p=reject existe : un tel automatisme peut casser les flux indirects. Accepter un échec peut, à l'inverse, laisser entrer un abus. Cette tension doit produire une décision explicable, non une obéissance muette.

Une erreur DNS n'est pas un fail. Si les requêtes nécessaires n'aboutissent pas, DMARC ne peut conclure et la préférence du domaine ne s'applique pas. Le destinataire choisit alors report, acceptation ou autre mesure en conservant l'état « inconnu ».

La dérogation possède son propre reçu. RFC 9990 prévoit PolicyOverride pour communiquer le fait et le motif ; RFC 8601 permet de conserver Authentication-Results. Le rapport détaillé de RFC 9991 reste une divulgation facultative, non une délégation de décision.

La doctrine de Heng Lu sur la spécification initiale minimale permet à un signal partagé de coordonner sans centraliser. Ses couches de réalité séparent le symbole de l'exécution ; la primauté du code en fonctionnement oblige à vérifier quelle règle le destinataire a réellement appliquée.

La formulation exacte est donc : cette preuve a produit cet alignement, le domaine a exprimé cette préférence, puis le destinataire a pris cette décision pour ces raisons.