DMARC : ce qui change avec la RFC 9989
En mai 2026, la RFC 9989 a rendu obsolètes la RFC 7489 (DMARC, 2015) et la RFC 9091. La RFC 7489 était un document informatif ; la RFC 9989 est publiée sur la voie des normes (Standards Track). Les rapports sont désormais décrits à part : RFC 9990 pour les rapports agrégés, RFC 9991 pour les rapports d'échec. Cette page ne couvre que la RFC 9989, lue en texte intégral le 5 novembre 2026.
Les balises en un tableau
La RFC 9989 tient un registre des balises (section 9.3, table 5). Trois passent au statut « historique », trois s'ajoutent par rapport à la RFC 7489 (annexe C.5) : t est nouvelle, np vient de la RFC 9091 (expérimentale, 2021), psd reprend la gestion des suffixes publics de ce même texte.
| Balise | Statut | Rôle |
|---|---|---|
v, p, sp, rua, ruf, adkim, aspf, fo | active | Inchangées dans leur principe. |
t | nouvelle | Mode test (y ou n, défaut n). |
np | nouvelle | Politique pour les sous-domaines qui n'existent pas. |
psd | nouvelle | Indique si le domaine est un suffixe public (défaut u). |
pct | historique | Pourcentage de messages soumis à la politique. |
rf | historique | Format des rapports d'échec. |
ri | historique | Intervalle des rapports agrégés. |
La fin de pct, remplacé par t
Avec la RFC 7489, on durcissait souvent par paliers : p=quarantine; pct=10, puis 50, puis 100. L'annexe A.6 de la RFC 9989 explique pourquoi elle abandonne ce mécanisme : en pratique, pct n'était appliqué correctement qu'à 0 ou 100, et l'erreur sur les autres valeurs variait beaucoup d'un récepteur à l'autre. La valeur 0, elle, servait réellement : certains intermédiaires et fournisseurs de messagerie la lisaient comme un signal pour réécrire l'en-tête From.
La balise t reprend ces deux cas. Avec t=y, le récepteur applique la politique d'un cran en dessous (section 4.7) :
| Enregistrement | Politique appliquée aux messages en échec |
|---|---|
p=reject; t=y | quarantine |
p=quarantine; t=y | none |
p=none; t=y | none (t est sans effet sur none) |
t ne change rien aux rapports : vous continuez à les recevoir.
np : les sous-domaines qui n'existent pas
Un fraudeur peut écrire depuis facture.votre-domaine.fr même si ce nom n'existe pas dans votre DNS. np fixe la politique pour ces noms inexistants, sans toucher au domaine principal ni aux sous-domaines réels. Si np est absent, c'est sp qui s'applique, et à défaut p (section 4.7). Exemple : v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@exemple.fr.
psd et la recherche dans l'arbre DNS
La RFC 7489 laissait chaque récepteur trouver le « domaine organisationnel » avec une liste de suffixes publics, sans imposer laquelle ni à quelle fréquence la mettre à jour. La RFC 9989 la remplace par une suite de requêtes DNS qui remonte les étiquettes du nom (section 4.10, « DNS Tree Walk ») ; un nom de plus de huit étiquettes ne donne pas plus de huit requêtes. L'annexe C prévient qu'un récepteur resté sur la RFC 7489 et sa liste peut aboutir à un autre domaine organisationnel. La balise psd=y est publiée par les opérateurs de suffixes publics ; pour un domaine d'entreprise, la valeur par défaut u laisse le récepteur conclure par cette recherche.
p reste à mettre
La balise p est « recommandée ». Un enregistrement par ailleurs valide sans p est traité comme p=none (section 4.7). La section 4.10.1 ajoute une condition pour un p absent ou invalide : p=none si rua contient au moins une adresse valide, aucun traitement DMARC sinon. Les deux passages ne disent pas tout à fait la même chose : écrivez p et le doute disparaît.
Que modifier dans votre enregistrement
pctentre 1 et 99 : remplacez-le. Pour tester une politique, publiezpct=0; t=y; pour l'appliquer, retirez les deux balises.pct=0seul : ajoutezt=y. Les RFC 7489 (section 6.3) et 9989 (section 4.7) imposent toutes deux d'ignorer une balise inconnue ; un récepteur conforme à la RFC 7489 doit donc ignorert.rfetri: elles sont historiques, vous pouvez les retirer.- Sous-domaines inutilisés : envisagez
np=rejectune fois que les rapports montrent qu'aucun envoi légitime n'en part.
Exemple pendant la phase de test : v=DMARC1; p=reject; pct=0; t=y; np=reject; rua=mailto:dmarc@exemple.fr. Contrôlez le résultat avec le vérificateur, qui signale désormais pct et t, ou produisez la valeur avec le générateur DMARC. La méthode complète est dans la progression none, quarantine, reject.
La combinaison pct=0; t=y est une déduction tirée des deux textes, pas une consigne écrite dans l'un d'eux : la RFC 9989 ne dit pas comment un récepteur traite un pct encore publié. Ce que cette page ne dit pas non plus : la date à laquelle chaque fournisseur de messagerie lira t. Aucune source officielle d'un grand fournisseur n'a été lue à ce sujet.
Sources
- RFC 9989, sections 4.7, 4.10, 4.10.1, 9.3 (table 5) et annexe A.6, https://www.rfc-editor.org/rfc/rfc9989 (texte intégral lu le 2026-11-05).
- RFC 7489, section 6.3, https://www.rfc-editor.org/rfc/rfc7489 (lue le 2026-11-05).