En onze ans, je n'avais jamais eu à réécrire ce que je racontais sur DMARC. C'est fait : en mai 2026, l'IETF a publié trois nouvelles RFC — 9989, 9990 et 9991 — qui remplacent la RFC 7489 de 2015. Bonne nouvelle d'abord : rien ne casse. Mais si vous gérez un domaine, quelques évolutions méritent dix minutes de votre attention.

Au sommaire :

• Ce qui vient de se passer
• Pourquoi cette mise à jour compte
• Les 5 changements clés
• Ce qui ne change pas
• Un enregistrement avant / après
• Votre checklist DMARC 2026

Ce qui vient de se passer

Trois documents redéfinissent désormais le standard :

• RFC 9989 — le nouveau cœur de DMARC (« DMARCbis »)
• RFC 9990 — les rapports agrégés
• RFC 9991 — les rapports d'échec

Ensemble, ils rendent obsolète la RFC 7489. Onze ans après la première standardisation, DMARC entre dans une nouvelle ère.

Pourquoi cette mise à jour compte

La RFC 7489 était un document Informational — un statut peu formel qui laissait place à des interprétations divergentes entre implémenteurs. Les RFC 9989/9990/9991 sont des documents Standards Track : consensus technique renforcé, comportements attendus plus clairs, meilleure base pour les fournisseurs de messagerie et les solutions de sécurité.

Ce n'est pas une révolution, mais une évolution structurante. Les organisations qui utilisent déjà DMARC ne verront rien casser. Celles qui n'ont pas encore déployé — ou l'ont fait à moitié — partent maintenant sur des fondations plus solides.

Les 5 changements clés

1. Le DNS Tree Walk remplace la Public Suffix List

C'est le changement le plus structurant. Pour déterminer le domaine organisationnel d'un message, les systèmes s'appuyaient sur la Public Suffix List (PSL), une liste externe maintenue par la communauté Mozilla — parfois obsolète ou interprétée différemment d'un système à l'autre. DMARCbis introduit le DNS Tree Walk : une traversée native de l'arborescence DNS, plus fiable et sans dépendance tierce.

_dmarc.mail.marketing.exemple.com
_dmarc.marketing.exemple.com
_dmarc.exemple.com   ← politique trouvée, arrêt

La recherche s'arrête au premier psd=n (domaine organisationnel) ou psd=y (suffixe public), ou après 8 niveaux. Si vous exploitez des sous-domaines profonds, vérifiez que vos enregistrements DMARC sont publiés aux bons niveaux.

2. Trois tags supprimés : pct, rf, ri

• pct — appliquait la politique à X % des messages. Rarement implémenté de façon cohérente.
• rf — format des rapports forensiques. Redondant avec des spécifications externes.
• ri — intervalle de reporting. Peu respecté par les fournisseurs.

Le tag pct servait au déploiement progressif (ex. pct=10). Ce mécanisme disparaît — mais le déploiement graduel reste une bonne pratique : il se pilote désormais par l'analyse de vos rapports agrégés et la montée des paliers p=none → quarantine → reject, pas par un tag. À faire : retirez pct, rf, ri de vos enregistrements.

3. Trois nouveaux tags : psd, np, t

• psd (Public Suffix Domain) — pilote le Tree Walk : psd=n (domaine organisationnel), psd=y (suffixe public).
• np (Non-existent domain Policy) — la politique des sous-domaines inexistants : np=reject ferme une surface d'attaque souvent négligée.
• t (testing mode) — un simple drapeau consultatif qui signale aux récepteurs une phase de test, sans annuler la politique active.

4. Le reporting scindé en trois RFC

Politique et reporting cohabitaient dans un seul document. Désormais : RFC 9989 (protocole cœur), RFC 9990 (rapports agrégés — les XML quotidiens en rua=), RFC 9991 (rapports d'échec en ruf=). Les rapports agrégés restent le mécanisme recommandé pour le monitoring ; les rapports d'échec soulèvent des enjeux de confidentialité et sont souvent désactivés.

5. Clarifications sur p=reject

Deux précisions à connaître. Côté émetteur : un domaine en p=reject ne doit pas reposer uniquement sur SPF — DKIM devient impératif, car SPF casse sur les redirections et les listes de diffusion (l'IP change), là où la signature DKIM reste intacte. Côté récepteur : ne pas rejeter un message sur la seule base de p=reject ; d'autres analyses restent nécessaires.

Ce qui ne change pas

DMARCbis est rétrocompatible : v=DMARC1 reste inchangé, l'alignement SPF/DKIM est identique, les tags p, sp, rua, ruf fonctionnent comme avant, et vos enregistrements existants continuent de fonctionner sans modification urgente.

Un enregistrement avant / après

Avant (RFC 7489) :
v=DMARC1; p=quarantine; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc@exemple.com

Après (RFC 9989) :
v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.com; np=reject; psd=n

Votre checklist DMARC 2026

1. Auditez vos enregistrements et retirez les tags dépréciés pct, rf, ri.
2. Fermez les sous-domaines inexistants en ajoutant np=reject.
3. Vérifiez que DKIM est déployé si vous utilisez ou visez p=reject.
4. Continuez à monitorer vos rapports agrégés — ils restent le centre du pilotage.
5. Pas encore de DMARC ? C'est le moment de partir directement sur la bonne base.

La perspective SecOps Forces

Chez SecOps Forces, nous suivons ces évolutions de près pour que notre service EmailProtect reste aligné avec les standards en vigueur. Le monitoring DMARC managé que nous proposons intègre déjà la logique des nouvelles spécifications : détection des configurations dépréciées, recommandations de migration, et analyse des rapports agrégés dans une vue unifiée — sans avoir à ouvrir un fichier XML.

Vous voulez savoir où en est votre domaine face au nouveau standard ? Demandez votre audit DMARC gratuit — on regarde ensemble.

Sources : RFC 9989, RFC 9990, RFC 9991 (IETF, Standards Track, mai 2026).