En mai 2025, un postmaster d’une infrastructure SaaS européenne a ouvert un ticket sur la mailing list IETF dmarc-discuss : son MTA rejetait les rapports RUA entrants parce qu’un parser maison refusait le nouveau schéma XML que DMARCbis avait commencé à tester. Le ticket n’a jamais eu de réponse officielle. Le 20 mai 2026, l’IETF a publié RFC 9989, RFC 9990 et RFC 9991, remplaçant officiellement RFC 7489 depuis 2015. Ce parser n’était pas un cas isolé.
Pour les équipes DevOps et postmasters qui maintiennent des pipelines de rapport DMARC, ces trois documents normalisent rigoureusement un standard qui avait fonctionné pendant onze ans comme document informationnel, sans jamais avoir le statut de Proposed Standard IETF. Ce statut change maintenant.
Ce qui change concrètement dans RFC 9989
RFC 9989 consolide la politique centrale : enregistrements, évaluation d’alignement, règles de correspondance organisationnelle. Le changement le plus opérationnel concerne la détermination du domaine organisationnel.
RFC 7489 s’appuyait sur la Public Suffix List (PSL) maintenue par Mozilla pour identifier le domaine racine d’un enregistrement DMARC. La PSL n’est pas un standard IETF ; c’est une liste collaborative, mise à jour par la communauté, qui pouvait créer des asymétries entre mailbox providers. RFC 9989 introduit le DNS Tree Walk : un algorithme qui remonte la hiérarchie DNS label par label jusqu’à trouver un enregistrement DMARC valide, sans dépendre de la PSL. En pratique, cela rend l’évaluation d’alignement plus déterministe entre les récepteurs, un avantage direct pour les domaines qui utilisent des sous-domaines d’envoi avec des politiques héritées.
Deux tags ont été supprimés dans cette révision. Le tag ri= (report interval, en secondes) disparaît : les mailbox providers l’ignoraient déjà universellement depuis des années, générant des rapports quotidiens quelle que soit la valeur configurée. Le tag rf= (report format) disparaît aussi ; le format XML des rapports agrégats est maintenant le seul format prévu, sans alternative possible.
Le retrait du paramètre de taille maximale des rapports (rua=mailto:reports@example.com!5m) complète cette liste. Ce mécanisme permettait de limiter les rapports agrégats à un volume en mégaoctets. Personne ne l’avait mis en place de manière cohérente.
pct= est mort : remplacez-le par t=y dans vos tests
Le tag pct= permettait d’appliquer la politique DMARC à un pourcentage du trafic : pct=25 pour tester l’impact d’un passage à p=reject sur un quart des messages. Utile en théorie ; ambigu en pratique, parce que les récepteurs interprétaient différemment ce que signifiait « appliquer la politique à X% ».
RFC 9989 supprime pct= et introduit t=y, un mode test explicite. Quand t=y est présent dans l’enregistrement, les récepteurs appliquent une politique dégradée : p=reject; t=y est traité comme p=quarantine, et p=quarantine; t=y comme p=none. Les rapports agrégats continuent d’être générés normalement. C’est un remplacement fonctionnel de l’ancienne approche p=none + monitoring manuel, avec une sémantique formalisée que les mailbox providers peuvent appliquer de façon uniforme.
Pour les opérations concrètes : si votre enregistrement contient encore pct=, il reste valide pour l’instant, la compatibilité ascendante est préservée. Mais les nouvelles implémentations n’interpréteront plus ce tag. La migration vers t=y n’est pas urgente en 2026 ; elle le deviendra à mesure que les récepteurs mettent à jour leur évaluation.
np= et le DNS Tree Walk : deux corrections ciblées sur les sous-domaines
L’angle mort historique de RFC 7489 sur les sous-domaines : un domaine configuré avec p=reject et sp=none laissait ses sous-domaines inexistants sans couverture claire. Un attaquant pouvant envoyer depuis login.billing.example.com, un sous-domaine qui n’existe pas dans le DNS, bénéficiait d’une zone grise que les mailbox providers géraient différemment.
RFC 9989 introduit le tag np= (non-existent subdomain policy), qui permet de spécifier explicitement la politique à appliquer pour les sous-domaines absents du DNS. Combiné au DNS Tree Walk, cela donne aux administrateurs un contrôle précis sur la hiérarchie d’héritage : p=reject; sp=quarantine; np=reject couvre maintenant trois niveaux distincts de scénarios d’envoi.
À noter : le DNS Tree Walk ne change pas le comportement pour les domaines qui gèrent déjà leur hiérarchie proprement. Il corrige surtout les cas où la PSL retournait des résultats inattendus sur des TLDs peu communs ou des domaines multi-niveaux.
RFC 9990 et 9991 : les formats de rapport changent aussi
RFC 9990 couvre les rapports agrégats (RUA). Le schéma XML est modernisé pour clarifier la structure des enregistrements de politique et améliorer la lisibilité des résultats d’alignement. Les outils qui parsent les rapports DMARC avec des parsers XML maison devront valider leur compatibilité avec le nouveau schéma. Le ticket mentionné en ouverture illustre exactement ce cas.
RFC 9991 couvre les rapports forensiques (RUF), ceux qui transmettent des copies de messages individuels en échec. Ces rapports étaient déjà rarement envoyés en pratique, pour des raisons de confidentialité (une copie de message individuel contient souvent des informations personnelles). RFC 9991 formalise leur format sans les rendre plus courants.
Les plateformes DMARC-as-a-service (DMARCReport, EasyDMARC, Postmark) ont annoncé des mises à jour de compatibilité RFC 9990 pour Q3 2026.
Ce qui ne change pas : la compatibilité ascendante tient
Les enregistrements existants commençant par v=DMARC1 restent entièrement valides. RFC 9989 ne casse rien. Un domaine configuré avec p=reject; rua=mailto:...@...com continue de fonctionner exactement comme avant : les récepteurs qui n’ont pas encore adopté RFC 9989 l’ignorent simplement et ceux qui l’ont adopté appliquent les nouvelles règles de manière rétrocompatible.
La question de la complaint rate et de la seedlist reste indépendante de ces RFC. Les seuils imposés par Google et Yahoo depuis début 2024 (taux de plaintes sous 0,3 %, désinscription en un clic conforme à RFC 8058) et par Microsoft depuis mai 2025 s’appliquent quelle que soit la version de DMARC évaluée. Ces exigences des mailbox providers précèdent RFC 9989 et coexistent avec elle.
Pourquoi il a fallu onze ans pour passer de RFC 7489 à RFC 9989
RFC 7489 était un document informationnel, pas un standard. Cette distinction IETF avait des conséquences pratiques : sans statut normatif, chaque mailbox provider pouvait interpréter les ambiguïtés à sa façon et il y en avait, sur la PSL, sur pct=, sur l’héritage des sous-domaines. Le groupe de travail DMARC de l’IETF (dmarc WG) a été formé en 2014. Un premier draft de révision a circulé en 2020 ; six ans de travail collectif ont abouti au DMARCbis, officiellement publié sous trois numéros RFC distincts.
L’ARC sealing (RFC 8617) et le BIMI (en cours de standardisation) s’appuient sur DMARC comme fondation normative. Avec RFC 9989, cette base passe du statut informationnel à celui de standard IETF.
Onze ans de retard rattrapés en trois documents.
