Il arrive qu’une norme et son usage divergent lentement, sans que personne ne s’en aperçoive. En emailing, il existe un cas où la divergence est totale, documentée des deux côtés, et parfaitement visible : il suffit de lire deux documents publiés à quatre mois d’intervalle.
Le premier retire un réglage de la norme DMARC. Le second l’exige toujours.
Ce réglage s’appelle pct.
Ce que la norme DMARC a fait en mai 2026
DMARC a été republié en mai 2026 sous la référence RFC 9989, en catégorie Standards Track, et cette publication rend obsolètes les RFC 7489 et 9091. Le changement de statut est en soi un évènement : DMARC n’était jusque-là qu’un document informatif.
Au passage, la norme a fait le ménage. L’annexe A.6 s’intitule « Removal of the « pct » Tag », et son explication est sans détour :
« Operational experience showed that the « pct » tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another. »
Le registre IANA des balises DMARC porte désormais la mention qui conclut l’affaire : pct y est marqué « historic ».
Un p=quarantine avec pct=50 était censé appliquer la politique à la moitié du trafic. Dans les faits, chaque opérateur en faisait ce qu’il voulait. La norme a préféré retirer la balise plutôt que de continuer à décrire une fiction.
Ce que BIMI exige toujours
BIMI est le mécanisme qui affiche le logo d’une marque à côté de ses messages. Il repose entièrement sur DMARC : sans politique stricte, pas de logo.
La spécification BIMI, dans sa version datée du 1er mai 2026, écrit ceci :
« The policy record MUST express either a Requested Mail Receiver policy of « quarantine » with an effective percentage of 100%, or a Requested Mail Receiver policy of « reject » (with any percentage value). »
Le guide d’implémentation du BIMI Group est plus direct encore : « Note: « None » policies or ‘pct’ less than 100 percent are not accepted ».
Et la documentation de Google, mise à jour le 26 août 2026, ne laisse aucune ambiguïté sur ce qu’elle attend :
« The percent option (pct) must be set to 100. This value applies the DMARC policy to all outgoing mail (100 percent) from your domain. »
Nous sommes donc en septembre 2026. La norme DMARC en vigueur a retiré la balise. Trois documents distincts, dont celui de Google, continuent de la réclamer.
Comment on sort de cette contradiction
La réponse tient en une phrase, et elle est rassurante : ne publiez pas pct du tout.
La valeur par défaut de l’ancienne balise était 100. Un enregistrement DMARC sans pct se comporte donc, pour tout opérateur qui lit encore cette balise, exactement comme un enregistrement avec pct=100. Et pour un opérateur qui suit la RFC 9989, il n’y a simplement rien à ignorer.
Un enregistrement conforme aux deux lectures ressemble à ceci, et il ne contient aucune valeur exotique :
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@votredomaine.fr
Ajouter pct=100 n’est pas une faute, c’est une redondance qui a l’avantage d’être lisible par les opérateurs restés sur l’ancienne lecture. Écrire pct=50 en revanche vous fait sortir du champ de BIMI sans vous protéger de quoi que ce soit.
Le sous-domaine, l’oubli qui coûte le logo
La spécification BIMI ne se contente pas de la politique du domaine principal. Elle décrit l’algorithme que suit le destinataire, et l’étape 8 est un couperet :
« If the DMARC record for the Author Domain or Author Organizational Domain includes a subdomain policy, and that subdomain policy is sp=none then BIMI processing MUST NOT be performed for this message. »
Beaucoup d’entreprises ont durci leur domaine principal en laissant sp=none, précisément pour éviter de casser les envois de sous-domaines mal recensés. C’est une prudence courante, et elle annule BIMI.
La balise sp, elle, est toujours dans la RFC 9989. Sur ce point, norme et implémentation sont d’accord.
Ce que cette contradiction dit du reste
Il serait facile d’en tirer un procès en incompétence. Ce serait manquer l’essentiel.
BIMI n’est pas une norme publiée : c’est un document de travail, réécrit régulièrement, dont la dernière version expire le 2 novembre 2026. La documentation d’un opérateur, elle, décrit ce que fait sa machine aujourd’hui. Les deux vivent à des rythmes différents, et il n’existe aucun mécanisme qui les synchronise.
La conséquence pratique est celle-ci : en délivrabilité, la norme dit ce qui devrait être, la documentation de l’opérateur dit ce qui est. Quand elles divergent, c’est la seconde qui décide du sort de vos messages.
Ce que vous faites demain matin
Interrogez votre enregistrement DMARC et lisez-le en entier, sans le résumer.
Si vous y trouvez un pct différent de 100, vous avez deux problèmes plutôt qu’un : une politique appliquée de manière imprévisible selon les opérateurs, et un logo qui ne s’affichera nulle part.
Si vous y trouvez sp=none, sachez ce que vous achetez avec cette prudence. Elle évite de casser un flux oublié, elle interdit BIMI, et elle laisse à vos sous-domaines une politique plus faible que celle que Gmail exige des expéditeurs groupés.
Et si vous n’y trouvez pas de pct du tout, ne l’ajoutez pas pour faire moderne. L’absence est ici la réponse la plus correcte des deux côtés.
Sources
- IETF (mai 2026). RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC), Standards Track
- IETF (1er mai 2026). draft-brand-indicators-for-message-identification-14, Internet-Draft
- BIMI Group (mise à jour le 17 juillet 2025). BIMI Implementation Guide
- Google (mise à jour le 26 août 2026). Set up BIMI, Google Workspace Admin Help
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é.