DMARC a une nouvelle spécification depuis mai 2026 : la RFC 9989. Elle renouvelle notamment la manière de trouver une politique dans le DNS. Pour une petite structure, cette évolution invite à vérifier la cohérence du domaine et des outils d’envoi ; elle ne justifie pas de remplacer des réglages fonctionnels sans diagnostic.

L’enjeu pratique reste accessible : reconnaître les messages légitimes qui utilisent votre identité et comprendre les décisions prises lorsque cette identité ne peut pas être validée. Le vocabulaire technique devient utile lorsqu’il éclaire ces deux questions.

Ce que la publication de 2026 établit

La RFC 9989, publiée en mai, appartient à la filière de normalisation IETF et rend obsolètes les RFC 7489 et 9091. Elle introduit une découverte par parcours DNS, souvent appelée DNS Tree Walk, à la place de la dépendance à une liste de suffixes publics. Le document souligne des différences possibles avec les implémentations antérieures.

Une référence nouvelle et une adoption générale sont deux informations différentes. Sans annonce spécifique d’un fournisseur, on ne peut pas conclure que sa messagerie applique déjà tout le nouvel algorithme. Cette limite compte lorsque vous essayez d’expliquer un résultat de test.

Pour une organisation qui publie une newsletter, l’information utile n’est donc pas « tout refaire ». Il s’agit de savoir quelle configuration vous avez, ce que votre prestataire observe et comment il suit l’évolution du standard.

Repartir des identités du message

Prenez un email réellement envoyé. Demandez à votre prestataire de relever le domaine visible, celui utilisé pour SPF et celui de la signature DKIM. Faites placer ces informations côte à côte.

DMARC relie le domaine d’auteur visible à une authentification réussie et alignée ; sa politique est publiée dans le DNS. Le guide de configuration DMARC de Google présente les vérifications à préparer. L’alignement constitue donc la question concrète à examiner, au-delà d’une mention isolée « SPF réussi ».

Dans votre tableau de travail, ajoutez l’usage : newsletter, confirmation, facture ou correspondance. Cette colonne évite de traiter un domaine comme une abstraction. Vous regardez des messages que vos lecteurs, adhérents ou clients attendent.

Pourquoi la découverte DNS mérite de l’attention

Le parcours DNS concerne la manière dont le système récepteur recherche la politique applicable et identifie le domaine organisationnel. Pour un responsable éditorial, le détail des requêtes peut être confié au prestataire.

En revanche, demandez-lui si plusieurs sous-domaines servent à vos envois et si leurs politiques sont explicites. Faites documenter les dépendances : qui a choisi ce découpage, quel service l’utilise et qui peut le modifier ?

Notre recommandation est d’en faire un sujet d’inventaire avant d’en faire un projet technique. Si votre domaine est simple et vos usages connus, la discussion sera courte. Si plusieurs équipes ou services interviennent, elle peut révéler des responsabilités restées floues depuis une ancienne migration.

Lire les rapports comme un relevé technique

Les rapports agrégés DMARC disposent d’une spécification distincte, la RFC 9990, également publiée en mai 2026. Ils utilisent un format XML pour décrire les flux observés, les résultats d’authentification et la politique appliquée. Leur rôle ne consiste pas à mesurer la lecture de votre newsletter.

Un fichier reçu automatiquement ne devient utile que si quelqu’un l’examine. Identifiez donc la personne ou le service chargé de les interpréter, puis la manière de transmettre une anomalie à l’équipe qui peut agir.

Nous proposons trois questions de lecture : reconnaît-on l’origine du flux ? Le résultat correspond-il à la configuration attendue ? Une action est-elle nécessaire et qui la prend ? Vous obtenez un suivi opérationnel, sans rechercher un indicateur de comportement individuel.

Construire un inventaire des flux légitimes

Rassemblez les services actuels et les services anciens susceptibles d’envoyer encore des messages. La newsletter n’est qu’une partie de l’ensemble : facturation, billetterie, formulaire web et boîtes professionnelles peuvent aussi être concernés.

Pour chaque flux, conservez un exemple récent, un responsable métier et un contact technique. Classez les origines non reconnues comme « à examiner ». Il est prématuré de les considérer toutes comme malveillantes : il peut s’agir d’un usage oublié ou d’une configuration mal documentée.

À l’inverse, l’absence de signalement par un client ne prouve pas qu’un flux fonctionne. La méthode consiste à croiser votre inventaire avec les éléments techniques disponibles, puis à résoudre les divergences.

Préparer une politique plus stricte avec des critères clairs

Les valeurs none, quarantine et reject expriment des politiques DMARC. Le guide de Google présente leurs usages ; le récepteur conserve sa propre décision de traitement. Ne choisissez pas la valeur la plus stricte uniquement parce qu’elle semble plus rassurante.

Avant une évolution, demandez un compte rendu des flux autorisés, des résultats observés et des cas non résolus. Définissez ce qui rend le changement acceptable pour votre activité. Une confirmation essentielle mérite un contrôle explicite.

Prévoyez également les responsabilités pendant la transition : qui surveille, qui reçoit une alerte, qui dispose de l’accès DNS et comment revenir à la configuration précédente si un usage légitime est touché. Ces décisions organisationnelles sont souvent plus utiles au quotidien qu’une accumulation d’acronymes.

Exemple fictif : un domaine partagé par une association

Imaginons une association qui envoie une newsletter et utilise une billetterie pour ses ateliers. Sa communication paraît homogène, mais les deux services ont été installés par des bénévoles différents.

En préparant une évolution DMARC, l’équipe relève les identités de chaque flux et constate que la billetterie n’a jamais été intégrée à la documentation du domaine. Elle demande des exemples au prestataire et fait vérifier le parcours avant toute modification.

L’association ne déduit pas du nouveau standard que sa billetterie est défaillante. Elle utilise la discussion pour combler une information manquante, puis construit sa décision sur les résultats observés. L’exemple est fictif ; il décrit un raisonnement, pas un incident constaté.

Ce que DMARC ne dit pas sur votre contenu

Une identité technique cohérente ne répond pas à la question éditoriale : la promesse de votre newsletter est-elle tenue ? Gardez les deux travaux reliés, mais distincts.

Si des destinataires ne reconnaissent pas la raison de votre message, une nouvelle politique DNS n’expliquera pas à leur place le lien avec votre activité. Revoyez l’inscription, le nom affiché et le contexte rappelé dans le message. Si le problème concerne une signature ou un domaine, fournissez les éléments techniques au prestataire.

Cette répartition permet d’éviter les réactions disproportionnées : réécrire tout le programme quand un flux est mal configuré, ou toucher au domaine alors que la difficulté vient de la fréquence et des attentes.

Préparer votre prochain échange avec le prestataire

Apportez votre inventaire et demandez un document bref répondant à quatre points : la configuration actuelle, les écarts observés, les changements proposés et les contrôles après intervention.

Ajoutez une question sur le suivi de la RFC 9989 : quelles évolutions le prestataire a-t-il effectivement intégrées, et lesquelles dépendent encore des systèmes récepteurs ? Une réponse datée vaut mieux qu’une promesse générale de compatibilité.

Vous disposerez ainsi d’un dossier utile pour votre domaine, même si les implémentations continuent d’évoluer. La nouvelle RFC devient un point de référence pour poser des questions précises et maintenir une identité d’envoi compréhensible.