Comprendre le DMARCbis

Qu'est ce que DMARCbis ? 

Le protocole DMARC a été instauré via la RFC 7489 publiée en 2015 par l'IETF. Les attaques d'usurpation étant de plus en plus complexes, une évolution DMARC est nécessaire pour continuer d'être efficient.

DMARCbis, en draft en 2026, apporte quelques limitations.

Qu'est ce qui change ?

Certains paramètres vont disparaître :

• pct : permet de définir le pourcentage de messages du flux d'emails auquel la politique DMARC doit être appliquée => va être remplacé par le nouveau paramètre "t"
• ri : permet de définir l'intervalle entre les rapports RUA générés, en secondes => va être supprimé car inexploité en pratique
• rf : permet de définir le format à utiliser pour les rapports d'échec RUF => va être supprimé car un seul format existe
• !10m : permet de limiter la taille des rapports générés, à renseigner à la fin d'un destinataire des rapports DMARC => va être supprimé

Ces trois paramètres seront donc obsolètes lors du déploiement de DMARCbis, il est donc important de retirer des enregistrements DMARC de vos domaines.

De nouveaux paramètres vont faire leur apparition :

• t (testing) : permet de réduire la politique déclarée d'un cran, les valeurs possibles sont : 
  • y (yes) : "t=y" sera équivalent à l'actuel "pct=0"
  • n (no - valeur par défaut) : "t=n" sera équivalent à l'actuel "pct=100"

• psd (public-suffix-domain) : permet de déclarer un domaine comme domaine organisationnel. Les valeurs possibles sont :
  • u (undefined - valeur par défaut) : donnée non renseignée sur ce domaine
  • y (yes) : indique que ce domaine est un PSD (Public Suffix Domain) et indique donc qu'il s'agit d'un domaine organisationnel
  • n (no) : indique que ce domaine n'est pas un PSD

• np (non-existent subdomain policy) : permet d'indiquer la politique à applqiuer sur les sous-domaines non-existants du domaine concerné
  • politique héritée de "sp=" ou de "p=" si non spécifiée
  • np=reject sera utile pour le DMARC sur les domaines PSD comme .bank, .gouv.fr, .berlin ... 
  • un domaine non existant sera déterminé si une requête DNS retourne le flag <NXDOMAIN>

Actuellement la PSL (Public Suffix List) liste les extensions de domaines pour déterminer ce qui est un domaine organisationnel ou non (exemple asso.fr est une extension, donc tennis.asso.fr est un domaine orga).

Un nouveau système va voir le jour pour déterminer dynamiquement si un domaine est organisationnel, nommé "DNS Tree Walk". Ce changement offrira une plus grande flexibilité aux propriétaires de domaines, leur permettant de décentraliser la gestion de sous-domaines définis comme organisationnel.

C'est le paramètre "psd=" qui va être utile de renseigné si besoin.

Une vérification facultative dans DMARC devient obligatoire avec DMARCbis. Est-ce que la boite de réception des rapports DMARC a déclaré (sur DNS) accepter de recevoir ces rapports DMARC ?

gmail.com n'a pas déclaré vouloir recevoir de RUA : 
pas de réponse pour *._report._dmarc.gmail.com IN TXT 

emailsecurity.merox.io a déclaré vouloir recevoir des RUA : 
réponse "v=DMARC" pour *._report._dmarc.emailsecurity.merox.io IN TXT 

Comment migrer ses enregistrements vers DMARCbis ?

Merox offre la possibilité de vérifier la compatibilité de ses enregistrements DMARC via le testeur public ou directement depuis la plateforme. Il est important de noter que les paramètres obsolètes seront à supprimer de vos enregistrements DNS dès la mise en service de DMARCbis pour garantir la compatibilité.

Vous pouvez aussi retrouver tous les détails dans la norme IETF:DMARCbis.