Guide sur la norme DMARC (RFC) : en quoi la norme révisée vous concerne-t-elle ?
Maintenant que DMARCbis est devenu une réalité à l'issue des travaux menés au sein du groupe de travail DMARC de l'IETF, nous souhaitons vous expliquer comment les nouvelles RFC (Requests for Comments) 9989, 9990 et 9991 ont évolué et quel est leur impact sur vos enregistrements DMARC.
L'IETF a publié trois nouvelles spécifications DMARC, à savoir les RFC 9989, RFC 9990 et RFC 9991, rendant ainsi la RFC 7489 obsolète.
Même si ces mises à jour ne sont pas révolutionnaires et n'obligeront pas les propriétaires de domaines à mettre à jour leurs enregistrements DMARC pour garantir le bon fonctionnement du système, ces modifications visent à améliorer la clarté, la sécurité et l'interopérabilité de ce mécanisme de contrôle.
Quels sont les changements apportés à la spécification DMARC ?
Au lieu d'un seul RFC DMARC, il existe désormais trois RFC distincts, que nous abordons ci-dessous.
DMARC (RFC 9989)
La spécification DMARC de base, la RFC 9989, introduit de nouvelles balises, rend d'autres balises obsolètes et remplace la liste des suffixes publics (PSL) par un algorithme de parcours d'arborescence DNS afin d'identifier avec plus de précision les enregistrements de politique DMARC valides.
Balises DMARC obsolètes
Les balises supprimées de la spécification DMARC sont notamment « pct », « rf » et « ri ». La balise « pct » est remplacée par la balise « t » (mode test) afin de créer un scénario « tout ou rien » (100 % ou 0 %). Les balises « rf » (format de rapport agrégé) et « ri » (intervalle entre les rapports agrégés) ont été supprimées car elles étaient respectivement peu utilisées et ignorées par les destinataires. Leur suppression vise à simplifier et à rationaliser le déploiement de DMARC.
Nouvelles balises DMARC
Voici les nouvelles balises d'enregistrement DMARC et leur fonctionnement :
t (mode test) – Remplace la balise pct et prend les valeurs binaires suivantes :
- t=n est la valeur par défaut qui applique la politique DMARC publiée et qui équivaut à la valeur pct=100.
- t=y indique que la politique DMARC publiée dans les balises p, sp et/ou np ne doit pas être appliquée et agit comme la valeur pct=0.
Quand utiliser la balise ` t `
Posons t = y (en parallèle p=quarantine ou p=reject) pour tester l’application de la règle en toute sécurité : les destinataires n’appliquent aucune mesure coercitive, donc aucun courrier n’est affecté, tandis que les rapports indiquent toujours quelles sources ne seraient pas conformes. Les courriers réécrits par un intermédiaire, comme une liste de diffusion qui les réexpédie sous son propre domaine, sont exclus des données, ne laissant que les sources qui doivent se mettre en conformité avant que vous n’appliquiez la règle.
np (politique de sous-domaine inexistant) – avec les mêmes valeurs de politique que les balises p et sp, la balise np vous permet d’appliquer une politique à un sous-domaine qui n’existe pas. L’intérêt de cette balise est de définir une politique d’application pour un sous-domaine inexistant afin d’empêcher les cybercriminels d’envoyer des e-mails frauduleux à partir d’un faux sous-domaine basé sur votre domaine parent.
Quand utiliser la balise « np » ?
Définissez « np=quarantine » ou « np=reject » pour appliquer cette règle aux e-mails provenant de sous-domaines inexistants, tout en conservant « p » et « sp » sur « none ». Une technique d'attaque courante consiste à usurper des adresses appartenant à des sous-domaines inexistants, par exemple « abc123.example.com », car ceux-ci ne sont soumis à aucune politique propre. La balise « np » vous permet de bloquer cet abus sans que le reste de votre messagerie ne soit soumis à cette règle.
psd (domaine à suffixe public) – utilisé pour préciser et définir les domaines à suffixe public (PSD). Cette balise sert à définir le domaine racine du domaine « De » et peut prendre les valeurs suivantes :
- psd=y indique que le domaine est un PSD. Si, lors de la détection des politiques, un enregistrement contenant cette balise avec la valeur « y » est détecté, cette information sera utilisée pour déterminer le domaine organisationnel et le domaine de la politique DMARC.
- psd=n indique que l'enregistrement de politique DMARC est publié pour un domaine qui n'est pas un PSD, mais un domaine organisationnel et ses sous-domaines.
- psd=u est la valeur par défaut indiquant que l'enregistrement de politique DMARC est publié pour un domaine qui n'est pas un PSD, et qui peut ou non être un domaine organisationnel pour lui-même et ses sous-domaines. Dans ce cas, la traversée de l'arborescence DNS permet de déterminer le domaine organisationnel. La traversée de l'arborescence DNS est le processus consistant à associer un nom de domaine à une adresse IP en parcourant le DNS.
Quand utiliser la balise « psd » ?
Le paramètre le plus courant pour un propriétaire de domaine est « psd=n ». Auparavant, le domaine organisationnel était fixe et la spécification DMARC le déterminait pour vous sans que le propriétaire puisse intervenir. La balise psd=n et sa valeur permettent au propriétaire d’un domaine de définir plusieurs domaines organisationnels au sein d’un même espace de domaine, ce qui est utile pour segmenter les sources de messagerie et gérer les politiques de manière distincte à différents niveaux. Par exemple, définir psd=n sur a.b.example.com en fait un domaine organisationnel : ses sous-domaines héritent de cet enregistrement, tandis que b.example.com et c.example.com hériteront quant à eux de l’enregistrement d’example.com.
Rapports agrégés DMARC (RFC 9990)
Le groupe de travail DMARC a supprimé les rapports agrégés de la RFC DMARC initiale et a rédigé une RFC spécifique. Dans la RFC 9990, le protocole DKIM, qui était auparavant facultatif, est désormais obligatoire dans les rapports ; cela facilite l'analyse des clés DKIM et le dépannage lié à leur rotation. De plus, cette RFC modernise le format XML afin de rendre les rapports plus uniformes et plus faciles à exploiter par les outils associés, et intègre des éléments de données issus de la nouvelle spécification DMARC.
Signalement des défaillances (RFC 9991)
La publication de la RFC 9991 inclut un format normalisé de signalement des abus (ARF) et impose aux destinataires d'inclure des champs spécifiques, tels que les échecs et les résultats d'authentification DKIM/SPF. Elle aborde également le problème de longue date de la divulgation des données à caractère personnel (PII) et met l'accent sur la masquage des informations sensibles et la sécurité du transport, tout en introduisant des lignes directrices en matière de vérification par des tiers afin de garantir la confidentialité des rapports RUF.
Ce que les propriétaires de noms de domaine doivent faire face aux nouvelles RFC
Tout d'abord, les modifications apportées à la spécification DMARC n'auront aucune incidence sur votre configuration DMARC actuelle ; la norme RFC 9989 est compatible avec la norme RFC 7489, mais le fait de vous conformer aux nouvelles normes vous permettra d'aligner la sécurité de votre domaine sur les meilleures pratiques.
Avec la publication des nouvelles spécifications RFC relatives au protocole DMARC, les enregistrements v=DMARC1 existants restent valides et continuent de constituer la norme du secteur en matière de sécurité des e-mails. Vous pouvez toutefois vérifier vos enregistrements DMARC afin de vous assurer qu’ils sont conformes à la spécification DMARC mise à jour :
- Suppression des balises obsolètes pct (pourcentage), rf (format de rapport) et ri (intervalle de rapport).
- Ajoutez les nouvelles balises « np » (politique inexistante), « psd » (domaines à suffixe public) et « t » (mode test) selon vos besoins.
Voici un exemple illustrant comment les nouvelles balises apparaissent dans l'enregistrement DMARC :
v=DMARC1; p=reject; np=quarantine; psd=y; t=y; rua=mailto:[email protected]Comme pour toute modification apportée à une norme Internet, l'adoption par les fournisseurs prend du temps. Si une nouvelle balise ne produit pas le résultat escompté, c'est probablement que le fournisseur ne l'a pas encore mise en œuvre. La prise en charge se fera progressivement et ne sera pas simultanée chez tous les fournisseurs.
—Ash Morin, directeur des services professionnels chez dmarcian
dmarcian est là pour vous aider
La mise en œuvre et la maintenance efficaces du protocole DMARC sont essentielles pour lutter contre le phishing et l'usurpation d'identité, et nous mettons à votre disposition les ressources et l'expertise dont vous avez besoin pour réussir du premier coup.
Nous accompagnons les organisations de toutes tailles :
- Déployer DMARC de la bonne manière : pas d'approximation, pas de perturbation.
- Obtenez une visibilité totale de votre écosystème de messagerie
- Garder une longueur d'avance sur l'évolution des politiques de sécurité du courrier électronique
Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.
