DMARC en 2026 : ce que change le RFC 9989 pour votre domaine

En mai 2026, l'IETF a publié trois documents qui redéfinissent le standard DMARC :

• 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.

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, 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 huit niveaux.

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. 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.

Trois nouveaux tags : psd, np, t

• psd (Public Suffix Domain) — pilote le Tree Walk : psd=n pour un domaine organisationnel, psd=y pour un 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.

Le reporting scindé en trois RFC

Politique et reporting cohabitaient dans un seul document. Désormais : RFC 9989 pour le protocole cœur, RFC 9990 pour les rapports agrégés — les XML quotidiens en rua= —, RFC 9991 pour les 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.

Deux clarifications sur p=reject

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'adresse 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 et après

Avant, sous la RFC 7489 :

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

Après, sous la RFC 9989 :

v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.com; np=reject; psd=n

Votre checklist DMARC 2026

Notre point de vue

Nous suivons ces évolutions de près pour que notre surveillance DMARC managée reste alignée sur les standards en vigueur. Elle 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.

Si le sujet vous concerne, l'étape suivante est décrite dans notre article sur la façon de passer à p=reject sans perdre un seul mail légitime.

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