Aperçu de DMARCbis

Bienvenue dans la section de documentation DMARCbis. Vous y trouverez un aperçu de DMARCbis, la mise à jour la plus importante de la norme DMARC depuis sa première publication.

Qu'est-ce que DMARCbis ?

DMARCbis est une révision de DMARC (Domain-based Message Authentication, Reporting, and Conformance). La désignation « bis » suit les conventions de nommage standard pour les révisions de protocole.

La spécification DMARC originale (RFC 7489) a été publiée en 2015 en tant que document « Informational », alors que DMARCbis a été publié en tant que « Proposed Standard ». Cela élève le statut formel de DMARC à celui d'un protocole d'authentification des emails éprouvé et largement adopté, s'appuyant sur plus d'une décennie d'expérience de déploiement.

DMARCbis renforce la norme d'origine en :

• Divisant la spécification en brouillons plus clairs et plus détaillés, avec des exemples supplémentaires
• Améliorant la façon dont les limites du domaine organisationnel sont déterminées, en utilisant des recherches DNS natives au lieu d'une liste maintenue manuellement
• Simplifiant les balises de politique en supprimant les éléments hérités incohérents
• Augmentant les exigences de rapport pour une meilleure visibilité et sécurité

Fait essentiel, DMARCbis maintient la rétrocompatibilité. Il continue d'utiliser v=DMARC1 comme identifiant de version, de sorte que les enregistrements DMARC existants restent valides sans changement immédiat — les organisations peuvent adopter les nouvelles fonctionnalités progressivement.

Principaux changements dans DMARCbis

Spécification restructurée

La norme mise à jour est divisée en trois brouillons distincts :

• Protocole de base — définit les fondamentaux de DMARC
• Rapports agrégés — décrit comment les rapports quotidiens sont générés et formatés
• Rapports d'analyse (forensic) — détaille comment les informations d'échec d'authentification sont rapportées

Cette division rend la norme plus facile à comprendre, à mettre en œuvre et à maintenir dans le temps.

Algorithme DNS Tree Walk

Le changement technique le plus important remplace la Public Suffix List (PSL) par un algorithme de DNS Tree Walk pour trouver la limite organisationnelle d'un domaine.

Au lieu de s'appuyer sur une liste publique maintenue manuellement, un récepteur interroge les niveaux successifs de la hiérarchie du domaine — en remontant un label à la fois — jusqu'à ce qu'il trouve un enregistrement DNS marqué psd=y (un domaine de suffixe public) ou psd=n (une limite organisationnelle).

• Le parcours est plafonné à huit niveaux pour éviter des requêtes DNS excessives.
• Pour les domaines comportant huit labels ou plus, les labels les plus à gauche sont supprimés jusqu'à ce qu'il n'en reste que sept avant le début du parcours.
• Le parcours s'arrête dès qu'il trouve un enregistrement DMARC valide avec une valeur psd explicite.

Cette approche native au DNS supprime la dépendance à une liste tierce, ce qui rend plus probable que les changements de limites soient pris en compte de manière cohérente et améliore globalement la précision de la détection des limites de domaine.

Remarque : Pendant la transition, certains récepteurs peuvent encore utiliser la PSL tandis que d'autres utilisent le Tree Walk, ce qui peut occasionnellement produire des résultats différents pour un même domaine. Publier un enregistrement DMARC explicite sur chaque domaine et sous-domaine — y compris une balise psd le cas échéant — permet d'éviter toute ambiguïté.

Nouvelles balises de politique

DMARCbis introduit trois nouvelles balises pour un contrôle plus fin :

Balise	Objectif
psd (Public Suffix Domain)	y marque le domaine comme un domaine de suffixe public, n le marque comme un domaine organisationnel. La valeur par défaut, u, laisse le Tree Walk le déterminer.
np (Non-Existent Subdomain Policy)	Définit la politique appliquée aux emails prétendant provenir d'un sous-domaine qui n'existe pas dans le DNS — comblant une faille d'usurpation où des attaquants utilisent des sous-domaines fabriqués tels que ceo.example.com.
t (Testing Mode)	Signale qu'une politique est en cours d'essai et pas encore appliquée (y), ou appliquée normalement (n, la valeur par défaut).

Balises héritées obsolètes

Trois balises ont été abandonnées car elles produisaient des résultats incohérents selon les récepteurs :

• pct (percentage) — remplacée par la balise t (Testing Mode), plus claire
• rf (report format)
• ri (report interval) — la cadence des rapports est désormais définie uniformément plutôt que configurable

Ces balises sont toujours publiées lorsqu'elles sont définies, pour des raisons de rétrocompatibilité, mais les récepteurs compatibles avec DMARCbis s'appuieront de plus en plus sur leurs remplacements.

Rapports améliorés

Les rapports agrégés et d'analyse (forensic) disposent désormais chacun de leur propre brouillon de spécification, avec des exigences plus strictes en matière de cohérence et de sécurité :

• Validation obligatoire des adresses de rapport externes (le destinataire rua=/ruf= doit autoriser les rapports envoyés en dehors du domaine expéditeur)
• Formatage des pièces jointes et conventions de nommage standardisés
• Application plus stricte de la structure XML et de la compression gzip

Recommandations sur les listes de diffusion

DMARCbis fournit des recommandations explicites sur les listes de diffusion et le courrier transféré. Il déconseille de publier une politique p=reject lorsque les listes de diffusion font partie du flux normal du courrier, car les logiciels de liste cassent fréquemment l'alignement SPF et DKIM — ce qui peut entraîner le rejet de messages légitimes.

Dans le même temps, DMARCbis continue d'encourager les propriétaires de domaine à œuvrer vers une politique p=reject dans la mesure du possible, car c'est la seule politique qui protège pleinement un domaine contre une utilisation non autorisée. La recommandation est d'évaluer votre écosystème de messagerie — y compris toute liste de diffusion — avant de passer à une application stricte.

Avantages clés

• Détection plus précise du domaine organisationnel grâce à l'algorithme DNS Tree Walk
• Balises de politique plus simples et plus claires, avec des signaux de test non ambigus
• Protection renforcée contre l'usurpation de sous-domaines inexistants
• Meilleure prise en charge des structures de domaine complexes et des domaines de suffixe public
• Cohérence et sécurité améliorées des rapports
• Aucune migration forcée — les enregistrements existants restent valides pendant que vous adoptez les nouvelles fonctionnalités à votre propre rythme

FAQ

Dois-je modifier mon enregistrement DMARC actuel pour DMARCbis ?

Aucun changement immédiat n'est requis. DMARCbis conserve le même identifiant de version (v=DMARC1), de sorte que les enregistrements existants restent valides. Vous pouvez adopter progressivement les nouvelles balises pour renforcer votre authentification des emails au fil du temps.

Comment le DNS Tree Walk améliore-t-il la Public Suffix List ?

Au lieu de s'appuyer sur une liste maintenue manuellement des suffixes publics, le Tree Walk interroge directement le DNS, en remontant la hiérarchie du domaine pour identifier la bonne limite organisationnelle. Cette approche est plus cohérente, car elle ne dépend pas d'un tiers qui maintient une liste à jour.

Dois-je définir une politique p=reject maintenant que DMARCbis la déconseille pour les listes de diffusion ?

DMARCbis ne déconseille pas p=reject de manière absolue — il recommande la prudence spécifiquement lorsque les listes de diffusion font partie de votre flux de courrier, car elles peuvent casser l'alignement SPF/DKIM. Examinez comment le courrier de votre domaine est réellement envoyé et transféré avant de passer à une application stricte.

Sujets connexes

• Aperçu de DMARC — Introduction à DMARC et son objectif
• Syntaxe DMARC — Informations détaillées sur les champs d'enregistrement DNS DMARC
• Paramètres DMARC — Configurer les balises DMARCbis telles que le mode de test et la politique de sous-domaine inexistant