Pourquoi DMARCbis et pourquoi maintenant
La RFC 7489, publiée en 2015, a défini DMARC comme un mécanisme expérimental (Informational). Onze ans de déploiement massif ont révélé trois limites : le tag pct permettait d'appliquer une politique à seulement X% des messages, ce qui diluait la protection et rendait imprévisible le comportement des récepteurs ; l'absence d'une politique dédiée aux sous-domaines inexistants laissait un flou exploitable pour le phishing ; et la dépendance à la Public Suffix List (PSL) pour identifier le domaine « organisationnel » créait des incohérences entre MTA, puisque la PSL est maintenue hors IETF et peut différer d'un implémenteur à l'autre. Les RFC 9989 (core DMARC), RFC 9990 (rapports agrégés) et RFC 9991 (rapports d'échec) répondent à chacun de ces points en élevant le standard au rang de Proposed Standard — la première étape du Standards Track, avec une voie balisée vers Full Standard.
- RFC 9989 (core DMARCbis) — remplace RFC 7489 et RFC 9091 ; introduit le tag
np, supprimepct, remplacepctpar le tagt(mode test), et définit le mécanisme Tree Walk DNS pour identifier le domaine parent sans recours à la PSL - RFC 9990 (rapports agrégés) — extrait et modernise la partie reporting agrégé de RFC 7489 ; les rapports XML compressés en GZIP restent le format mais le mécanisme de vérification des destinations externes est durci
- RFC 9991 (rapports d'échec) — extrait la partie failure reporting ; met l'accent sur les risques vie privée et impose une limitation de débit chez les générateurs pour éviter les abus DoS
- Suppression de
pct— tout enregistrement DMARC existant portantpct=50(ou toute autre valeur) doit être relu : les récepteurs conformes RFC 9989 peuvent ignorer ce tag ou l'interpréter différemment - Tree Walk DNS — le récepteur remonte l'arbre DNS par requêtes successives (plafonné à 8) pour trouver la politique applicable, éliminant la dépendance à la PSL et améliorant la cohérence entre implémentations
Prérequis avant d'intervenir
Avant toute modification, vérifiez que votre infrastructure remplit les bases : SPF et DKIM doivent être correctement configurés sur votre domaine émetteur — DMARCbis n'ajoute rien à ces mécanismes mais en dépend entièrement. Si SPF ou DKIM échouent, aucune politique DMARC ne sauvera votre délivrabilité. Vérifiez également que vos outils d'audit (dig, nslookup, un accès SSH à votre VPS) sont disponibles et que vous avez accès à votre zone DNS chez votre registrar ou votre panel d'administration. Enfin, disposez des rapports agrégés DMARC actuels (via rua) pour avoir une ligne de base du trafic légitime avant de durcir la politique.
Auditez votre enregistrement DMARC actuel
Lancez
dig TXT _dmarc.votre-domaine.comdepuis votre VPS ou un terminal. Notez la valeur exacte de chaque tag :v,p,sp,pct,rua,ruf,adkim,aspf. Sipctest présent avec une valeur inférieure à 100, vous devez planifier sa suppression.Supprimez ou remplacez le tag `pct`
Dans RFC 9989,
pctest déprécié. Son rôle de déploiement progressif passe au tagt(mode test) :t=yindique au récepteur de traiter le message comme si la politique étaitp=none, sans appliquer la quarantaine ou le rejet. Pour migrer en douceur depuispct=50, remplacez part=y, validez sur quelques semaines via vos rapports agrégés, puis retirezt=y. Exemple de migration :v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected]Ajoutez le tag `np` pour les sous-domaines inexistants
Le tag
np(non-existent subdomain policy) définit la politique à appliquer aux messages prétendant provenir d'un sous-domaine qui n'existe pas dans votre DNS. Sansnp, la RFC 9989 utilise la valeur desp(subdomain policy) ou, à défaut, dep. Si vous ne voulez pas qu'un attaquant exploiteinexistant.votre-domaine.com, ajouteznp=reject. Exemple complet :v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]Comprenez Tree Walk DNS et publiez aux bons niveaux
Avec Tree Walk, un récepteur qui reçoit un message de
mail.app.votre-domaine.comcherche_dmarc.mail.app.votre-domaine.com, puis_dmarc.app.votre-domaine.com, puis_dmarc.votre-domaine.com, s'arrêtant à la première réponse valide (maximum 8 requêtes DNS). Cela signifie que si vous publiez une politique DMARC sur un sous-domaine intermédiaire, elle prend la priorité sur la politique racine pour tous les sous-domaines en dessous. Auditez vos zones DNS pour détecter des enregistrements_dmarc.*non intentionnels qui pourraient court-circuiter votre politique principale.Mettez à jour l'enregistrement DNS final
Une fois les tags revus, publiez l'enregistrement mis à jour dans votre zone DNS. Exemple complet pour un domaine en phase de durcissement :
v=DMARC1; p=quarantine; sp=quarantine; np=reject; adkim=s; aspf=s; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1. Le tagfo=1demande un rapport d'échec si SPF ou DKIM échoue (pas seulement les deux).Vérifiez la configuration DKIM côté Postfix
Sur Postfix avec OpenDKIM, assurez-vous que
adkim=s(strict) n'entre pas en conflit avec des sous-domaines qui signent sous une clé différente. En mode strict, le domaine d'en-têteFrom:doit correspondre exactement au domained=de la signature DKIM. En cas de doute, passez temporairement àadkim=r(relaxed) et analysez vos rapports agrégés.Vérifiez la configuration DKIM côté Exim
Sur Exim, vérifiez dans
/etc/exim4/exim4.conf.templateou votre fichier de configuration principal quedkim_domaincorrespond exactement au domaine publié dans votre enregistrement DMARC. Toute divergence sousadkim=sentraîne un échec DKIM et peut déclencher la politique de quarantaine ou de rejet.Testez et validez les rapports
Attendez 24 à 48 heures et analysez les rapports agrégés XML reçus sur l'adresse
rua. Les champs<policy_evaluated><dkim>et<policy_evaluated><spf>vous indiquent si vos messages passent l'alignement. Un outil comme MXToolbox DMARCAnalyzer ou le parseur en ligne mail-tester.com vous permettra de lire ces rapports sans écrire de code.
Pour valider rapidement votre enregistrement DMARC depuis votre VPS, utilisez dig TXT _dmarc.votre-domaine.com +short puis copiez la valeur dans le vérificateur en ligne de MXToolbox (mxtoolbox.com/dmarc.aspx). Il détecte les tags inconnus, les conflits pct/t, et indique si l'enregistrement est syntaxiquement valide selon RFC 9989. Pour simuler un Tree Walk, lancez successivement dig TXT _dmarc.sous-domaine.votre-domaine.com, dig TXT _dmarc.votre-domaine.com et comparez les politiques retournées à chaque niveau.
Dépannage des situations courantes
Les problèmes courants ont presque toujours une cause déterministe — voici lesquels surviennent le plus souvent et comment les résoudre.
pctignoré par un récepteur — Si des MTA conformes RFC 9989 ignorent votrepct=50et appliquent la politique à 100% des messages, vos rapports agrégés montreront une augmentation soudaine de rejets ou quarantaines. Ajoutez immédiatementt=ypour passer en mode test le temps d'adapter votre infrastructure.- Politique
nptrop restrictive — Si un service légitime envoie depuis un sous-domaine non publié (par exemple un outil d'envoi SaaS qui crée dynamiquement des sous-domaines),np=rejectbloquera ces messages. Commencez parnp=quarantineet analysez les rapports avant de passer àreject. - Tree Walk produit une politique inattendue — Si vous trouvez un enregistrement
_dmarc.app.votre-domaine.comorphelin hérité d'un ancien service, les récepteurs Tree Walk l'appliqueront en priorité. Supprimez les enregistrements_dmarc.*inutilisés après inventaire complet de vos zones DNS. - Rapports agrégés vides ou absents — Vérifiez que l'adresse
ruaest joignable et que votre MX accepte les rapports XML compressés (GZIP). Certains filtres antispam bloquent les pièces jointes.gz. Vérifiez aussi la taille maximale des messages acceptée par votre serveur de réception des rapports. - Divergence
adkim=savec Postfix multi-domaines — Si vous utilisez un même serveur Postfix pour plusieurs domaines et que la clé DKIM signe sousexample.commais que leFrom:contientnewsletter.example.com, l'alignement strict échouera. Soit ajoutez une clé DKIM dédiée par sous-domaine, soit passez àadkim=rpour ces domaines.
RFC 7489 vs RFC 9989 : les différences qui comptent
Le tableau ci-dessous résume les différences structurelles entre les deux spécifications.
Faites défiler le tableau
| Point | RFC 7489 (2015) | RFC 9989 (2026) |
|---|---|---|
| Tag `pct` | Présent — applique la politique à X% des messages pour un déploiement progressif | Supprimé — remplacé par le tag `t=y` (mode test) ; tout message conforme reçoit la politique à 100% |
| Sous-domaines inexistants | Aucun tag dédié — la politique `sp` ou `p` s'applique par défaut | Tag `np` introduit — permet une politique distincte pour les sous-domaines qui n'existent pas en DNS |
| Découverte du domaine parent | Basée sur la Public Suffix List (PSL), maintenue hors IETF, variable selon l'implémenteur | Tree Walk DNS — remontée de l'arbre DNS par requêtes successives, plafonné à 8, défini dans le standard |
| Reporting | Agrégé et échec dans une seule RFC 7489 | Trois RFC distinctes : 9989 (core), 9990 (agrégé), 9991 (échec) — évolutivité accrue |
| Statut | Informational — valeur de référence mais pas de Standards Track | Proposed Standard (Standards Track) — autorité IETF, base pour les implémentations futures des MTA |
Adapter maintenant ou subir plus tard
DMARCbis n'est pas encore appliqué uniformément par tous les MTA Google, Microsoft et Yahoo ont annoncé des phases de test pour Tree Walk, mais aucune date de coupure n'est communiquée officiellement. Cela ne justifie pas l'attente : les RFC 9989, 9990 et 9991 sont publiées sur le Standards Track, ce qui signifie que l'implémentation progressive est en cours et que les premières disparités d'interprétation de pct entre récepteurs apparaissent déjà. Supprimer pct, ajouter np et auditer vos zones DNS pour Tree Walk sont des gestes défensifs qui ne cassent rien sur les récepteurs encore en RFC 7489 — np est ignoré par les anciens MTA, et supprimer pct n'a d'effet que si le récepteur applique déjà RFC 9989. Le coût de l'adaptation est faible ; le coût d'une politique partiellement appliquée par des récepteurs mixtes l'est beaucoup moins.
