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érence6 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

Quand vous rédigez un enregistrement DMARC, ou que vous devez savoir exactement comment un serveur de réception va le trouver et l’appliquer, les règles viennent désormais de DMARCbis. Vous trouverez ci-dessous ses balises, ses règles d’alignement, la façon dont un serveur de réception découvre la politique applicable à un message, et ce qui a changé par rapport à la spécification précédente.

La RFC 9989 (voie normative, mai 2026) est la spécification DMARC actuelle, et 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 une introduction à ce que fait DMARC, aux bases de l’alignement et à la stratégie de déploiement, voir DMARC.

Registre complet des balises

L’enregistrement est publié sous forme d’enregistrement TXT à _dmarc.<domain>. Les balises sont des paires key=value séparées par des points-virgules, et 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 enregistrement A, AAAA ou MX). Par exemple, vous pouvez fixer p=none; np=reject pour bloquer l’usurpation de sous-domaines inventés pendant que vous faites encore évoluer le domaine principal vers une politique contraignante.
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 Quand envoyer des rapports d’échec : 0 signifie un rapport uniquement si tous les mécanismes échouent à produire un pass aligné ; 1 signifie un rapport si un mécanisme quelconque échoue ; d signifie un rapport des échecs DKIM quel que soit l’alignement ; s signifie un 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), s’il 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 s’applique à tous les messages ou à aucun) 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 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é ont 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 donne un pass DMARC.

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

La RFC 7489 s’appuyait sur la Public Suffix List, une liste tenue pour les navigateurs web, pour trouver le domaine organisationnel d’un domaine. La RFC 9989 la remplace par un parcours de l’arborescence (Tree Walk) dans le DNS, limité à 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 plus court, l’un après l’autre.
  4. S’arrêter plus tôt lorsqu’un enregistrement avec psd=n ou psd=y est trouvé. Ces enregistrements marquent la frontière entre l’organisation et le suffixe public.
  5. Le parcours se termine lorsqu’un enregistrement approprié est trouvé ou qu’il ne reste plus de libellés.

Le domaine organisationnel est déterminé à partir des résultats du parcours : c’est le domaine situé juste sous le point où apparaît psd=y, ou le nom le plus long qui porte un enregistrement ou psd=n. Par rapport à la PSL, cela modifie le comportement dans les cas limites, pour les zones à délégation profonde. Pour des configurations typiques comme example.com et 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 applicable 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, et np s’il n’existe pas. À défaut, revenir à p.
  4. S’il n’existe 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 point où le Tree Walk s’arrête, et évite que des emails soient attribués au mauvais domaine.
  • 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 l’augmentation progressive de pct=. Avec la RFC 7489, pct=25 donnait une application partielle. Avec la 9989, soit vous appliquez, soit vous testez. Planifiez les déploiements par étapes, d’abord p=none, puis t=y avec p=quarantine/reject, puis la politique contraignante, en vous guidant 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) seront toutes deux utilisées. Les enregistrements qui ne contiennent que les balises communes aux deux (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 →