Email & Collaboration Threat Protection

DMARC est désormais une proposition de norme de l'IETF — votre organisation est-elle prête ?

Voici ce qui a changé, ce que cela implique en matière d'exigences de conformité et d'assurance, et pourquoi la valeur « p=none » n'est plus une option sûre

by Alexander Decarne

juin 02, 2026

Key Points

Le DMARC est passé du statut de document d'information à celui de projet de norme (RFC 9989) dans le cadre du processus de normalisation de l'IETF. Ses exigences bénéficient désormais d'un consensus officiel.
Les enregistrements v=DMARC1 existants restent pleinement valides. La RFC 9989 présente des mises à jour structurelles que les organisations peuvent adopter à leur propre rythme, mais la pression en matière de conformité et d'assurance, qui les pousse à s'aligner sur ces nouvelles exigences, s'intensifie.
Les assureurs spécialisés dans la cybercriminalité posent de plus en plus de questions sur la mise en œuvre du protocole DMARC lors de la souscription. Un nombre croissant d'opérateurs considèrent qu'une approche « p=none », consistant uniquement en une surveillance, constitue un signal moins fort qu'une politique appliquée de manière stricte.

Après onze ans d'existence en tant que convention communautaire largement adoptée, mais sans statut officiel au sein de l'IETF, DMARC fait désormais l'objet d'un document relevant de la procédure de normalisation de l'IETF. La RFC 9989, publiée en mai 2026, remplace la RFC 7489 et place DMARC sur la même voie de normalisation que des protocoles fondamentaux tels que SMTP et IMAP. Pour la plupart des organisations, cela pourrait passer pour une simple note technique. Ce n'est pas le cas.

Pourquoi ce changement de statut est-il important ?

La RFC 7489 originale a été publiée en 2015 dans le cadre du volet « Independent Submission Stream » de l'IETF, ce qui signifie qu'elle ne bénéficiait pas du poids d'un consensus officiel de l'IETF ; c'est pourquoi les implémentations ont divergé et que certaines lacunes sont restées sans réponse pendant des années. La RFC 9989 modifie cela : les exigences du protocole DMARC reflètent désormais le consensus officiel de l'IETF, après avoir été examinées par la communauté et approuvées par l'IESG.

Conséquence concrète : les secteurs réglementés et les cadres de passation de marchés disposent désormais d'une référence stable et pouvant être invoquée pour rendre obligatoire l'adoption du protocole DMARC. Une proposition de norme de l'IETF est le type de document qui se retrouve dans les référentiels de sécurité des pouvoirs publics, les recommandations du secteur financier et les cadres de gestion des risques liés aux fournisseurs mis en place par les entreprises. La directive NIS2 de l'UE et la réglementation DORA imposent déjà aux organisations de mettre en œuvre des mesures de sécurité pour les e-mails ; la norme RFC 9989 fournit à ces cadres réglementaires un fondement technique précis.

Deux normes complémentaires accompagnent la RFC 9989. La RFC 9990 traite des rapports agrégés et la RFC 9991 traite des rapports d'échec ; ces deux documents constituent désormais des projets de norme à part entière. Le fait de dissocier la fonctionnalité de rapport du protocole de base permet de clarifier les attentes en matière de mise en œuvre, tant pour les expéditeurs et les destinataires que pour les fournisseurs d'outils.

L'aspect « cyberassurance » que vous ne devriez pas négliger

Au-delà de la conformité technique, les assureurs spécialisés dans la cybercriminalité prennent en compte le niveau de conformité DMARC dans leurs décisions de souscription, et la norme RFC 9989 devrait renforcer encore davantage cette vigilance. Le rapport « Perspectives sur les conditions du marché de la cyberassurance en 2025 » de Gallagher montre que les assureurs évaluent de manière plus détaillée le niveau de sécurité des organisations, l'authentification des e-mails étant explicitement citée, aux côtés de l'authentification multifactorielle (MFA), des solutions EDR et des pratiques de sauvegarde, comme des facteurs influençant le calcul des primes et la disponibilité des garanties.

Les demandes de souscription émanant des principaux opérateurs demandent désormais systématiquement si les organisations ont mis en place les protocoles SPF, DKIM et DMARC. Mais la question qui se cache derrière cette case à cocher est de plus en plus de savoir si cette politique est réellement appliquée. Une configuration « p=none », qui surveille les flux d'e-mails mais n'intervient pas sur les messages rejetés, constitue un signal moins fort pour les souscripteurs que les configurations « p=quarantine » ou « p=reject ». Les organisations qui adoptent la posture « p=none » de manière permanente risquent de faire l'objet d'un examen plus approfondi lors du renouvellement, de se voir proposer des conditions moins avantageuses ou de voir leurs limites de couverture réduites.

Cinq changements que les équipes informatiques doivent comprendre

Les enregistrements existants commençant par « v=DMARC1 » restent pleinement valides, sans date limite de migration. Cependant, plusieurs changements structurels auront une incidence sur le fonctionnement des requêtes DNS, le traitement des rapports et la stratégie de déploiement.

1. Trois balises sont supprimées : pct=, rf= et ri=

La balise « pct= » (déploiement par pourcentage) a disparu ; dans la pratique, elle était rarement utilisée avec « nuance ». La balise rf= (format de rapport) a également été supprimée — un seul format a jamais été utilisé. De plus, le paramètre ri= (intervalle de rapport demandé) est supprimé ; la norme RFC 9989 recommande aux destinataires d'envoyer des rapports quotidiennement. Si vos enregistrements contiennent encore ces balises, cela ne pose aucun problème — les balises inconnues sont ignorées de manière transparente, conformément à la norme RFC 9989, paragraphe 4.7 — mais elles peuvent être supprimées.

2. La balise « t= » remplace « pct= » par un comportement prévisible et progressif

La balise « t= » peut prendre deux valeurs. Mode de test des signaux « t=y » : la combinaison « p=quarantaine » et « t=y » traite les messages non conformes comme si « p=aucun » était sélectionné ; la combinaison « p=rejet » et « t=y » les traite comme si « p=quarantaine » était sélectionné — ce qui représente une approche un peu plus souple que la politique définie. t=n (valeur par défaut) applique la politique de manière normale. Cela remédie à l'ambiguïté qui rendait l'utilisation de `pct=` incohérente d'une implémentation à l'autre.

3. Nouvelle balise : « np= » pour les sous-domaines inexistants

La RFC 9989 introduit le paramètre « np= », qui définit une politique DMARC spécifiquement destinée aux sous-domaines inexistants, c'est-à-dire ceux qui ne disposent d'aucun enregistrement DNS. Auparavant, celles-ci relevaient de « sp= » ou reprenaient par défaut la valeur « p= » du domaine de l'organisation. Les pirates exploitent parfois cette ambiguïté en envoyant des messages à partir de sous-domaines qui n'existent pas dans le système DNS. La balise « np= » offre aux propriétaires de domaines un contrôle explicite.

4. La méthode « DNS Tree Walk » remplace la liste des suffixes publics

Auparavant, la découverte des domaines d'organisation s'appuyait sur la liste des suffixes publics (PSL), une base de données externe statique, mise à jour manuellement. La RFC 9989 remplace cette méthode par l'algorithme « DNS Tree Walk », qui parcourt dynamiquement la hiérarchie DNS à partir du domaine figurant dans l'en-tête « From: » jusqu'à ce qu'il localise l'enregistrement TXT _dmarc correspondant, éliminant ainsi une source connue d'erreurs d'attribution des politiques dans les structures de domaines complexes.

5. La prise en charge du format PSD et la balise « psd= » font désormais partie du cœur du système

La prise en charge des domaines à suffixe public était auparavant à titre expérimental (RFC 9091). La RFC 9989 remplace la RFC 9091 et intègre la gestion des PSD dans la spécification de base. La balise « psd= » est désormais standard et n'est plus expérimentale — ce qui est particulièrement pertinent pour les organisations opérant sous des domaines de deuxième niveau correspondant à un code pays, tels que .co.uk.

Ce que cela signifie pour le secteur

Pour les organisations qui en sont encore au niveau « p=none », la RFC 9989 renforce les exigences sur deux fronts à la fois. Les cadres d'audit et les exigences en matière de marchés publics disposent désormais d'une norme officielle et citable à laquelle se référer, et les mandats spécifiques à chaque secteur s'appuieront de plus en plus sur la RFC 9989 plutôt que sur son prédécesseur à caractère informatif. Parallèlement, la pression exercée par les assureurs pour que l'on passe à la mise en application des règles s'intensifie, indépendamment des facteurs incitant à la conformité.

La démarche à suivre pour assurer la mise en conformité reste inchangée : la visibilité avant tout, chaque source d'envoi doit être identifiée, chaque échec SPF et DKIM doit être résolu avant que la politique ne soit renforcée. Il convient de noter un changement technique important : la RFC 9989 déconseille explicitement l'utilisation de « p=reject » pour les flux de courrier indirects, notamment les listes de diffusion et les transferts — les destinataires sont invités à traiter ces cas comme « p=quarantine » plutôt que de les rejeter d'emblée.

Aucun élément actuellement déployé ne présente de dysfonctionnement. Cependant, les organisations qui adoptent « p=none » comme politique permanente sont exposées à trois risques : le risque d’usurpation d’identité auquel elles étaient déjà confrontées, une norme dont le poids formel est suffisant pour figurer dans les références réglementaires et les évaluations des risques des fournisseurs, ainsi qu’un marché de la cyberassurance qui distingue de plus en plus clairement l’authentification surveillée de l’authentification imposée.

Gardez une longueur d'avance grâce à Mimecast

Mimecast suit de près la mise en œuvre de la norme RFC 9989 et des normes connexes. Pour les organisations qui utilisent Mimecast DMARC Analyzer, la transition devrait se faire en toute transparence. La plateforme offre une visibilité en continu permettant de gérer le niveau de sécurité de l'authentification des domaines à mesure que les normes et les exigences en matière de mise en conformité évoluent. S'inscrivant dans le cadre d'une plateforme plus large au service de plus de 42 000 organisations à travers le monde, Mimecast aide les équipes de sécurité à anticiper les exigences en matière de conformité et d'assurance qui s'articulent désormais autour de la mise en œuvre du protocole DMARC.

Vous souhaitez comprendre ce que la norme RFC 9989 implique pour votre mise en œuvre de DMARC et comment nous pouvons vous aider ? Prenez rendez-vous pour une démonstration et échangez avec l'un de nos experts.

Sources :