SPF, DKIM et DMARC : l’adoption monte en flèche dans la zone .fr

L’étude de l’Afnic publiée l’an dernier reposait sur une photographie du .fr prise entre le 30 et le 31 janvier 2023. Cette photographie combine des données obtenues via le DNS et la présence ou non de contenu original sur le site Web, s’il existe, associé au nom de domaine.

Pour la photographie de cette année, la méthodologie est similaire et les données ont été collectées aux alentours du 15 février 2024.

Nous avons ainsi collecté des données portant sur plus de 4 millions de noms de domaine en .fr. Parmi ces domaines, environ 3,9 millions étaient fonctionnels.

Avec ces données, nous avons directement accès aux politiques SPF et DMARC et nous pouvons inférer la présence d’au moins une clé DKIM. Cette fois, nous avons également intégré BIMI (Brand Indicators for Message Identification) dans l’étude et avons recherché la présence d’enregistrements d’assertion BIMI au sélecteur par défaut (default).

Dans ce billet, nous passerons en revue les évolutions les plus marquantes entre 2023 et 2024, avant de rentrer dans les détails de l’étude. Nous chercherons aussi à expliquer les évolutions que nous constatons, avant de terminer par des perspectives possibles pour l’avenir.

SPF, DKIM et DMARC, de quoi s'agit-il ?

Pour ceux qui n’ont pas déjà lu les billets de blog précédents sur cette thématique, rappelons ce que sont SPF, DKIM et DMARC et à quoi ils servent :

• Sender Policy Framework (SPF) est un mécanisme par lequel un administrateur d’un nom de domaine désigne, au moyen d’informations publiées dans le DNS, la liste des serveurs de messagerie autorisés à envoyer des messages prétendant venir dudit nom de domaine ;
• DomainKeys Identified Mail (DKIM) est un mécanisme qui permet à un serveur de messagerie d’affirmer qu’un courrier électronique provient bien d’un nom de domaine au moyen de signatures cryptographiques apposées aux messages, et dont les clés publiques sont publiées dans le DNS ;
• enfin, Domain-based Message Authentication, Reporting and Compliance (DMARC) effectue des contrôles de cohérence supplémentaires et s’appuie sur SPF et DKIM pour décider si un message est authentique ou non. L’administrateur d’un domaine publie une politique DMARC dans le DNS qui joue principalement deux rôles : primo, recommander une action en cas d’échec de ces contrôles (ne rien faire, mettre en quarantaine ou rejeter le message) ; secundo, fournir une adresse de courrier électronique sur laquelle recevoir des rapports automatisés, ce qui permet de surveiller la délivrabilité des messages.

Ces trois mécanismes pris ensemble sont une contre-mesure qui devraient rendre beaucoup plus difficile l’usurpation d’identité dans les courriers électroniques.

À SPF, DKIM et DMARC s’ajoute Brand Indicators for Message Identification (BIMI), un mécanisme pour afficher des logotypes à côté de courriers qui passent DMARC.

Les évolutions marquantes

La première chose qui saute aux yeux est une adoption de SPF, DKIM et DMARC en nette progression au sein du .fr. En effet, parmi les domaines en .fr qui publient au moins une entrée MX :

• 74,4 % des domaines publient une politique SPF (contre 57,8 % en 2023) ;

• 33,0 % des domaines semblent avoir déployé DKIM (contre 23,1 % en 2023) ;

• et 16,6 % des domaines publient une politique DMARC (contre 7,8 % en 2023).

Si on prend tous les domaines, y compris ceux qui ne publient pas d’entrée MX à l’apex, on trouve que 66,2 % des domaines publient une politique SPF, 28,5 % semblent avoir déployé DKIM et 15,1 % publient une politique DMARC. Ces chiffres étaient respectivement de 52,5 %, 22,6 % et 7,3 % en 2023.

Concernant SPF, l’adoption a augmenté sans aller au détriment de la qualité : les bonnes pratiques sont en moyenne mieux respectées et la proportion de politiques SPF qui les respectent passe de 97,74 % à 98,82 %.

Du côté de DMARC, le constat est similaire : on observe notamment un recul du p=none, surtout en faveur de politiques p=quarantine, tandis que le p=reject progresse presque uniquement chez les domaines sans site Web.

BIMI entre en scène aussi, mais très timidement. Il est adopté par seulement 2 295 domaines avec au moins une entrée MX. Cependant la très grande majorité des déploiements BIMI est incomplète : sur tout le .fr, 58 domaines seulement publient un enregistrement d’assertion BIMI assortie du certificat VMC (Verified Mark Certificate), qu’exigent certains fournisseurs de messagerie pour qu’ils acceptent d’afficher le logo.

Les résultats de l'étude en détails

Passons maintenant en revue quelques détails qui émergent de l’étude cette année : l’évolution du respect des bonnes pratiques SPF, l’évolution des politiques DMARC et une analyse de BIMI sur le .fr.

Bonnes pratiques SPF

L’année dernière, nous avions recensé les critères suivants comme des bonnes pratiques pour l’élaboration et la publication d’une politique SPF :

• publier une politique dont la syntaxe est correcte ;

• publier une et une seule politique SPF ;

• publier la politique SPF sous le type d’enregistrement TXT et ne plus utiliser le type DNS « SPF » ;

• être suffisamment restrictif, ce qui implique ne pas tout autoriser par défaut (tout terme +all ou all est à proscrire) et ne pas autoriser plus de 2¹⁶ adresses IPv4 ou 2³² sous-réseaux /64 en IPv6 ;
• ne pas utiliser le mécanisme ptr ni la macro %{p} ;

• ne pas faire apparaître d’adresses IP dans des plages non routables ou dédiées à l’adressage privé ;

• veiller à conserver un jeu d’enregistrements TXT en-deçà de 512 octets ;

• publier une politique entraînant au plus 10 requêtes DNS pour son évaluation.

En comparant le respect des bonnes pratiques entre 2023 et 2024, on peut constater une nette amélioration de la qualité des politiques SPF si on se fie aux indicateurs ci-dessus.

Tableau 1 :

Évolution du respect des bonnes pratiques dans les politiques SPF dans la zone .fr entre 2023 et 2024

Toutes ces métriques ont augmenté, sauf une. En effet, la proportion de domaines dont le jeu d’enregistrements TXT à l’apex n’excède pas 512 octets a légèrement diminué.

Taille des jeux d’enregistrements TXT

Quel intérêt de regarder cet indicateur en particulier ?

À l’origine, les messages DNS échangés en UDP ne pouvaient pas dépasser 512 octets. Au-delà, le serveur de noms faisant autorité doit tronquer la réponse et l’indiquer comme telle ; le résolveur doit alors refaire la même requête en TCP pour obtenir un jeu d’enregistrement complet, ce qui est beaucoup plus coûteux.

Et bien que le mécanisme d’extensions EDNS permette d’augmenter la taille maximale des messages en UDP, un examen du trafic DNS des serveurs de noms faisant autorité de l’Afnic entre février et avril 2024 montre que 19,5 % du trafic provient de résolveurs sans prise en charge d’EDNS. Rester sous les 512 octets reste encore pertinent aujourd’hui.

Or les politiques SPF sont publiées sous la forme d’enregistrements TXT à l’apex du domaine (c’est-à-dire directement sur domaine.example, plutôt qu’un sous-domaine comme le fait DMARC). Ils côtoient donc les autres enregistrements TXT qu’imposent certains éditeurs de plate-formes logicielles dans le cloud pour prouver le contrôle sur un domaine.

Un client de nombreux fournisseurs de logiciels de ce type qui imposent tous cette même méthode de vérification verra donc son jeu d’enregistrements TXT croître jusqu’à devenir trop volumineuse pour être servie en UDP, ce qui peut dégrader les performances à chaque fois qu’un serveur de messagerie souhaite obtenir la politique SPF du domaine concerné.

Les fournisseurs qui imposent des TXT à l’apex participent à ce qui est maintenant considéré comme une mauvaise pratique par un draft Internet. Ce document préconise entre autres de placer ce type de TXT dans des sous-domaines.

Politiques DMARC

Dans les grandes lignes, rappelons d’abord que DMARC permet au titulaire de domaine de recommander une action si un courrier électronique entrant échoue simultanément à SPF et à DKIM. Il s’offre trois possibilités : le terme p=reject dans une politique DMARC signifie « ne pas laisser passer le message » ; le terme p=none, à l’inverse, signifie « laisser passer le message quand même » et entre les deux se trouve p=quarantine, qui suggère une mise en quarantaine, par exemple en rangeant le message dans un sous-répertoire « indésirables » ou en la mettant dans une file d’attente pour un examen plus minutieux. Dans le dernier cas, la mise en quarantaine est faite avec une probabilité exprimé sous la forme d’un pourcentage par le terme pct, par défaut à 100.

La montée en flèche de l’adoption de DMARC va aussi de pair avec une nette diminution de la proportion de politiques p=none, essentiellement en faveur du p=quarantine. Le p=reject connaît quant à lui une progression très faible chez les domaines publiant un site Web mais plus importante chez les domaines dépourvus de site Web.

Les politiques DMARC sont donc à la fois plus nombreuses et plus strictes : les noms de domaine en .fr sont en théorie mieux protégés contre l’usurpation d’identité dans les courriers. Mais il s’agit toujours d’une infime minorité de domaines : on recense 117 243 domaines publiant un p=reject, soit 2,99 % de tous les noms de domaine en .fr ; cette proportion était de 1,34 % l’an dernier.

Une partie des titulaires de domaines a donc visiblement décidé de passer de p=none à p=quarantine. Le passage à p=reject est donc encore jugé risqué : la proportion de p=reject n’a pratiquement pas évolué chez les domaines avec une présence Web.

Quant aux domaines sans site Web, on observe aussi une chute libre du p=none. Ce recul est plutôt en faveur du p=quarantine là aussi, mais on voit également plus de domaines qui optent pour le p=reject. À ce rythme, il se peut que l’année prochaine, le p=reject surpasse le p=none parmi ces domaines-là.

Et BIMI ?

Regardons maintenant plus en détail l’adoption de BIMI au sein du .fr.

Tout d’abord, qu’est-ce que BIMI ? BIMI, ou Brand Indicators for Message Identification, est une spécification, encore à l’état de projet (« draft »), pour afficher des logos de marques à côté des messages émanant d’une entreprise donnée et dont l’authenticité a pu être vérifiée avec SPF, DKIM et DMARC. Le logo s’affiche seulement si le domaine publie une politique DMARC suffisamment stricte.

Le titulaire d’un domaine publie dans le DNS un enregistrement TXT qu’on appelle « enregistrement d’assertion BIMI ». Il contient deux informations : l’URL de l’image du logo à afficher et l’URL d’un certificat qui prouve le droit d’utiliser l’image, qu’on appelle VMC (Verified Mark Certificate). Un exemple :

default._bimi.domaine.example   IN TXT  (
   "v=BIMI1; l=https://domaine.example/logo.svg; "
   "a=https://domaine.example/vmc.pem" )

Pour adopter BIMI, le chemin est long

Un déploiement complet de BIMI nécessite beaucoup d’étapes préalables.

Tout d’abord, il faut avoir mis en place une politique DMARC p=reject, ou bien p=quarantine à condition que le terme pct ne soit pas précisé ou soit 100. Ce qui implique avoir mis en place SPF et DKIM préalablement.

Ensuite, il faut mettre à disposition le logo au format SVG (plus exactement, un profil particulier de SVG), puis publier l’enregistrement d’assertion BIMI comportant juste un terme l=. Ce type de déploiement BIMI est appelé « mode auto-certifié », car l’enregistrement d’assertion ne référence pas de certificat.

Cependant, certaines messageries exigent le mode dit « certifié » : en effet, il serait sinon facile pour un attaquant d’enregistrer un domaine usurpant une marque, de configurer SPF, DKIM et DMARC correctement et de copier le logo dans son assertion BIMI. Le mode certifié nécessite, en plus des prérequis pour le mode auto-certifié, un dépôt de la marque et des logotypes auprès de l’INPI ou un équivalent, l’achat d’un certificat VMC et l’ajout de l’URL dudit certificat dans l’enregistrement d’assertion BIMI.

Une adoption très faible

Par conséquent, qu’en est-il de l’adoption de BIMI ? Elle est très faible et se manifeste surtout chez les domaines ayant un site Web avec un contenu original, comme l’illustre le tableau ci-dessous.

Tableau 2 : Adoption de BIMI dans la zone .fr.

En regardant ces domaines de plus près, on trouve :

• 968 enregistrements d’assertion BIMI distincts et non nuls ;

• parmi eux : 70 enregistrements munis d’un URL d’un certificat VMC (les autres sont dits auto-certifiés) ;

• parmi ces 70 URL de VMC :

  • 58 URL pointent vers des certificats X.509 conformes aux exigences pour ce type de certificat,

  • 3 URL pointent vers des certificats X.509, mais non conformes (par exemple, des certificats TLS, qui sont aussi au format X.509),

  • 4 URL donnent une erreur 404 lors de la tentative d’accès,

  • 5 URL pointent vers autre chose qu’un certificat X.509 (images, clés GPG…).

On constate enfin que parmi ces 58 certificats VMC, le marché est dominé par deux autorités de certification : DigiCert (42 certificats) et Entrust (16 certificats), toutes deux des entreprises basées aux États-Unis.

Examen des certificats VMC

Chaque entreprise ayant obtenu un VMC a été classifié à la main dans un secteur d’activité. Il en ressort qu’il ne s’agit pratiquement que de grands groupes et qu’aucun service public n’a adopté BIMI. Les secteurs les plus représentés sont :

• le commerce en ligne (15 VMC) ;

• les services financiers (14 VMC) ;

• et le secteur des nouvelles technologies de l’information et de la communication (NTIC, 8 VMC).

Le tableau ci-dessous donne la répartition des entreprises ayant adopté un VMC par secteur, de manière plus détaillée.

Tableau 3 :
Secteurs d’activité des entreprises ayant investi dans un VMC, parmi les certificats trouvés dans des enregistrements BIMI dans la zone .fr

Explication de ces évolutions

Il y a quatre tendances qui sont, à mon avis, à l’origine de ces évolutions décrites plus haut : les fournisseurs de services de messagerie électronique qui commencent à exiger SPF, DKIM et DMARC ; l’attrait de BIMI ; l’impulsion d’autres industries et de services publics et les nouveaux modes opératoires de certaines escroqueries.

Services de messagerie électroniques

Les services de messagerie électroniques, soucieux de protéger leurs utilisateurs contre les courriers frauduleux, commencent à durcir les exigences vis-à-vis des messages qu’ils acceptent, notamment ceux venant de domaines à fort trafic.

En effet, depuis du 1^er février de cette année, GMail exige que le domaine expéditeur ait SPF ou DKIM (au moins un des deux). Et pour les gros expéditeurs qui envoient plus de 5 000 courriers par jour, il faut SPF, DKIM et DMARC. Yahoo exige la même chose depuis la même date.

GMail et Yahoo! Mail compteraient ensemble plus de 1,7 milliard d’utilisateurs. Ce sont autant de boîtes mail qui deviennent inaccessibles aux domaines qui ne déploient ni SPF, ni DKIM, ni DMARC.

Cette tendance pourrait continuer : si GMail et Yahoo Mail commencent à exiger SPF, DKIM et DMARC, d’autres services de messagerie électronique, soucieux de protéger leurs usagers contre les messages frauduleux, pourraient plus facilement leur emboîter le pas, car l’industrie de l’e-mailing s’est déjà adaptée.

BIMI et son attrait

Une deuxième explication est BIMI. Pour qu’une messagerie prenant en charge BIMI affiche le logo associé au domaine expéditeur, un des prérequis est la publication d’une politique DMARC stricte, c’est-à-dire un p=quarantine sans terme pct ou un terme pct=100, ou alors un p=reject.

Mais il est encore trop tôt pour dire si ce sont ces prérequis stricts qui ralentissent l’adoption de BIMI ou si, au contraire, c’est la perspective d’afficher des logos chez les clients qui incite à mettre en œuvre SPF, DKIM et DMARC pour ensuite déployer BIMI.

Autres industries et gouvernements

D’autres industries poussent aussi à l’adoption de SPF, DKIM et DMARC. C’est notamment le cas de PCI-DSS, un ensemble de normes visant à protéger les données financières. La version 4.0 de la norme PCI-DSS va rendre obligatoire la mise en place de SPF, DKIM et DMARC à partir du 1^er avril 2025.

Notons aussi l’initiative du gouvernement fédéral allemand, dont le Bundesamt für Sicherheit in der Informationstechnik (BSI) a publié en février 2024 un ensemble d’exigences techniques (en anglais et en allemand) vis-à-vis de l’authentification des courriers, entièrement consacré à SPF, DKIM et DMARC.

Autres considérations

Enfin, à l’heure où les IA génératives soulèvent des inquiétudes vis-à-vis de l’usage qu’il est possible d’en faire pour réaliser des hameçonnages convaincants, voire fortement personnalisés (spear phishing), il est d’autant plus important de pouvoir faire confiance aux en-têtes d’un message. D’autant plus qu’il est maintenant avéré que des acteurs étatiques, comme la Corée du Nord (PDF), n’hésitent pas à abuser de domaines mal protégés pour réaliser des campagnes de hameçonnages ciblés.

Futurs enjeux

Toutes ces observations amènent à s’interroger sur deux sujets en particulier : l’efficacité de SPF, DKIM et DMARC quand l’expédition de courriers est confié à des entreprises tierces et la possible domination du marché des certificats VMC pour BIMI par des acteurs basés aux États-Unis.

Externalisation des courriers : source de failles pour SPF, DKIM et DMARC ?

L’efficacité de SPF repose sur l’hypothèse que chaque domaine ait sa propre infrastructure pour émettre ses courriers, sans aucune mutualisation de moyens. Confier l’envoi de messages à un tiers, qu’il s’agisse d’un hébergeur, d’une plateforme applicative ou d’un prestataire d’envoi de courriers (ou « routeur ») va à l’encontre de cette hypothèse et affaiblit donc les garanties qu’apporte SPF.

En particulier, externaliser l’envoi de courriers électroniques ainsi nécessite d’inclure dans sa politique SPF une sous-politique contrôlée par le prestataire et qui liste de grandes plages d’adresses IP. Or qu’est-ce qui empêche un client d’un prestataire d’usurper l’identité d’un autre client du même prestataire, si l’un comme l’autre sont obligés de publier une politique SPF laxiste ? SPF n’est pas une contre-mesure efficace dans ce scénario. Avec le moindre include, la qualité de la politique SPF du domaine devient directement dépendante de la qualité des sous-politiques.

L’affaiblissement des garanties de SPF entraîne aussi un affaiblissement de ceux de DMARC, ce qui crée donc le risque d’afficher à tort le logo d’une entreprise à côté d’un courrier frauduleux.

BIMI et autorités de certification : vers une concentration du marché autour d’acteurs états-uniens ?

Le développement de BIMI entraîne l’émergence d’un nouveau marché d’émetteurs de certificats VMC, parallèle à celui des certificats TLS. Tous les certificats VMC rencontrés au cours de l’étude sont émis par des entités basées aux États-Unis.

Il existe certes des organismes français chez qui on peut obtenir un certificat adéquat pour BIMI, mais il s’agit de revendeurs des sociétés américaines DigiCert et Entrust. En tout état de cause, aucune trace du revendeur n’apparaît dans le certificat.

Pour qu’un autorité de certification française puisse émerger dans ce marché, il faudrait qu’il parvienne à convaincre les différentes messageries de faire confiance aux certificats qu’il émet. Il s’agit d’un problème analogue à celui des certificats TLS, où toute nouvelle autorité de certification doit trouver un moyen de figurer parmi les autorités auxquelles les navigateurs font confiance par défaut.

Conclusion

Nous avons vu dans ce billet une évolution positive de l’adoption de SPF, DKIM et DMARC. Il s’agit d’un cercle vertueux : plus ces mécanismes sont adoptés, plus ils deviennent indispensables. Mais mal configurés, ils peuvent se retourner contre les titulaires des noms de domaine concernés. C’est pourquoi il est important de savoir comment configurer SPF, DKIM et DMARC correctement.

À cette fin, l’Afnic propose une formation sur SPF, DKIM et DMARC destinée aux professionnels de l’informatique et aux titulaires de domaine. En attendant la prochaine session, vous pouvez également explorer les autres ressources que l’Afnic met à disposition sur le même sujet :

• l’outil Zonemaster, qui comporte un test de la syntaxe des politiques SPF ;
• une présentation et une démonstration sur scène de SPF, DKIM et DMARC à la Journée du Conseil Scientifique de l’Afnic (JCSA) en 2023, que l’on peut revoir en vidéo ;
• et le code source du tutoriel SPF, DKIM et DMARC ayant servi dans cette démonstration sur scène.

Et vous, votre nom de domaine est-il déjà protégé contre les acteurs malveillants ?