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

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc

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](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc)** (rapports agrégés) et la **[RFC 9991](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc)** (rapports d'échec). Pour une introduction à ce que fait DMARC, aux bases de l'alignement et à la stratégie de déploiement, voir [DMARC](https://emailmarketing.net/fr/apprendre/authentification/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](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc). |
| `ruf` | URI `mailto:` séparées par des virgules | aucune | Destinations des [rapports d'échec](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc). |
| `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](https://emailmarketing.net/fr/apprendre/authentification/en-tete-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](https://emailmarketing.net/fr/apprendre/authentification/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

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur les concepts, les bases de l'alignement et la stratégie de déploiement
- [Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc) (RFC 9990)
- [Rapports d'échec DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc) (RFC 9991)
- [SPF](https://emailmarketing.net/fr/apprendre/authentification/spf)
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim)
- [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc)