La RFC 9989 a fait de DMARC une vraie norme internet en mai 2026 et a supprimé trois balises au passage : pct, ri et rf. Sur 173 enregistrements DMARC vivants que nous avons résolus depuis de vrais domaines expéditeurs le 15 août 2026, 79 en publient encore au moins une. Presque aucun de ces domaines ne le remarquera, car 66 des 68 enregistrements qui portent pct le fixent à 100, ce qui ne faisait rien avant et ne fait rien maintenant.
L’exception est l’enregistrement qu’un expéditeur soigneux a le plus de chances d’avoir publié. Une politique quarantine ou reject avec un pct inférieur à 100 était une rampe délibérée, qui appliquait l’exigence à une partie du courrier en échec. Cette partie a disparu chez tout récepteur qui suit la norme actuelle, et l’enregistrement s’est durci sans que personne modifie le DNS.
Ce guide couvre chaque changement de la RFC 9989 qui atteint un enregistrement publié, avec les numéros de section pour vérifier chacun.
La RFC 9989 a remplacé trois documents, pas un
La RFC 9989 rend obsolètes la RFC 7489 et la RFC 9091, et elle est sur la voie des normes au lieu d’être informative. Ce changement de statut est l’essentiel : DMARC a passé huit ans comme document informatif décrivant ce que faisait un déploiement existant, et c’est désormais une spécification à laquelle les récepteurs sont censés se conformer.
Deux documents compagnons ont détaché la moitié consacrée aux rapports, et tous deux rendent également la RFC 7489 obsolète. La RFC 9990 couvre les rapports agrégés, ceux qui arrivent en XML à votre adresse rua. La RFC 9991 couvre les rapports d’échec, message par message, sur ruf. La RFC 9091 était l’extension expérimentale pour les domaines de suffixe public, et sa balise psd survit dans la spécification principale.
Une page qui cite la RFC 7489 pour quoi que ce soit de DMARC en 2026 cite un document que trois RFC distinctes ont remplacé. Cela comprend la plus grande partie de la documentation des éditeurs, et cela comprend les consignes aux expéditeurs de Google et de Microsoft, qui décrivent encore DMARC dans les termes de la RFC 7489.
Trois balises sont enregistrées comme historic, ce qui n’est pas la même chose qu’inconnues
La RFC 9989 a créé un registre IANA des balises DMARC et y a inscrit pct, ri et rf avec le statut historic. La RFC définit ce statut avec ses propres mots : la balise « is considered deprecated and is not expected to be in use in any current implementation. ».
| Balise | Ce qu’elle faisait | Statut aujourd’hui |
|---|---|---|
pct | Taux d’échantillonnage, la part du courrier en échec visée par la politique | Historic |
ri | Intervalle des rapports agrégés, en secondes | Historic |
rf | Format des rapports d’échec | Historic |
Historic est un état différent d’inconnue, et un outil de vérification doit le traiter comme tel. Ces trois-là ont un nom, une histoire documentée et, pour pct, une raison déclarée de partir. Une balise inconnue est une chose que personne n’a définie. Les deux sont ignorées par un récepteur conforme, et aucune ne peut invalider un enregistrement, mais une seule mérite qu’on la nomme à celui qui publie.
Ce qu’un récepteur fait de l’une ou l’autre est tranché en section 4.8 : « Unknown tags MUST be ignored. Syntax errors in the remainder of the record MUST be discarded in favor of default values (if any) or ignored outright. ». pct=abc et pct=50 sont donc aussi inertes l’un que l’autre chez un récepteur RFC 9989, et un outil de vérification qui passe un enregistrement au rouge pour l’un des deux signale une faute sur laquelle aucun récepteur n’agit.
Une seule des trois suppressions change ce qui arrive à votre courrier
pct est la balise dont le retrait a déplacé du courrier vivant, et il l’a déplacé du côté strict. Sous la RFC 7489, p=reject; pct=25 demandait aux récepteurs de rejeter un quart des messages en échec et d’appliquer au reste la politique du cran en dessous. Chez un récepteur RFC 9989, la balise est ignorée et p=reject s’applique à chaque message en échec.
Personne n’a modifié le DNS pour que cela arrive. L’enregistrement est identique et le résultat ne l’est pas, ce qui est le contraire de ce à quoi ressemble d’ordinaire une dépréciation.
Les deux comportements coexistent, et c’est la partie autour de laquelle il faut planifier. Google et Microsoft ne se sont pas engagés sur la sémantique de la RFC 9989 et leur documentation aux expéditeurs décrit encore l’échantillonnage, le même enregistrement peut donc être échantillonné chez un récepteur et pleinement appliqué chez un autre le même jour.
Cela fixe aussi l’ordre des opérations pour y remédier. Supprimer un pct inférieur à 100 relève l’application chez tous les récepteurs qui l’honorent encore, la séquence sûre consiste donc à atteindre d’abord le niveau d’exigence que vous voulez vraiment, puis à supprimer la balise. Dans l’autre sens, c’est une hausse d’exigence déguisée en nettoyage.
ri et rf sont plus discrètes. ri demandait un intervalle de rapport en secondes, et les récepteurs envoyaient massivement des rapports quotidiens quoi qu’elle dise. rf nommait un format de rapport d’échec, et afrf était la seule valeur que quiconque publiait. Retirer l’une ou l’autre ne change rien à votre courrier.
La balise p n’est plus obligatoire, et deux habitudes partent avec elle
La RFC 9989 liste p comme « RECOMMENDED for DMARC Policy Records » plutôt que comme obligatoire, et la grammaire formelle ne nomme que la balise de version comme indispensable. Un enregistrement sans p n’est pas une erreur de syntaxe.
Deux règles que les outils de vérification anciens imposent disparaissent avec elle, et toutes deux rejettent des enregistrements que tous les récepteurs acceptent :
- L’ordre des balises après
vn’est pas contraint. La RFC 7489 fixaitpen deuxième position, et la documentation de Google destinée à celui qui publie le dit encore. La RFC 9989 non. - Les valeurs de balise ne distinguent pas la casse. Ce sont de simples littéraux ABNF,
p=Rejectest donc valide.
Un p absent mérite toujours un signalement, car un enregistrement sans politique est une conséquence réelle pour le domaine. Ce n’est simplement pas une erreur de syntaxe, et la différence décide de ce qu’on dit au lecteur de faire.
Un enregistrement est écarté pour exactement deux raisons, et ce sont des états distincts
Trois états d’échec doivent rester séparés, car les confondre est la façon dont un outil de vérification annonce à un domaine sans protection qu’il a seulement une faute de frappe. C’est la partie que presque aucune explication ne couvre, et celle qui décide si un outil a raison.
La balise de version est mauvaise. Absente, pas en premier, ou pas exactement DMARC1 à la casse près. Section 4.7 : « the entire record MUST be ignored. ». La découverte de politique continue au-delà, le nom peut donc rester couvert par un enregistrement situé plus haut dans l’arbre.
La politique est inutilisable. p absent ou non reconnu, ou un sp ou un np présent et invalide. La section 4.10.1 place les trois dans une seule branche, et le résultat dépend de rua : avec au moins une URI de rapport syntaxiquement valide, « the Mail Receiver MUST act as if a record containing p=none was retrieved », et sans elle le récepteur n’applique aucun traitement DMARC au message. Ce second résultat est pire que p=none et pire que de ne rien publier.
Tout le reste est réparé sur place. Section 4.8 de nouveau : un fo mauvais, un t mauvais, une balise historic, une balise inconnue. Aucune d’elles ne peut rendre un enregistrement invalide.
La clause qu’on manque est dans le deuxième point. Une faute dans sp écarte en bloc un p=reject parfaitement bon. v=DMARC1; p=reject; sp=quarintine ne protège rien, et un outil de vérification qui rapporte le p qu’il arrive à lire remet un badge vert à un domaine ouvert. Si vous publiez sp ou np, ils portent un poids que p seul n’a pas, et c’est sur la politique de sous-domaines que cela se voit le plus.
Ce que publient vraiment 173 enregistrements DMARC vivants
Nous tenons un corpus d’enregistrements DMARC publiés par de vrais domaines expéditeurs, résolus depuis dns.google en DoH, comme contrôle anti-faux-positifs de notre propre analyseur : chaque enregistrement qui s’y trouve porte du courrier réel, donc toute erreur que notre analyseur lève contre l’un d’eux a tort jusqu’à preuve du contraire. Voici à quoi ressemblaient les balises au 15 août 2026.
| Balise | Enregistrements qui la portent | Part |
|---|---|---|
| Au moins une balise historic | 79 | 46 % |
pct | 68 | 39 % |
pct fixé à 100 | 66 | 38 % |
pct inférieur à 100 | 2 | 1 % |
ri | 16 | 9 % |
rf | 11 | 6 % |
| Les trois balises historic | 1 | moins de 1 % |
Deux choses ressortent, et la seconde explique pourquoi la première pèse peu. Près de la moitié du corpus porte une balise supprimée, ce qui semble alarmant jusqu’à ce qu’on regarde les valeurs : 66 des 68 balises pct valent 100, une valeur qui appliquait la politique à tout avant la RFC 9989 et qui l’applique à tout aujourd’hui. Les valeurs de ri sont 3600, 14400 et 86400 secondes, et absolument toutes les valeurs de rf sont afrf.
L’exposition tient à un enregistrement sur 173 : un p=reject; pct=25 qui demandait un quart et qui reçoit désormais tout. C’est là tout le risque pratique de cette suppression, et il se concentre chez les expéditeurs qui étaient prudents.
Ce corpus est un ensemble de domaines que nous suivons, pas un échantillon aléatoire d’internet, lisez donc les parts comme l’allure de vrais enregistrements publiés et non comme une mesure de tous les domaines. Pour le chiffre de population, 48 % publient une politique DMARC dans le Unspam 2026 Email Deliverability Benchmark.
Les destinations de rapport dans un autre domaine doivent désormais consentir
La section 4 de la RFC 9990 exige qu’un récepteur vérifie qu’une destination de rapport externe a accepté de recevoir les vôtres, et qu’il écarte toute URI qu’il ne peut pas confirmer. La section 5 de la RFC 9991 le répète pour ruf. La RFC 7489 disait que ces vérifications « are to be taken » ; le nouveau texte en fait un MUST et supprime l’échappatoire qui permettait à un récepteur de sauter la vérification au profit d’une liste locale.
En pratique, cela signifie qu’un rua pointant vers le domaine d’un éditeur a besoin d’un enregistrement dans la zone de cet éditeur autorisant votre domaine à y envoyer. La plupart des éditeurs de rapports le publient automatiquement quand vous ajoutez un domaine, c’est donc en général un fait sur une configuration que vous n’avez pas faite et non un changement sur une que vous avez faite.
Il y a un piège distinct dans la même balise, antérieur à la RFC 9989 et qui attrape encore du monde. La grammaire de l’enregistrement utilise deux séparateurs différents : les points-virgules séparent les balises, les virgules séparent les URI à l’intérieur d’une balise. Ainsi rua=mailto:a@example.com; mailto:b@example.net n’est pas une liste de deux adresses. C’est une balise rua suivie d’un terme isolé qui n’est pas tag=value, et la seconde adresse ne reçoit rien. Un outil de vérification bâti sur des expressions régulières par balise ne peut pas voir cela, car chaque expression demande seulement si sa propre balise apparaît quelque part.
BIMI cite toujours la RFC 7489, et c’est correct
La spécification BIMI est en désaccord avec la RFC 9989 sur pct, et c’est volontaire ; les deux affirmations sont actuelles. La RFC 9989 a rendu la balise historic en mai 2026. Le brouillon BIMI publié le même mois cite encore la RFC 7489, et sa section 7.1 bloque encore un logo quand un enregistrement p=quarantine porte un pct qui n’est pas 100.
Un domaine peut donc détenir un enregistrement parfaitement moderne au sens de la RFC 9989 et échouer malgré tout au contrôle BIMI, à cause d’une balise que DMARC n’a plus. Tout ce qui touche à BIMI est cité sur une révision de brouillon et jamais sur une RFC, car il n’existe pas de RFC BIMI : la révision actuelle est draft-brand-indicators-for-message-identification-14, datée du 1er mai 2026.
C’est le genre de détail qui s’aplatit quand un outil partage un seul analyseur DMARC entre plusieurs fonctions. Le chemin BIMI a besoin de son propre contrôle de pct, capable de survivre à un analyseur en forme de RFC 9989 qui laisse tomber la balise.
Quoi faire de votre enregistrement cette semaine
Lisez votre enregistrement avant de le changer, car trois de ces contrôles dépendent de valeurs dont vous ne vous souvenez peut-être pas. Notre outil de vérification DMARC analyse selon la grammaire de la RFC 9989 et trie les balises en actives, historic et inconnues, une balise supprimée est donc signalée comme un avis et non comme une erreur.
- Cherchez un
pctinférieur à 100. Si vous en trouvez un et que votre politique estquarantineoureject, votre enregistrement est déjà plus strict que vous ne le croyez chez certains récepteurs. Décidez du niveau d’exigence voulu, atteignez-le, puis supprimez la balise. - Relisez
spetnpcaractère par caractère. Une faute dans l’un ou l’autre écarte l’enregistrement entier. Si vous n’avez pas besoin d’une politique différente pour les sous-domaines, ne pas les publier est plus sûr que les publier approximativement. - Supprimez
rietrfquand cela vous arrange. Elles sont inertes et en étaient toujours proches. - Vérifiez que votre
ruasépare les adresses par des virgules, pas par des points-virgules, s’il en liste plusieurs. - Laissez un
pct=100tranquille, sauf si vous êtes déjà en train de modifier. C’est du bruit, pas une faute.
Si vous construisez un enregistrement de zéro plutôt que d’en auditer un, le générateur d’enregistrement DMARC produit une syntaxe actuelle, et ce que fait DMARC couvre le mécanisme derrière les balises.
Une balise que personne n’honore n’est pas un enregistrement cassé
L’erreur la plus fréquente dans les textes sur ce changement est de traiter une balise historic comme une erreur. Elle ne l’est pas, et la section 4.8 est sans ambiguïté sur le pourquoi : un récepteur ignore ce qu’il ne reconnaît pas et répare ce qu’il ne peut pas analyser, au lieu de jeter l’enregistrement. Un outil qui passe un enregistrement au rouge pour pct envoie son utilisateur modifier un DNS qui marche, ce qui est pire que de ne rien dire.
Le seul endroit où un avertissement se justifie est le cas étroit ci-dessus, et il se justifie parce qu’il parle de votre courrier et non de votre syntaxe : un pct inférieur à 100 en exigence signifie que votre politique s’applique désormais à des messages qu’elle épargnait. Tout le reste de cette suppression relève de l’entretien.
Passez votre domaine dans l’outil de vérification DMARC, puis envoyez un message de test pour voir si la politique que vous publiez correspond à l’endroit où votre courrier atterrit vraiment.
