emailmarketing.net
EnglishFrançais

Référence de la norme DMARC (RFC 9989 / DMARCbis)

La spécification DMARC en voie normative qui rend obsolète la RFC 7489 : registre complet des balises de l’enregistrement, parcours de l’arborescence DNS (Tree Walk) qui remplace la Public Suffix List, règles d’alignement, découverte de la politique, et ce qui a changé.

Référence5 min de lecture

À qui cela s’adresse Opérateurs ESP, Expéditeurs

S’applique aux expéditeurs, quelle que soit leur plateforme

SommaireSur cette page : 6 sections

La RFC 9989 (voie normative, mai 2026) est la spécification DMARC actuelle ; elle rend obsolètes la RFC 7489 et la RFC 9091. Elle répartit DMARC en trois documents : la RFC 9989 (protocole central), la RFC 9990 (rapports agrégés) et la RFC 9991 (rapports d’échec). Pour l’introduction conceptuelle (ce que fait DMARC, les bases de l’alignement, la stratégie de déploiement), voir DMARC ; cet article est la référence au niveau de l’enregistrement et des algorithmes.

Registre complet des balises

Publié sous forme d’enregistrement TXT à _dmarc.<domain>. Les balises sont des paires key=value séparées par des points-virgules ; v= doit venir en premier.

Balise Valeurs Par défaut Signification
v DMARC1 obligatoire, première balise Version.
p none | quarantine | reject none si absente Traitement demandé pour les messages du domaine qui échouent à DMARC.
sp comme p hérite de p Politique pour les sous-domaines existants du domaine de l’enregistrement.
np comme p hérite de sp, puis de p Nouveau dans la 9989. Politique pour les sous-domaines inexistants (sans A/AAAA/MX). Permet par exemple de fixer p=none; np=reject pour neutraliser l’usurpation de sous-domaines inventés tout en poursuivant la montée en charge sur le domaine principal.
adkim r | s r Mode d’alignement DKIM : souple (même domaine organisationnel) ou strict (domaine identique).
aspf r | s r Mode d’alignement SPF.
rua URI mailto: séparées par des virgules aucune Destinations des rapports agrégés.
ruf URI mailto: séparées par des virgules aucune Destinations des rapports d’échec.
fo 0 | 1 | d | s (combinaisons séparées par des deux-points) 0 Déclencheurs des rapports d’échec : 0 = rapport uniquement si tous les mécanismes échouent à produire un pass aligné ; 1 = rapport si un mécanisme quelconque échoue ; d = rapport des échecs DKIM quel que soit l’alignement ; s = rapport des échecs SPF quel que soit l’alignement.
psd y | n | u u Nouveau dans la 9989. Indique si ce domaine est un domaine de suffixe public (Public Suffix Domain, y), n’en est certainement pas un (n) ou si c’est inconnu (u). Utilisé par le Tree Walk.
t y | n n Nouveau dans la 9989. Mode test : t=y demande aux serveurs de réception de traiter la politique comme indicative (évaluer et produire des rapports, sans appliquer le traitement). Remplace pct.

Retirées par rapport à la RFC 7489 : pct (échantillonnage en pourcentage, remplacé par la balise t, qui fonctionne en tout ou rien) et ri (intervalle des rapports). Les serveurs de réception qui rencontrent encore d’anciens enregistrements ignorent simplement les balises inconnues ou retirées.

Si un enregistrement découvert n’a pas de balise p valide mais possède une balise rua valide, les serveurs de réception le traitent comme p=none (surveillance seule) au lieu de l’écarter.

Alignement

Un identifiant authentifié (Authenticated Identifier) est le domaine d= d’une signature DKIM valide, ou le domaine RFC5321.MailFrom validé par SPF.

  • Souple (par défaut) : le domaine From: et l’identifiant authentifié partagent le même domaine organisationnel.
  • Strict : les domaines doivent être identiques.
  • La comparaison ne tient pas compte de la casse. Un pass aligné de DKIM ou de SPF suffit pour un pass DMARC.

Le parcours de l’arborescence DNS (Tree Walk, remplace la Public Suffix List)

La RFC 7489 avait besoin de la Public Suffix List, issue du monde des navigateurs, pour trouver le domaine organisationnel d’un domaine. La RFC 9989 la remplace par un parcours de l’arborescence (Tree Walk) effectué dans le DNS, plafonné à 8 requêtes par parcours :

  1. Interroger _dmarc.<domain> pour le domaine exact ; écarter tout ce qui ne commence pas par v=DMARC1.
  2. Si le nom compte plus de 8 libellés, passer directement à ses 7 derniers libellés (les plus à droite) pour les étapes suivantes.
  3. Retirer le libellé le plus à gauche et interroger _dmarc. à chaque nom successivement plus court.
  4. S’arrêter plus tôt lorsqu’un enregistrement avec psd=n ou psd=y est trouvé (ils fixent la frontière entre domaine organisationnel et suffixe public).
  5. Le parcours se termine lorsqu’un enregistrement approprié est trouvé ou que les libellés sont épuisés.

Le domaine organisationnel est déterminé à partir des résultats du parcours (le domaine situé juste sous le point où apparaît psd=y, ou le nom le plus long portant un enregistrement ou psd=n). Cela modifie le comportement dans les cas limites par rapport à la PSL pour les zones à délégation profonde, mais pour des configurations typiques example.com / mail.example.com le résultat est le même.

Découverte de la politique pour un message

  1. Interroger _dmarc.<RFC5322.From domain>. Si un enregistrement DMARC valide existe, l’utiliser.
  2. Sinon, effectuer le Tree Walk vers le haut ; le premier enregistrement valide trouvé s’applique.
  3. Lorsque l’enregistrement appliqué a été trouvé au-dessus du domaine From: (c’est-à-dire que le domaine From: est un sous-domaine) : utiliser sp si le sous-domaine existe dans le DNS, np s’il n’existe pas, et à défaut p.
  4. Aucun enregistrement valide nulle part → DMARC ne s’applique pas au message (traitement none, résultat « none » dans Authentication-Results).

Conséquences opérationnelles

  • Publiez psd=n dans l’enregistrement d’un domaine organisationnel si vous déléguez des arborescences profondes de sous-domaines : cela fixe le Tree Walk et évite les erreurs d’attribution.
  • Utilisez np= pour vous protéger contre l’usurpation de sous-domaines inexistants, même tant que la politique principale est encore p=none pendant le déploiement.
  • t=y remplace la montée progressive par pct=. Avec la RFC 7489, pct=25 donnait une application partielle ; avec la 9989, soit vous appliquez, soit vous testez. Planifiez les déploiements selon la séquence p=none → (t=y avec p=quarantine/reject) → politique contraignante, en vous appuyant sur les données des rapports agrégés comme décrit dans DMARC.
  • Les serveurs de réception adoptent DMARCbis progressivement ; attendez-vous à une longue période pendant laquelle la sémantique de la RFC 7489 (PSL, pct) et celle de la RFC 9989 (Tree Walk, t, np, psd) coexisteront dans la nature. Les enregistrements qui ne contiennent que le sous-ensemble commun (v, p, sp, adkim, aspf, rua, ruf, fo) se comportent de la même façon sous les deux.

Voir aussi

Vérifier votre propre enregistrement

Le diagnostic gratuit lit ce que votre domaine publie dans le DNS.

Dans ce thème

Les 13 articles du thème Authentification →