DMARC a changé de statut en mai 2026

par | Sep 7, 2026 | Emailing

Pendant onze ans, DMARC a été un document informatif. Publié en mars 2015 comme RFC 7489, il n’était même pas passé par le processus normatif de l’IETF : il est arrivé par la voie des soumissions indépendantes, avec le statut Informational.

Autrement dit, le mécanisme sur lequel Google, Yahoo et Microsoft ont fondé leurs exigences d’authentification n’était, formellement, la norme de personne.

C’est terminé depuis mai 2026.

Une RFC remplacée par trois

Le travail connu sous le nom de DMARCbis a abouti. La RFC 7489 est rendue obsolète par trois documents distincts, tous en Proposed Standard, tous issus cette fois du groupe de travail DMARC de l’IETF :

La RFC 9989 porte le mécanisme lui-même. Elle rend obsolètes la RFC 7489 et la RFC 9091, l’extension expérimentale pour les domaines de suffixe public, désormais intégrée au corps du texte.

La RFC 9990 spécifie les rapports agrégés, ces fichiers XML quotidiens que vous recevez à l’adresse déclarée dans le tag rua.

La RFC 9991 spécifie les rapports d’échec, message par message.

Le découpage n’est pas cosmétique. Il isole la partie du dispositif qui fonctionnait le plus mal.

La partie qui fonctionnait mal, chiffrée

Un travail présenté à la conférence ACM CoNEXT en décembre 2024, relu par un comité de programme, a collecté plus de quarante mille rapports agrégés reçus par une grande université européenne entre avril 2022 et novembre 2023.

Résultat : 94,93 % de ces rapports ne respectaient pas la syntaxe définie par la RFC 7489, et 92,22 % étaient non conformes au schéma XML.

Vingt rapports sur vingt et un, produits par des opérateurs de messagerie professionnels, hors norme.

Un travail antérieur présenté à USENIX Security en 2023 avait montré la face amont du même problème : 49 % des domaines publiant du DMARC activent le reporting agrégé, et 26 % de ces configurations sont mal formées, donc incapables de recevoir les rapports qu’elles demandent. Parmi les dix mille premiers domaines mondiaux, 10 % étaient dans ce cas.

Voilà le contexte réel dans lequel une entreprise déclare « nous avons mis DMARC en place ».

Ce qui change concrètement dans vos enregistrements

Le tag pct disparaît. Il permettait d’appliquer sa politique à un pourcentage des messages en échec, typiquement pour un déploiement progressif. La RFC 9989 le classe en historic et explique pourquoi : l’expérience opérationnelle a montré qu’il n’était presque jamais appliqué correctement, sauf pour les valeurs 0 et 100. Un tag nommé « pourcentage » qui n’avait en pratique que deux valeurs valides n’avait plus de raison d’exister.

Un tag t le remplace, avec les valeurs y et n. Il indique si le propriétaire du domaine souhaite que la politique déclarée soit réellement appliquée, ou s’il est en phase de test. Deux valeurs, explicitement, au lieu de cent valeurs dont deux fonctionnaient. Les tags rf et ri passent également en historic.

La Public Suffix List cède la place à un parcours de l’arbre DNS. C’est le changement le plus profond. Pour savoir quelle politique s’applique à facture.paiement.exemple.fr, le receveur ne consulte plus une liste externe maintenue par un tiers : il remonte l’arborescence DNS, avec un plafond de huit requêtes quel que soit le nombre de niveaux. Deux nouveaux tags accompagnent ce mécanisme, psd pour déclarer un domaine de suffixe public et np pour fixer la politique des sous-domaines qui n’existent pas.

p=none ne disparaît pas, contrairement à ce qui se raconte. La RFC 9989 en fait même un repli explicite : si l’enregistrement trouvé ne contient pas de tag p valide mais comporte un rua syntaxiquement correct, le receveur doit se comporter comme s’il avait lu p=none et poursuivre le traitement.

L’ordre de découverte est normé : domaine auteur, puis domaine organisationnel, puis domaine de suffixe public. Et si le parcours ne trouve aucun enregistrement, la règle est catégorique : le receveur ne doit pas appliquer DMARC au message.

Ce que cela ne change pas

L’alignement reste l’alignement. Le domaine du From visible doit correspondre au domaine validé par SPF ou par DKIM, et les opérateurs se contentent d’un alignement relâché : un seul des deux suffit.

Un SPF qui tombe en permerror parce qu’il dépasse la limite de dix requêtes DNS ne s’aligne pas. Une signature DKIM produite avec une clé trop courte ou un algorithme périmé ne s’aligne pas davantage. DMARC ne répare rien : il constate.

Et la chaîne de transfert reste le point faible. Une liste de diffusion qui réécrit le sujet casse la signature DKIM ; ARC, spécifié par la RFC 8617 en 2019, existe pour transporter le verdict d’authentification à travers ces relais, mais il est resté au statut Experimental.

Ce que vous faites demain matin

Sortez votre enregistrement DMARC actuel et lisez-le, tag par tag. S’il contient pct, il repose sur un mécanisme que la norme vient de retirer.

Vérifiez ensuite que l’adresse déclarée en rua reçoit réellement quelque chose. Un quart des configurations mesurées ne le faisaient pas. Envoyez-vous un rapport de test et ouvrez-le.

Enfin, résistez à la tentation de passer en p=reject parce qu’un tableau de bord affiche un feu vert. Une politique de rejet appliquée alors qu’un flux légitime n’est pas encore aligné, un outil de facturation, un formulaire de site, une plateforme de recrutement, supprime ce flux sans laisser de trace exploitable. La progression se fait avec des rapports lus, pas avec des rapports demandés.

Sources

LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.