Votre enregistrement TXT _dmarc contient-il encore une balise pct=50 ? Elle ne sert plus à rien depuis le 20 mai 2026. Ce jour-là, l’IETF a publié DMARCbis sous la forme de trois RFC : la 9989 pour le socle du protocole, rejointe par la 9990 et la 9991 pour le reporting, qui remplacent officiellement la RFC 7489 de 2015 (dmarc.org, mai 2026). La balise pct disparaît, deux tags arrivent et la manière de découvrir le domaine organisationnel change de mécanisme. Perdre 30% de delivery en trois mois sans changement de contenu, avec un SaaS d’emailing qui continue d’afficher un statut vert, remonte parfois à une configuration DNS jamais revue plutôt qu’au contenu des campagnes. Pour les fondamentaux du protocole, notamment ce qu’il ne couvre pas, DMARC : 5 choses qu’il ne peut pas faire reste la référence. Ici, il s’agit de la bascule elle-même et de ce qu’il faut corriger avant que les grands receveurs (Google, Microsoft, Yahoo) n’alignent leurs parsers dessus.
Que change concrètement DMARCbis par rapport à la RFC 7489 ?
RFC 7489 portait le statut « Informational » depuis sa publication en 2015 : DMARC n’était jamais devenu un standard Internet au sens strict de l’IETF. RFC 9989 corrige ce point. Le protocole passe en Proposed Standard, la première marche normative de l’IETF et rend caduques RFC 7489 ainsi que RFC 9091, l’extension PSD DMARC restée expérimentale. RFC 9990 encadre désormais les rapports agrégés XML ; RFC 9991 couvre les rapports d’échec message par message. Le tout provient du brouillon draft-ietf-dmarc-dmarcbis-41, publié le 4 avril 2025 au terme d’un travail engagé en 2019, dans la foulée de la finalisation du protocole ARC.
Un point rassure les administrateurs pressés. La valeur v=DMARC1 ne change pas. Un enregistrement publié en 2019 continue de répondre en 2026, sans interruption de service le jour de la bascule.
Les balises que DMARCbis supprime
Trois balises quittent la spécification, avec pct en tête. Censée appliquer la politique à un pourcentage du trafic, elle souffrait d’un défaut documenté depuis des années : en pratique, seules les valeurs 0 et 100 étaient appliquées de manière fiable, les valeurs intermédiaires produisant des comportements incohérents d’un receveur à l’autre (dmarcian, 2025). Elle est remplacée par un tag binaire, t, avec deux valeurs seulement : t=y pour le mode test, équivalent à l’ancien pct=0 et t=n pour l’application complète, équivalent à pct=100. Autour d’elle disparaissent rf, le format des rapports agrégés et ri, l’intervalle entre rapports, déplacés dans les documents de reporting RFC 9990 et RFC 9991. Un enregistrement qui contient encore l’une de ces trois balises continue de fonctionner, il devient simplement obsolète.
Les balises que DMARCbis ajoute
Le tag np cible un angle mort réel de la RFC 7489, celui des sous-domaines qui n’existent pas dans le DNS. Un attaquant pouvait jusque-là expédier depuis fake.paiement.exemple.com sans qu’aucune politique DMARC ne s’applique, le sous-domaine n’ayant tout simplement pas d’enregistrement à interroger (dmarcian, 2025). Avec np=reject ou np=quarantine, le propriétaire du domaine ferme cette porte sans devoir durcir le reste de son trafic légitime. Rejoint par lui, le tag psd reprend le contenu de l’ancienne RFC 9091 : il marque un domaine comme suffixe public (psd=y), une information qui alimente le mécanisme de découverte décrit plus bas. Un domaine qui vise l’affichage BIMI dans Gmail devra de toute manière passer par p=quarantine ou p=reject : la clarification apportée par np ne change rien à ce prérequis déjà en place.
La découverte par arbre DNS remplace la Public Suffix List
Prenez mail.marketing.exemple.com. Sous RFC 7489, déterminer le domaine organisationnel de cette adresse dépendait de la Public Suffix List, une liste maintenue manuellement par Mozilla, mise à jour hors bande, jamais formellement standardisée. Un registre oublié ou un nouveau TLD absent de la liste produisait un faux négatif silencieux. RFC 9989 remplace ce mécanisme par un DNS Tree Walk : le receveur interroge successivement mail.marketing.exemple.com, puis marketing.exemple.com, puis exemple.com, puis le TLD, en s’arrêtant dès qu’il trouve un enregistrement portant psd=n (domaine organisationnel) ou psd=y (suffixe public). L’algorithme est plafonné à 8 requêtes DNS, un chiffre fixé à la section 4.10 de la RFC elle-même. Les rapports agrégés de RFC 9990 ajoutent deux champs absents jusque-là : discovery_method et testing, qui indiquent comment la politique a été trouvée et si le domaine tourne en mode t=y. Un administrateur qui lisait ses rapports XML sans jamais vérifier ces deux champs devra les intégrer à son tableau de bord.
L’impact sur l’alignement SPF et DKIM
L’alignement relève toujours de la même mécanique : comparer le domaine authentifié par SPF ou DKIM au domaine organisationnel du domaine From. Ce qui change, c’est le calcul de ce domaine organisationnel, qui ne sort plus d’une liste externe mais d’une résolution DNS déterministe. Sur un domaine au schéma classique, du type exemple.com sans sous-niveau exotique, rien ne bouge. Sur une structure DNS profonde, plusieurs niveaux de sous-domaines gérés par des entités différentes, le résultat du tree walk peut différer de ce que rendait la PSL, surtout quand un niveau intermédiaire publie désormais un enregistrement psd. RFC 9989 clarifie aussi un point déjà vrai dans les faits mais rarement écrit noir sur blanc : l’alignement SPF ne porte que sur l’identité MAIL FROM de la commande SMTP, jamais sur l’identité HELO. Un domaine qui misait sur un alignement HELO n’a en réalité jamais été couvert ; la clarification ne fait que le rendre explicite. Pour les points de friction structurels du protocole SPF lui-même, la limite des 10 lookups DNS et les conséquences d’un SPF absent restent d’actualité, DMARCbis ne les supprime pas.
Une limite subsiste. Passé huit requêtes DNS, le tree walk ne résout rien. La RFC fixe ce plafond pour éviter les boucles et les attaques par amplification mais une architecture à délégation profonde, un sous-traitant DNS empilé sur un autre sous-traitant, peut buter dessus avant même d’atteindre le domaine organisationnel réel.
Quelles balises DNS TXT _dmarc corriger avant la bascule ?
La documentation IETF ne précise pas dans quel délai les grands receveurs (Google, Microsoft, Yahoo) migreront leurs parsers de réception vers DMARCbis. Les trois RFC sont publiés ; l’adoption côté receveurs reste progressive et non calendaire à ce stade. Corriger l’enregistrement maintenant évite de se retrouver à la traîne le jour où l’un des trois bascule sa lecture par défaut.
- Retirer toute balise pct= de l’enregistrement TXT _dmarc, quelle que soit sa valeur actuelle.
- Supprimer rf= et ri= si elles sont présentes, deux paramètres qu’un receveur conforme à RFC 9989 ne lit plus.
- Ajouter np=quarantine ou np=reject dès que la politique principale, p=, est déjà appliquée, pour fermer la porte des sous-domaines inexistants.
- Vérifier la structure des sous-domaines gérés par des prestataires externes, registre, filiale, marque secondaire et évaluer si une balise psd=y ou psd=n doit être publiée à un niveau intermédiaire.
- Documenter le mode t= choisi, t=y en test ou t=n en application, au lieu de laisser une valeur pct héritée faire foi.
Aucune de ces corrections n’exige de résilier ou de reconfigurer un enregistrement SPF ou DKIM existant. Le travail reste circonscrit au champ DMARC, même s’il touche à la même zone DNS que les enregistrements CNAME déjà en place pour d’autres usages.
« Les changements et améliorations connus sous le nom de DMARCbis sont désormais officiels : le protocole passe sur la voie normative de l’IETF » (dmarc.org, mai 2026).
Ce que la bascule change pour la réputation d’envoi
Nettoyer l’enregistrement DMARC ne règle qu’une partie du problème. Un domaine parfaitement aligné qui envoie vers une liste dégradée continue de générer des rejets, pour une autre raison : le taux de hard bounce grimpe, la sender reputation se dégrade auprès du postmaster Gmail et un DMARC reject sur un domaine par ailleurs propre finit par être lu comme un signal de spam plutôt que comme une anomalie ponctuelle. C’est l’objection habituelle : vérifier une liste avant l’envoi a un coût, autant filtrer après coup. Sauf qu’un rejet DMARC post-authentification ne se rattrape pas au tri comme un soft bounce ordinaire, il abîme la réputation de l’IP avant même que ce tri ait lieu. Les feedback loops FAI et le complaint rate remontent généralement avant que le SNDS de Microsoft ne signale quoi que ce soit d’anormal. Une bascule DMARCbis mal préparée, combinée à une liste jamais nettoyée, cumule les deux causes de rejet au lieu d’en isoler une seule. Pour savoir pourquoi les rejets SMTP augmentent et comment les faire baisser, le sujet rejoint directement celui de l’enregistrement DNS traité ici. La seule façon de savoir laquelle des deux causes pèse le plus, c’est de passer la liste au crible avant la prochaine campagne, séparément du travail sur l’enregistrement DNS.
Les protocoles se mettent à jour tout seuls. Les enregistrements DNS, jamais.
