Les RFC 9989, 9990 et 9991 relatifs au protocole DMARC remplacent la RFC 7489
par
Dernière mise à jour : Temps de lecture : 7 min
Après des années de travail au sein du groupe de travail DMARC de l'IETF, la mise à jour tant attendue de la norme DMARC a été publiée. Trois nouveaux documents, les RFC 9989, RFC 9990 et RFC 9991, remplacent désormais officiellement la RFC 7489 originale datant de 2015. Bien qu'il ne s'agisse pas d'un terme officiel, ces RFC étaient communément appelées « DMARCbis » au sein de la communauté et sont désormais publiées en tant que spécification DMARC mise à jour, avec le même numéro de version.
Les nouvelles spécifications ont été publiées en mai 2026, faisant passer DMARC de son statut antérieur de « document d'information » à celui de « projet de norme » dans le cadre du processus de normalisation de l'IETF. Il s'agit d'une avancée significative, car cela confère à DMARC une place plus solide et plus officielle dans la pile des normes Internet.
Contenu de chaque RFC
La spécification DMARC a été divisée en trois documents distincts plutôt qu'en un seul gros fichier. La RFC 9989 contient le protocole de base, notamment l'évaluation des politiques, les règles d'alignement et le traitement des enregistrements. La RFC 9990 définit le format de rapport agrégé (RUA). La RFC 9991 traite des rapports d'échec, souvent appelés rapports d'analyse.
Votre enregistrement DMARC actuel fonctionne toujours
L'un des points les plus importants pour les propriétaires de domaines est qu'il ne s'agit pas d'un changement radical. L'identifiant du protocole reste inchangé ; les enregistrements commencent donc toujours par v=DMARC1. Vous n'avez pas besoin de reconfigurer votre système ni de republier tous vos enregistrements du jour au lendemain.
Si vous souhaitez rafraîchir vos connaissances sur la structure des enregistrements, notre guide sur les balises DMARC vous explique en détail chaque champ.
Principales modifications techniques
Certaines mises à jour méritent une attention particulière, et il est utile d'en comprendre certaines en détail avant de modifier votre enregistrement.
La liste des suffixes publics a été remplacée par l'analyse de l'arborescence DNS
Les destinataires ne s'appuient plus sur la liste des suffixes publics (Public Suffix List), gérée en externe, pour déterminer le domaine organisationnel. À la place, ils remontent la hiérarchie DNS et recherchent des enregistrements _dmarc à chaque niveau. Concrètement, un destinataire commence par le domaine en question et interroge progressivement les étiquettes supérieures, jusqu'à un maximum de huit recherches, jusqu'à ce qu'il trouve un enregistrement DMARC publié. Cela élimine la dépendance vis-à-vis d'un tiers et améliore la précision pour les structures de domaine complexes.
Il convient de noter une implication pratique. Étant donné que le « Tree Walk » résout le domaine organisationnel différemment de l’ancienne méthode de la liste des suffixes publics (Public Suffix List), un destinataire utilisant la norme RFC 9989 peut, dans certains cas, aboutir à un domaine organisationnel différent de celui d’un destinataire utilisant encore la norme RFC 7489. Si vous gérez une hiérarchie complexe de sous-domaines ou utilisez des domaines délégués, l’approche la plus sûre consiste à publier un enregistrement DMARC explicite sur chaque domaine et sous-domaine à partir duquel vous envoyez effectivement des e-mails. Cela élimine toute ambiguïté quant à la politique applicable, quelle que soit la version utilisée par un destinataire donné.
Nouvelles balises : np, psd et t
La RFC 9989 introduit trois nouvelles balises. Voici à quoi sert chacune d'entre elles et dans quelles circonstances vous pourriez les utiliser.
np (politique de sous-domaines inexistants)
La balise « sp » permet déjà de définir une politique pour les sous-domaines, mais « np » va plus loin en distinguant la politique applicable aux sous-domaines qui n’existent tout simplement pas, c’est-à-dire pour lesquels le DNS renvoie une réponse « NXDOMAIN ». Cela comble une véritable faille liée à l’usurpation de sous-domaines, car les attaquants falsifient souvent des e-mails provenant de sous-domaines qui n’ont jamais été enregistrés. Par exemple, un enregistrement de type v=DMARC1; p=none; np=reject; n’appliquerait aucune politique au domaine racine et à ses sous-domaines authentiques, mais rejetterait tout de même les e-mails provenant de sous-domaines inexistants. Si votre domaine est déjà configuré sur p=reject ou sp=reject, la politique stricte est automatiquement héritée ; np=reject n’apporte donc rien de plus et aucune modification n’est nécessaire. Si vous appliquez une politique plus souple mais souhaitez une protection ciblée contre cette attaque spécifique, l’ajout de np=reject en vaut largement la peine.
t (mode test)
Il s'agit de la balise la plus susceptible d'être mal interprétée. Définir t=y ne désactive pas votre politique. Au contraire, cela demande aux destinataires d'appliquer la politique immédiatement moins stricte que celle que vous avez publiée : une politique de rejet est traitée comme quarantine, une quarantine est traitée comme « aucune », et « aucune » n'est pas affectée. Ce comportement est bien plus précis que l'ancien comportement « pct » qu'il remplace effectivement. Une mise en garde importante : tous les destinataires ne prennent pas encore en charge la norme RFC 9989 ; certains ignoreront donc tout simplement la valeur t=y. Pendant la période de transition, l’approche la plus sûre consiste à utiliser à la fois pct et t, afin que les destinataires, qu’ils soient anciens ou récents, comprennent votre intention. Un enregistrement par étapes pourrait se présenter ainsi : v=DMARC1; p=reject; pct=50; t=y;. Vous pouvez en savoir plus sur ce changement dans notre note précédente expliquant pourquoi « t » remplace « pct ».
psd (domaine à suffixe public)
Cette balise aide les destinataires à déterminer le domaine organisationnel lors de la traversée de l'arborescence DNS. La plupart des propriétaires de domaines ordinaires devraient simplement ne pas l'inclure. Elle n'est pertinente que dans deux situations : lorsqu'une organisation souhaite définir délibérément la limite de son domaine organisationnel au niveau d'un sous-domaine (dans ce cas, définir psd=n), ou lorsqu'il s'agit d'un opérateur d'un domaine à suffixe public tel que .bank ou .gov (définir psd=y). Gardez à l'esprit que les récepteurs fonctionnant encore selon la norme RFC 7489 ignoreront complètement cette balise ; elle ne remplace donc pas une conception rigoureuse des enregistrements.
Trois balises ont été supprimées : pct, rf et ri
La RFC 9989 supprime trois balises. Aucune de ces suppressions n'entraînera de rupture d'un enregistrement existant, mais il est utile de comprendre le rôle de chaque balise et comment gérer cette situation. Reportez-vous à la section dédiée ci-dessous.
Des consignes plus claires concernant les listes de diffusion et le transfert de messages
Les flux de courrier indirects continuent de rompre l'alignement SPF DKIM, et la nouvelle spécification le reconnaît ouvertement. Elle déconseille les politiques agressives de rejet (« p=reject ») lorsque le trafic lié aux listes de diffusion est courant, ce qui reflète le comportement réel du courrier électronique dans la pratique.
Une conformité mieux définie
Le nouveau texte précise ce que signifie la « participation totale au protocole DMARC » tant pour les expéditeurs que pour les destinataires, ce qui devrait permettre de réduire les mises en œuvre inégales qui posent problème depuis des années.
Suppression de la limite de taille des URI de rapport
Un changement mineur qui passe facilement inaperçu : la RFC 9989 a supprimé la possibilité de spécifier une taille maximale de rapport dans l'URI de rapport. Les enregistrements qui utilisaient un suffixe de taille tel que rua=mailto:[email protected]!10m n'ont plus de sens, et les destinataires doivent désormais ignorer toute limite de taille associée à une adresse rua ou ruf. Si vos URI de rapport incluent cette syntaxe, vous pouvez supprimer sans risque la partie relative à la limite de taille.
Comprendre les balises supprimées
Si votre enregistrement actuel utilise les codes « pct », « rf » ou « ri », voici précisément ce que chacun d'entre eux signifiait et ce que vous devez faire désormais.
pct (pourcentage)
Cette balise a été conçue pour vous permettre de déployer progressivement une politique, en l'appliquant à un pourcentage donné de messages. Dans la pratique, sa mise en œuvre n'était pas uniforme d'un récepteur à l'autre, ce qui entraînait des résultats imprévisibles ; elle a donc été remplacée par la balise t, plus claire. Si vous utilisez encore la balise pct, ne vous fiez plus uniquement à elle à l'avenir. Pendant la période de transition, la solution la plus judicieuse consiste à utiliser simultanément « pct » et « t=y » afin que les récepteurs plus anciens comme ceux conformes à la RFC 9989 comprennent que vous vous préparez progressivement à l'application de la politique.
rf (format de rapport)
Cette balise spécifiait le format des rapports d'erreur, mais la seule valeur valide a toujours été « afrf », ce qui rendait cette balise superflue dans la pratique. Elle peut être supprimée sans risque de tous les enregistrements où elle apparaît.
ri (intervalle de rapport)
Cette balise définissait l'intervalle souhaité entre les rapports agrégés, en secondes. La plupart des destinataires l'ignoraient et se rabattaient simplement sur un rapport quotidien par défaut ; la RFC 9989 officialise désormais cette pratique en exigeant que les destinataires envoient des rapports agrégés au moins une fois par jour. Il n'y a aucun inconvénient à laisser cette balise en place, mais elle est de moins en moins pertinente et il ne faut pas s'y fier.
Comment mettre à jour l'enregistrement DMARC conformément à la norme RFC 9989 ?
La publication de la RFC 9989 n'affecte en rien ce que vous avez déjà mis en place. Votre enregistrement se trouve toujours au même endroit : un enregistrement DNS de type TXT sur _dmarc.votredomaine.com, et la balise de version reste v=DMARC1.
Alors, pourquoi procéder à cette mise à jour ? Parce que la RFC 9989 reflète le fonctionnement réel du courrier électronique après une décennie de déploiement en conditions réelles, et que certaines de ses modifications méritent d'être intégrées dès maintenant à votre base de données plutôt que d'être découvertes plus tard.
Voici ce que les propriétaires de noms de domaine devraient faire
Les propriétaires de domaines peuvent suivre la liste de contrôle ci-dessous pour mettre à jour leurs enregistrements de manière dynamique :
- Supprimez les balises « rf » et « ri ». Elles sont toutes deux obsolètes et peuvent être supprimées sans risque.
- Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
- Pensez à ajouter « np=reject » si vous souhaitez bloquer l'usurpation d'identité provenant de sous-domaines inexistants sans modifier votre politique principale.
- Supprimez le suffixe indiquant la limite de taille de l'URI de rapport si vos enregistrements rua ou ruf en comportent un.
- Ne mentionnez pas « psd » sauf si vous avez besoin de définir intentionnellement une limite de domaine organisationnel ou si vous gérez un domaine à suffixe public.
- Publiez des enregistrements DMARC explicites pour chaque domaine et sous-domaine à partir duquel vous envoyez des e-mails, afin d'éviter toute ambiguïté liée à la traversée de l'arborescence DNS entre les destinataires conformes aux normes RFC 9989 et RFC 7489.
Pour une présentation plus détaillée des modifications et des étapes à suivre pour mettre à jour vos enregistrements, consultez notre guide complet sur DMARCbis.
Voici à quoi ressemble un enregistrement modernisé conforme à la norme RFC 9989 :
v=DMARC1 ; p=reject ; sp=reject ; np=reject ; rua=mailto:[email protected] ; ruf=mailto:[email protected] ; fo=1 ; adkim=s ; aspf=s
Remarquez ce qui manque : il n'y a pas de pourcentage. Pour mettre en place cette mesure en toute sécurité, ajoutez « t=y », laissez les rapports agrégés s'accumuler, puis supprimez-le lorsque vous serez prêt à appliquer la mesure dans son intégralité.
Vous remarquerez également que deux balises conformes à la norme RFC 9989 sont absentes de cet enregistrement : « t » et « psd ». C'est intentionnel, car ces deux balises sont utilisées dans des cas particuliers et ne font pas partie de la norme.
La balise « t » correspond au mode de test temporaire : vous ne l'ajoutez que pendant la phase de mise en place progressive de la politique, car elle indique aux destinataires d'appliquer la politique immédiatement inférieure à celle que vous avez publiée. La balise « psd », quant à elle, est un indicateur qui déclare qu'un domaine est un suffixe public. Les opérateurs de suffixes publics doivent définir « psd=y », mais pour un propriétaire de domaine ordinaire, la valeur par défaut (u) convient parfaitement, et vous devez simplement omettre cette balise.
Assurez-vous que votre plateforme DMARC est prête
Tous les outils disponibles sur le marché ne se sont pas encore adaptés aux nouvelles normes, et cet écart a son importance. Si votre plateforme ne peut pas lire les nouvelles balises ou traiter les rapports au format mis à jour, vous perdez en visibilité au moment même où le protocole évolue.
PowerDMARC est déjà conforme aux nouvelles spécifications et prend en charge :
- Génération d'enregistrements compatibles avec les RFC 9989, 9990 et 9991
- Analyse syntaxique des nouvelles balises np, psd et t
- RFC 9990 : intégration et génération de rapports agrégés
- Gestion des domaines d'organisation basée sur la traversée de l'arborescence DNS
- Comportement de traitement mis à jour afin de refléter les nouvelles règles de conformité
Si vous souhaitez savoir comment votre profil actuel se positionne par rapport à la nouvelle norme, testez-le à l'aide de notre outil de vérification DMARC gratuit et identifiez les points à améliorer.
En conclusion
Les RFC mises à jour ne constituent pas un nouveau protocole. Il s'agit du même DMARC, réécrit de manière plus claire et élevé au statut de projet de norme. Après plus d'une décennie de déploiement en conditions réelles, la spécification reflète désormais le fonctionnement réel du courrier électronique, y compris ses aspects complexes tels que le transfert de messages et les listes de diffusion.
Pour toute personne chargée de la sécurité des domaines, la publication des RFC 9989, 9990 et 9991 est une bonne occasion de procéder à un audit de vos enregistrements et de vous assurer que vos outils sont prêts à prendre en charge les nouvelles balises et l'approche « DNS Tree Walk ».
Expert en sécurité des domaines et des courriels chez PowerDMARC
Ahona est la responsable du marketing chez PowerDMARC, avec plus de 5 ans d'expérience dans l'écriture sur des sujets de cybersécurité, spécialisée dans la sécurité des domaines et des courriels. Ahona est titulaire d'un diplôme de troisième cycle en journalisme et communication, solidifiant sa carrière dans le secteur de la sécurité depuis 2019.
Derniers messages de Ahona Rudra (voir tous)
