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, RFC 9989, RFC 9990 et RFC 9991, remplacent désormais formellement le RFC 7489 original de 2015. Ensemble, ils sont communément appelés DMARCbis.

Les nouvelles spécifications ont été publiées en mai 2026 et ont fait passer DMARC de son ancien statut Informationnel à celui de Norme Proposée sur la Piste de Normalisation de l’IETF. Cela confère à DMARC une place plus forte et plus formelle dans la pile des normes Internet.

I. Ce que couvre chaque RFC

Tableau comparatif des fonctionnalités de la RFC 7489 de DMARC et des nouvelles spécifications DMARCbis, couvrant la structure, le statut, la méthode de découverte, les tests et les politiques.

La spécification DMARC a été divisée en trois documents ciblés plutôt qu’en un seul fichier volumineux :

  • RFC 9989 : Définit le protocole DMARC de base, y compris l’évaluation des politiques, l’alignement des identifiants, le traitement des enregistrements et les procédures de parcours d’arborescence DNS.
  • RFC 9990 : Définit les rapports agrégés DMARC, également connus sous le nom de rapports RUA.
  • RFC 9991 : Définit les rapports d’échec DMARC, parfois appelés rapports forensiques, qui peuvent fournir des détails au niveau des messages sur les échecs d’authentification lorsqu’ils sont pris en charge par les systèmes de réception.

Cette division rend la norme plus facile à mettre en œuvre, à maintenir et à référencer.

II. Votre enregistrement DMARC existant fonctionne toujours

Il ne s’agit pas d’un changement radical pour les propriétaires de domaines.

Les enregistrements DMARC commencent toujours par :

v=DMARC1

Vous n’avez pas besoin de reconstruire votre déploiement DMARC ou de republier immédiatement tous les enregistrements. Les enregistrements existants restent valides, mais la mise à jour est une bonne raison de revoir votre configuration, de supprimer les comportements obsolètes et de confirmer que votre plateforme de surveillance prend en charge les nouvelles spécifications.

III. Principaux changements techniques

Tableau comparatif des nouvelles balises DMARC np, psd et t avec les anciennes balises obsolètes pct, rf et ri, ainsi que leurs objectifs respectifs.

Plusieurs changements importent pour les équipes de sécurité, les administrateurs DNS et les plateformes d’authentification des e-mails.

Le parcours d’arborescence DNS remplace la dépendance à la liste des suffixes publics

DMARCbis remplace la dépendance à la liste des suffixes publics, maintenue en externe, pour la découverte du domaine organisationnel par des procédures de parcours d’arborescence DNS.

Les récepteurs peuvent désormais parcourir la hiérarchie DNS et rechercher les enregistrements _dmarc pertinents à chaque niveau. Cela réduit la dépendance à une liste tierce et améliore la gestion des structures de domaines complexes, des domaines délégués et des opérateurs de domaines de suffixes publics.

Nouvelles balises : np, psd et t

Le RFC 9989 met à jour le registre des balises DMARC et introduit la prise en charge active de :

  • np : politique pour les sous-domaines inexistants.
  • psd : gestion des domaines de suffixes publics.
  • t : indicateur de test, avec t=y pour les tests et t=n pour le fonctionnement normal.

La balise np est particulièrement importante pour les organisations ayant des empreintes de domaines vastes ou complexes, car elle aide à contrer les tentatives d’usurpation contre les sous-domaines inexistants.

Balises historiques : pct, rf et ri

Le RFC 9989 marque plusieurs anciennes balises comme historiques :

  • pct
  • rf
  • ri

La balise pct était initialement destinée à prendre en charge le déploiement partiel de politiques, mais son implémentation était incohérente entre les récepteurs. DMARCbis remplace cette approche par un comportement de test plus clair via la balise t.

Les organisations devraient examiner les enregistrements DMARC existants pour détecter les balises historiques et planifier un nettoyage si nécessaire.

Orientations plus claires pour le transfert et les listes de diffusion

Les flux de courrier indirects, tels que le transfert et les listes de diffusion, restent difficiles pour DMARC car l’alignement SPF ou DKIM peut échouer même lorsque le message est légitime.

DMARCbis fournit des orientations plus explicites concernant ces scénarios réels. Cela importe car de nombreuses défaillances en production ne sont pas causées par du courrier malveillant, mais par du courrier légitime passant par des systèmes qui modifient le routage, les en-têtes ou le contexte d’authentification.

Conformité mieux définie

Les spécifications mises à jour fournissent des définitions plus claires pour la participation DMARC et le comportement d’implémentation.

Cela devrait contribuer à réduire les interprétations incohérentes entre les expéditeurs, les récepteurs et les fournisseurs. Pour les organisations, il est également plus facile de demander si un outil ou un fournisseur est réellement aligné sur la norme DMARC actuelle.

IV. RFC 9989 : Protocole DMARC de base

Le RFC 9989 remplace le RFC 7489 comme spécification DMARC principale.

Il définit le protocole de base, notamment :

  • La découverte de politique DMARC.
  • Le traitement des enregistrements.
  • L’alignement des identifiants.
  • L’évaluation des politiques.
  • Le comportement de parcours d’arborescence DNS.
  • La gestion des balises mise à jour.
  • Les attentes de conformité.

Découverte et héritage des politiques

Le RFC 9989 clarifie le fonctionnement de la découverte de politique DMARC à travers les hiérarchies de domaines.

Cela importe pour les organisations ayant de nombreux sous-domaines, des domaines délégués ou des domaines régionaux. Sans découverte de politique claire, les équipes peuvent croire qu’un domaine est protégé alors qu’un récepteur ne découvre ou n’applique pas la politique attendue.

Alignement des identifiants

DMARC dépend toujours de l’alignement des identifiants.

Un message réussit DMARC uniquement lorsque au moins l’une des conditions suivantes est vraie :

  • SPF réussit et le domaine authentifié SPF s’aligne avec le domaine From visible.
  • DKIM réussit et le domaine de signature DKIM s’aligne avec le domaine From visible.

Le succès de SPF seul ne signifie pas que DMARC réussit. Le succès de DKIM seul ne signifie pas que DMARC réussit. L’alignement est ce qui relie l’authentification au domaine que le destinataire voit.

Parcours d’arborescence DNS

Le parcours d’arborescence DNS est l’un des changements opérationnels les plus importants du RFC 9989.

Au lieu de s’appuyer sur la liste des suffixes publics pour déterminer le domaine organisationnel, les récepteurs utilisent des recherches DNS à travers la hiérarchie de domaines pour découvrir la politique DMARC applicable.

Cela améliore la capacité de la norme à gérer les modèles de délégation complexes et les scénarios de domaines de suffixes publics.

V. RFC 9990 : Rapports agrégés

Le RFC 9990 définit le format des rapports agrégés DMARC.

Les rapports agrégés donnent aux propriétaires de domaines une visibilité sur la façon dont leur domaine est utilisé dans l’écosystème des e-mails. Ces rapports incluent généralement :

  • Les adresses IP sources.
  • Les résultats d’authentification.
  • Les résultats d’alignement.
  • La disposition de la politique.
  • Le volume d’envoi.
  • L’organisation de rapport.

Le RFC dédié aux rapports agrégés devrait améliorer la cohérence entre les implémentations et faciliter l’interprétation du comportement de rapport pour les fournisseurs et les propriétaires de domaines.

Pour les équipes de sécurité, les rapports agrégés restent l’un des moyens les plus utiles pour découvrir les expéditeurs légitimes, identifier les sources non autorisées et surveiller la progression de l’application de DMARC.

VI. RFC 9991 : Rapports d’échec

Le RFC 9991 définit les rapports d’échec DMARC comme une spécification dédiée de la Piste de Normalisation.

Les rapports d’échec peuvent fournir des détails au niveau des messages sur les échecs d’authentification, selon l’implémentation du récepteur et les contrôles de confidentialité.

Ces rapports peuvent être utiles pour le dépannage et l’investigation des menaces, mais ils doivent être manipulés avec précaution. Les rapports d’échec peuvent contenir des métadonnées sensibles et, selon l’implémentation, peuvent inclure des en-têtes de messages ou des éléments de contenu. Les organisations devraient considérer la confidentialité, le volume, la rétention et les contrôles d’accès avant d’activer ou de s’appuyer sur les rapports d’échec.

Tous les récepteurs n’envoient pas de rapports d’échec. Les équipes de sécurité devraient les traiter comme un signal supplémentaire, et non comme une source de surveillance complète.

VII. Ce que les propriétaires de domaines devraient faire

Les propriétaires de domaines n’ont pas besoin de modifier leurs enregistrements DNS en urgence, mais ils devraient examiner leur posture DMARC par rapport aux spécifications mises à jour.

Un examen pratique devrait inclure :

  • Confirmer que tous les enregistrements DMARC utilisent toujours v=DMARC1.
  • Identifier et planifier le nettoyage des balises historiques telles que pct, rf et ri.
  • Examiner si la balise np est pertinente pour la protection des sous-domaines inexistants.
  • Confirmer comment les sous-domaines sont protégés.
  • Vérifier si les expéditeurs tiers sont correctement alignés.
  • Examiner la visibilité des rapports agrégés.
  • Confirmer que votre plateforme DMARC prend en charge les RFC 9989, RFC 9990 et RFC 9991.
  • Demander aux fournisseurs comment ils gèrent la découverte de politique par parcours d’arborescence DNS.
  • Examiner si les rapports d’échec sont utiles, appropriés et sûrs en matière de confidentialité pour votre organisation.

L’objectif n’est pas une migration urgente. L’objectif est un alignement contrôlé avec la norme DMARC actuelle.

VIII. Ce que les plateformes DMARC doivent prendre en charge

La préparation à DMARCbis n’est pas seulement un problème pour les propriétaires de domaines. Les plateformes qui gèrent ou surveillent DMARC doivent également s’adapter.

Une plateforme prête pour DMARCbis devrait prendre en charge :

  • Le comportement du protocole de base RFC 9989.
  • La découverte de politique basée sur le parcours d’arborescence DNS.
  • L’analyse et l’interprétation de np, psd et t.
  • La reconnaissance des balises historiques telles que pct, rf et ri.
  • L’ingestion et l’analyse des rapports agrégés RFC 9990.
  • La gestion des rapports d’échec RFC 9991 lorsqu’elle est activée.
  • La distinction claire entre authentification et alignement.
  • La visibilité à travers les sous-domaines et les domaines délégués.
  • Le comportement de conformité mis à jour à mesure que les implémentations des récepteurs évoluent.

Si une plateforme ne peut pas interpréter les balises mises à jour ou le comportement de rapport, les équipes de sécurité peuvent perdre la visibilité sur d’importantes modifications d’authentification.

IX. Comment Skysnag Protect aide

Skysnag Protect aide les organisations à se préparer à DMARCbis en prenant en charge l’analyse des enregistrements mise à jour, la visibilité des rapports et la surveillance des politiques à mesure que les implémentations des récepteurs évoluent.

La plateforme est conçue pour aider les organisations à :

  • Surveiller la posture d’application de DMARC.
  • Suivre l’alignement SPF et DKIM.
  • Identifier les sources d’envoi légitimes et non autorisées.
  • Maintenir la visibilité à travers les domaines et les sous-domaines.
  • Interpréter le comportement des rapports agrégés.
  • Prendre en charge la gestion des balises DMARC mises à jour.
  • Se préparer à la découverte de politique basée sur le parcours d’arborescence DNS.
  • Réduire la complexité manuelle dans la gestion continue de DMARC.

Alors que l’industrie adopte les RFC 9989, RFC 9990 et RFC 9991, les organisations ont besoin d’outils qui suivent le rythme de la norme sans forcer de perturbations opérationnelles inutiles.

X. Considérations relatives à la migration et à la conformité

DMARCbis n’est pas un nouveau protocole. C’est une version plus claire et normalisée de DMARC basée sur plus d’une décennie d’expérience opérationnelle.

Les organisations devraient traiter la mise à jour comme un point d’examen structuré :

Examiner les enregistrements

Vérifiez les balises historiques, les politiques de sous-domaines incohérentes, les adresses de rapport manquantes et les hypothèses obsolètes sur le déploiement de politiques.

Examiner les expéditeurs

Confirmez que chaque expéditeur légitime peut réussir SPF aligné ou DKIM aligné. C’est particulièrement important pour les plateformes marketing, les CRM, les systèmes de billetterie, les outils d’assistance et autres services tiers.

Examiner les rapports

Assurez-vous que les rapports agrégés sont traités correctement et que tout rapport d’échec est géré avec des contrôles appropriés de confidentialité et d’accès.

Examiner les fournisseurs

Demandez aux fournisseurs de sécurité des e-mails s’ils prennent en charge les RFC 9989, RFC 9990 et RFC 9991, y compris la découverte de politique par parcours d’arborescence DNS et l’interprétation des balises mises à jour.

XI. Derniers mots

DMARCbis est le même DMARC, mais plus clair, plus formel et mieux aligné avec le comportement réel des e-mails.

La publication des RFC 9989, RFC 9990 et RFC 9991 est une bonne incitation pour les propriétaires de domaines à examiner leurs enregistrements, valider l’alignement des expéditeurs, vérifier la couverture des sous-domaines et confirmer que leurs outils sont prêts pour la norme actuelle.

Pour les organisations responsables de la protection de la marque, de la prévention du phishing et de la confiance dans les e-mails, le changement n’est pas perturbateur. C’est une opportunité d’améliorer la qualité de l’implémentation.

XII. Points Clés

  • La RFC 9989 remplace la RFC 7489 en tant que spécification principale du protocole DMARC.
  • La RFC 9990 définit les rapports agrégés DMARC.
  • La RFC 9991 définit les rapports d’échec DMARC.
  • Les enregistrements DMARC existants utilisent toujours v=DMARC1.
  • Le DNS Tree Walk remplace la dépendance à la Public Suffix List pour la découverte de politique.
  • La RFC 9989 introduit un support actif pour np, psd et t.
  • pct, rf et ri sont désormais des balises historiques.
  • DMARCbis améliore la clarté et la cohérence de mise en œuvre plutôt que de modifier l’objectif fondamental de DMARC.
  • Les organisations doivent examiner leurs enregistrements, sous-domaines, expéditeurs, rapports et la préparation de leurs fournisseurs.

Prêt à aligner votre programme d’authentification des emails avec DMARCbis ? Découvrez Skysnag Protect.