Introduction

Après plus de dix ans d’existence, DMARC franchit une étape majeure avec la publication de la nouvelle spécification RFC 9989. Cette évolution remplace officiellement l’ancienne référence RFC 7489, qui servait de fondation au protocole depuis 2015. Pour les responsables cybersécurité, les équipes messagerie et les administrateurs DNS, cette mise à jour est loin d’être anodine : elle transforme DMARC d’une spécification « informative » en véritable standard IETF, tout en apportant plusieurs changements techniques importants.

DMARC devient enfin un standard Internet officiel

Le premier changement est institutionnel mais significatif. RFC 7489 avait été publiée comme document informatif, sans passer par le processus normal de standardisation de l’IETF. Avec RFC 9989, DMARC rejoint officiellement la catégorie des standards Internet reconnus et bénéficie désormais d’un cadre de gouvernance plus formel. Cette évolution renforce la légitimité du protocole auprès des grandes entreprises, des administrations et des fournisseurs de messagerie qui attendaient parfois cette validation avant d’accélérer certains déploiements.

Par ailleurs, l’ancienne RFC unique est désormais remplacée par trois documents distincts : RFC 9989 pour le protocole principal, RFC 9990 pour les rapports agrégés et RFC 9991 pour les rapports d’échec. Cette séparation permettra de faire évoluer chaque composant indépendamment à l’avenir.

Fin de la dépendance à la Public Suffix List

L’un des changements techniques les plus importants concerne la détermination du domaine organisationnel. Jusqu’à présent, DMARC s’appuyait sur la Public Suffix List (PSL), maintenue par la communauté, afin d’identifier les domaines de référence. RFC 9989 abandonne cette approche au profit d’un mécanisme de « DNS Tree Walk », qui explore dynamiquement la hiérarchie DNS.

Cette modification améliore notamment la prise en charge des Public Suffix Domains (PSD) et réduit la dépendance à une liste externe parfois incomplète ou obsolète. En contrepartie, l’algorithme de découverte devient plus complexe et nécessite une adaptation des outils d’analyse et des plateformes DMARC existantes. Pour les organisations possédant de nombreux sous-domaines ou des structures DNS complexes, cette évolution mérite une attention particulière.

De nouveaux tags apparaissent, d’autres disparaissent

RFC 9989 introduit plusieurs nouveaux paramètres dans les enregistrements DMARC. Le tag np permet désormais de définir une politique spécifique pour les sous-domaines inexistants, tandis que psd identifie les politiques publiées par des Public Suffix Domains. Un nouveau mode de test, t, fait également son apparition afin de faciliter les phases de validation.

À l’inverse, certains tags historiques disparaissent. Les paramètres pct, rf et ri sont désormais considérés comme obsolètes. Dans la pratique, de nombreuses implémentations les ignoraient déjà ou les utilisaient de manière incohérente. Les administrateurs devront néanmoins vérifier la compatibilité de leurs outils de reporting et de monitoring avec cette nouvelle approche.

Une nouvelle vision de la politique « reject »

L’évolution la plus commentée concerne probablement le traitement de la politique p=reject. Historiquement, celle-ci représentait le niveau maximal de protection contre l’usurpation de domaine. RFC 9989 conserve cette option, mais introduit des recommandations plus nuancées concernant son utilisation, notamment pour les organisations dont les utilisateurs participent à des listes de diffusion ou à des flux indirects susceptibles de casser l’alignement DMARC.

Le groupe de travail IETF reconnaît ainsi que certains scénarios de transfert ou de redistribution de messages continuent de poser problème. La nouvelle norme recommande davantage de prudence afin d’éviter les faux positifs et les blocages de courriers légitimes. Cette position a déjà suscité des débats dans la communauté cybersécurité, où de nombreux experts considèrent toujours p=reject comme la meilleure défense contre le phishing lorsque l’inventaire des expéditeurs légitimes est maîtrisé.

Ce que les entreprises doivent faire maintenant

Les enregistrements actuels continuent de fonctionner et la syntaxe fondamentale reste inchangée, notamment le célèbre v=DMARC1. Les domaines déjà protégés par DMARC ne verront pas leurs politiques cesser de fonctionner du jour au lendemain.

En revanche, cette publication doit être considérée comme une opportunité de réévaluer sa stratégie d’authentification email. Les équipes sécurité devraient vérifier la compatibilité de leurs plateformes DMARC avec les nouvelles RFC, revoir leurs politiques de sous-domaines, analyser l’impact du DNS Tree Walk sur leur architecture et anticiper l’évolution des formats de reporting. Pour les organisations fortement exposées aux attaques de phishing et de compromission de messagerie, RFC 9989 marque surtout le début d’une nouvelle phase de maturité du protocole DMARC, qui devient désormais un standard Internet à part entière.