SPF, DKIM, DMARC et BIMI sur .fr : toujours à la hausse en 2025

L’adoption continue de croître

Commençons par comparer les statistiques d’adoption entre 2023, 2024 et 2025. Avant toute chose, profitons-en pour changer légèrement la méthodologie : au lieu d’examiner seulement les domaines publiant au moins un enregistrement MX à l’apex, nous examinerons dorénavant tous les domaines en .fr. En effet, tous les domaines sont concernés par le risque d’usurpation d’identité : il est donc important de configurer des politiques SPF et DMARC défensifs sur les domaines qui ne sont pas utilisés pour envoyer des courriers électroniques. De plus, un domaine sans enregistrement MX ne signifie pas qu’il n’accepte pas de courrier électronique (seul un MX nul, décrit dans la RFC 7505, permet de le signaler) et ne dit rien sur son intention d’en émettre.

Pour ces raisons, nous étudierons dorénavant tous les domaines, qu’ils possèdent un enregistrement MX ou non. Ainsi, nous capturerons mieux l’adoption de SPF, DKIM et DMARC au sein de l’ensemble des domaines en .fr.

Comme on peut le voir sur le graphique ci-dessous, l’adoption de SPF, DKIM et DMARC a beaucoup augmenté entre 2023 et 2025. SPF semble avoir atteint un point d’inflexion, tandis que DKIM connaît un léger sursaut et DMARC continue d’augmenter également.

Les politiques DMARC évoluent-elles ?

Pour un nouveau déploiement de DMARC sur un domaine, le conseil usuel est de commencer par publier une politique DMARC p=none comportant une adresse sur laquelle recevoir les rapports automatisés (tag rua), d’analyser minutieusement chaque rapport qui arrive et de faire les modifications qui s’avèrent nécessaires. Une fois qu’on a la certitude que tout le trafic authentique est correctement authentifié, on peut passer de p=none à p=quarantine ou p=reject.

Cependant, ce conseil est-il suivi en pratique ? Comment les politiques DMARC existantes ont-elles évolué en deux ans ?

Si on regarde au niveau macroscopique, on constate que les proportions des termes p=none, p=quarantine et p=reject ont beaucoup changé. Cette fois-ci, entre 2024 et 2025, la proportion de p=quarantine a diminué tandis que les autres ont augmenté.

Tableau 1 : Proportions des termes p des politiques DMARC des noms de domaine en .fr, entre 2023 et 2025.

Mais comment peut-on expliquer les changements dans ces proportions ? Le diagramme ci-dessous apporte une vue plus détaillée sur l’évolution dans le temps de l’ensemble des politiques DMARC recensées sur les noms de domaine en .fr.

Ainsi, on voit que sur deux années consécutives, l’augmentation en nombre absolu des politiques DMARC p=quarantine et p=reject a été très majoritairement dû à de nouveaux déploiements de DMARC qui ont immédiatement opté pour un mode plus restrictif. On voit notamment très peu de passages de p=none à p=quarantine ou p=reject d’année en année. Autrement dit, une politique p=none qui a été publié en 2023 a de grandes chances de rester en p=none deux ans plus tard.

BIMI

Pour rappel, BIMI est un mécanisme qui permet d’afficher le logotype d’une organisation à ses courriers envoyés avec une politique DMARC.

Une légère croissance en trompe-l’œil

En 2024, nous avions déterminé que 2 435 domaines ont déployé BIMI. En 2025, nous avons recensé 2 547 domaines, soit une croissance de 4,6 %.

Ce chiffre de croissance cache cependant une autre réalité : presque 40 % des déploiements BIMI recensés en 2024 ont été supprimés l’année suivante. Mais ceci est largement compensé par de nouveaux déploiements de BIMI venant d’autres domaines, y compris des domaines qui n’existaient pas en 2024.

En effet, les suppressions de BIMI se répartissent ainsi :

• 800 domaines avec BIMI qui n’existaient plus en 2025 ;
• 89 domaines qui sont passés en « état indéterminé », c’est-à-dire qu’il n’était plus possible de déterminer avec certitude l’adoption ou non de BIMI sur ce domaine ;
• 81 domaines qui ont supprimé leurs enregistrements BIMI.

En face, nous avons de nouveaux déploiements, répartis ainsi :

• 523 domaines qui existaient déjà en 2024 et qui n’avaient pas BIMI l’année dernière ;
• 163 domaines qui existaient déjà en 2024 mais qui étaient en « état indéterminé » ;
• et 396 nouveaux domaines.

La figure ci-dessous représente graphiquement cette évolution.

Sur 2 547 domaines, nous avions eu accès directement à 1 443 enregistrements d’assertion BIMI, qui se trouvaient au sélecteur par défaut (c’est-à-dire default._bimi.domaine.example). On élimine un enregistrement comportant une erreur de syntaxe et trois assertions nulles.

On distingue deux modes de déploiement BIMI : le mode certifié et le mode auto-certifié. Dans le mode certifié, on publie l’URL d’un logo et, en sus, celui d’un certificat (Verified Mark Certificate ou Common Mark Certificate) qui prouve qu’on a un droit sur la marque ou le logo et donc le droit de l’utiliser. Dans le mode auto-certifié, on publie seulement l’URL du logo sans y associer de certificat.

Ainsi, nous constatons que sur 1 439 assertions BIMI bien formées, 1 312 (91,2 %) sont en mode auto-certifié et 127 (8,8 %) sont en mode certifié.

BIMI en mode certifié : 30 % des configurations sont incorrectes

Il ne suffit cependant pas de pointer vers une URL de certificat dans un enregistrement BIMI pour que la configuration soit correcte. Tout d’abord, il faut que l’URL fonctionne et qu’elle mène à un certificat X.509. Ensuite, il faut que le certificat soit émis par une autorité de certification reconnue, qu’il soit explicitement désigné pour être utilisé dans le cadre de BIMI et qu’il ne soit pas expiré. Enfin, le courrier doit avoir été authentifié avec une politique DMARC stricte : p=quarantine sans terme pct, p=quarantine avec pct=100 ou p=reject.

Or notre analyse montre que sur 127 domaines publiant un enregistrement d’assertion BIMI en mode certifié sur le sélecteur default, 30 % possèdent une configuration incorrecte. Si les messages émanant de ces domaines utilisent le sélecteur BIMI default, les messageries compatibles risquent donc de refuser d’afficher le logo désigné par la configuration BIMI.

En effet, parmi ces 127 enregistrements d’assertion BIMI susmentionnés, nous avons extrait 110 URL distinctes. Après analyse, seules 73 URL menaient à un certificat valable, ce qui correspond à 89 domaines.

Les erreurs de configuration observées sont de natures très diverses :

• Certificats BIMI expirés : 13 certificats (affectant 14 domaines) pointaient vers un VMC qui avait expiré au moment où il a été récupéré. Le temps écoulé entre l’expiration et la récupération variait entre 12 et 960 jours, avec une médiane de 102 jours ;
• Certificats BIMI émis par Entrust après le 15 novembre 2024 : une série d’incidents impliquant l’autorité de certification Entrust a conduit au retrait du certificat de la liste des autorités de certification reconnues par diverses entités, comme Google. Pour BIMI, Apple a notamment cessé de reconnaître les certificats d’Entrust émis à partir du 15 novembre 2024. Quatre certificats sont dans ce cas, affectant quatre domaines.
• Configuration DMARC inadéquate : BIMI ne fonctionne que si le courrier a été authentifié à l’aide d’une politique DMARC stricte. Cependant, 3 domaines publiaient une politique DMARC p=none ou omettaient d’en publier une, rendant ainsi BIMI inopérant pour au moins une partie des courriers émanant du domaine, sauf si les messages soient envoyés depuis un sous-domaine doté d’une configuration DMARC plus stricte. Ces 3 domaines correspondent à 3 certificats.
• Erreurs HTTP : au total, 8 URL étaient inaccessibles. Parmi elles, 5 URL (affectant 5 domaines) donnaient une erreur 404 et 3 URL (affectant 3 domaines) donnaient une erreur 403. Cela affecte 8 domaines.
• Certificats TLS expirés : dans un cas, ce n’était pas le certificat VMC lui-même qui était expiré, mais celui présenté par le serveur HTTPS qui l’héberge. Étant donné que l’URL du VMC doit obligatoirement être un URL https, cela montre bien qu’il y a non pas un, mais deux certificats cryptographiques à superviser dans un déploiement BIMI. Cette erreur de configuration affecte un domaine.
• Certificats X.509 bien formés mais non valables pour BIMI : les certificats utilisés par BIMI sont dans le format spécifié par la recommandation UIT-T X.509, comme les certificats utilisés pour TLS (et donc HTTPS, entre autres). Pour qu’un certificat soit valable pour BIMI, il doit signaler qu’il est valable pour cet usage : cela signifie qu’il doit comporter un attribut « X.509 v3 Extended Key Usage » qui liste l’OID dédié pour BIMI, 1.3.6.1.5.5.7.3.31. Quatre certificats sont dans ce cas de figure, ce qui affecte quatre domaines.
• URL ne pointant pas vers un certificat : quelques URL désignaient autre chose qu’un certificat. Dans quatre cas (concernant 4 domaines), le fichier récupéré n’était pas un certificat X.509 : il y avait une clé publique GPG, une image et deux pages HTML. Cela concerne 4 domaines au total.

Le tableau ci-après donne une synthèse de ces observations.

Tableau 2 : Synthèse des erreurs de configuration constatées dans des déploiements de BIMI en mode certifié.

Maintenir une configuration BIMI en mode certifié n’est pas une tâche facile : en témoigne la part non négligeable de domaines qui, malgré une telle configuration, ont un ou plusieurs problèmes pouvant entraîner le refus, par une messagerie, d’afficher le logo malgré la présence du certificat.

Pensez à protéger vos domaines parqués !

Un domaine parqué, c’est un nom de domaine enregistré mais non exploité. Il peut s’agit d’un nom de domaine enregistré en amont d’un projet, d’un enregistrement défensif pour éviter d’être victime de typosquatting, d’un domaine mis en vente par son titulaire… Quel que soit le cas de figure, les domaines parqués nécessitent eux aussi une configuration de SPF et de DMARC pour éviter qu’ils soient utilisés comme adresse d’expédition par des personnes tierces mal intentionnées.

Voici un exemple d’un message de hameçonnage qui a été porté à notre attention l’année dernière :

De: Paiement loyer <quittancepaiementloyer@[domaine].fr>
À: [destinataire]
Objet: Quittance

Bonjour,

Votre paiement du mois de novembre n’est pas enregistré dans notre fichier comptable.

Veuillez svp nous envoyer votre quittance de paiement pour que nous puissions
vérifier et confirmer votre paiement du mois.
Avez-vous reçu nos nouvelles coordonnées bancaires (RIB) pour le règlement
du loyer du mois de novembre ?

E-mail de contact : [adresse de courrier électronique]

Nous vous prions d’agréer nos salutations les plus chaleureuses.

La comptabilité

L’adresse d’expédition (RFC5322.From) usurpait un domaine en .fr à l’insu de son titulaire. L’adresse de l’enveloppe (RFC5321.MailFrom) comportait cependant un domaine différent du premier et le message n’était pas signé avec DKIM. Si DMARC avait été configuré sur ce domaine, il y aurait eu un échec simultané de SPF, par absence d’alignement entre les domaines des adresses d’expédition dans l’enveloppe et dans l’en-tête, et de DKIM, par absence de signature, et donc un échec de DMARC.

Mais le domaine de l’adresse d’expédition (RFC5322.From) ne publiait pas de politique DMARC, ce qui a contribué à rendre possible cette usurpation d’identité. Il publiait certes une politique SPF dite « nulle » (c’est-à-dire v=spf1
-all), mais sans DMARC, la configuration de ce domaine, qui n’a aucune raison d’être à l’origine de courriers électronique, était incomplète. Un simple DMARC p=reject aurait rendu cette campagne de hameçonnage moins efficace.

Le titulaire aurait-il pu corriger cette configuration ? Son domaine était parqué chez une plateforme de revente. Celle-ci demande à ses clients de changer les serveurs de noms pour le nom de domaine ; ils sont ensuite configurés pour servir le même fichier de zone pour tous les domaines délégués à eux. En parquant le domaine chez eux, le titulaire perd le contrôle sur le contenu de la zone correspondante et c’est à la plateforme qu’il incombe de la configurer correctement. Le titulaire n’a donc pas eu la possibilité de durcir son domaine parqué contre ce risque.

En conclusion : passez en revue votre portfolio de domaines parqués et vérifiez s’il y a bien des enregistrements SPF et DMARC défensifs. Un exemple d’une bonne configuration défensive se trouve dans un guide de bonnes pratiques publié par le M³AAWG.

Et bientôt, DMARCbis

DMARCbis, le successeur de DMARC, est en passe d’être publié. Actuellement à l’état de brouillon (avec des spécifications séparées pour le format des rapports agrégés et celui des rapports individuels), cette future RFC sera une proposition de norme (proposed standard), tandis que la RFC 7489 est une RFC informative (informational). Il s’agit notamment d’intégrer le retour d’expérience de nombreux déploiements de DMARC et de corriger quelques détails.

Parmi les principaux changements, DMARCbis spécifie une méthode différente pour déterminer le domaine organisationnel associé au domaine de provenance d’un courrier ; il reconduit le tag np, un ajout tardif à DMARC spécifié dans la RFC 9091 ; les tags pct, rf et ri sont dépréciés et pour les envois de rapports, la vérification des destinataires externes, actuellement facultative, devient obligatoire.

Domaine organisationnel et suffixes publics

Tout d’abord, qu’est-ce que le domaine organisationnel ? Dans l’esprit de DMARC, il s’agit du domaine qui a été enregistré immédiatement sous un suffixe public. Conserver aveuglément les deux dernières composantes du nom de domaine peut mener à des erreurs : par exemple, pour l’adresse ne-pas-repondre@dgfip.finances.gouv.fr, le domaine qui a été enregistré auprès de l’Afnic est finances.gouv.fr et non pas gouv.fr.

L’algorithme actuel fonctionne comme suit : parmi les suffixes de la Public Suffix List, déterminer le suffixe le plus long qui s’y trouve (ici gouv.fr) puis ajouter une étiquette à droite pour en déduire le domaine organisationnel, finances.gouv.fr. Cette méthode a quelques inconvénients : il faut maintenir un exemplaire local de la Public Suffix List à jour, car la liste peut changer.

DMARCbis, quant à lui, s’affranchit entièrement de la Public Suffix List et s’appuie uniquement sur le DNS et son modèle arborescent. On procède comme suit : on essaye d’abord d’obtenir une politique DMARC pour le domaine exact, dgfip.finances.gouv.fr. S’il n’y en a pas, on essaye successivement le domaine parent (tronqué aux 7 étiquettes les plus à droite pour ne jamais faire plus de huit requêtes), puis son parent à lui, et ainsi de suite, jusqu’au domaine de premier niveau inclus (comme fr) ou jusqu’à trouver une politique DMARC avec un tag psd=y ou psd=n (PSD pour Public Suffix Domain). Ensuite, il y a trois possibilités : si on a trouvé une politique DMARC avec psd=n, le domaine organisationnel est le domaine où se trouve cette politique DMARC. Si on a trouvé une politique DMARC avec psd=y, alors il s’agit d’un suffixe public : le domaine organisationnel est alors le domaine qui se trouve immédiatement sous le suffixe. Si aucune politique DMARC n’a de tag psd=y ni psd=n, on applique la politique DMARC trouvé au domaine le plus long. La procédure complète se trouve dans le paragraphe 4.10.2 de DMARCbis.

En résumé : plutôt que de se reposer sur une liste centralisée qu’il faut penser à tenir à jour régulièrement, on détermine le domaine organisationnel par un nouveau mécanisme qui permet aux administrateurs de suffixes publics de s’auto-déclarer comme tels.

Tags dépréciés

Ensuite, le tag pct, qui recommandait d’appliquer un terme p=reject ou p=quarantine que sur un certain pourcentage de messages entrants, est déprécié en faveur d’un nouveau tag t prenant la valeur y ou n, qui sert à indiquer un déploiement de DMARC en phase de test.

En effet, un usage détourné du tag pct consistait à publier une politique restrictive (p=quarantine ou p=reject) avec un pct=0 : cela avait l’effet émergent de dégrader un p=quarantine en p=none et un p=reject en p=quarantine et servait de fait comme un signal d’un déploiement en cours de test. Les pourcentages n’étaient pas non plus toujours respectés par les systèmes destinataires et les seules valeurs garantissant un traitement déterministe étaient donc 0 et 100.

Deux autres tags sont dépréciés : rf, qui spécifie le format des rapports d’échec individuels souhaité, et ri, l’intervalle de temps entre deux rapports agrégés, ne seront plus pris en compte par des destinataires conformes à DMARCbis.

Vérification des destinataires externes

Un autre changement concerne la vérification des destinataires externes. L’idée est d’éviter qu’un acteur malveillant publie une politique DMARC dans le seul but d’inonder une messagerie d’un tiers avec des rapports qu’il n’a pas demandés. Ainsi, si le domaine arles.example publie une politique DMARC avec le terme rua=dmarc@brest.example, il faut que brest.example indique qu’il accepte de recevoir les rapports concernant arles.example : cela se fait en publiant un enregistrement TXT contenant le texte v=DMARC1; au nom de domaine arles.example._report._dmarc.brest.example.

Mais vérifier la présence de cet enregistrement spécial n’était pas obligatoire dans la RFC 7489 : c’est en effet un « SHOULD ». DMARCbis change ce « SHOULD » en « MUST ».

À l’heure actuelle, cette vérification des domaines externe est loin d’être systématiquement faite par les principaux fournisseurs de services de messagerie, comme le montre Hureau et al., 2024. Mais la mise en œuvre de DMARCbis pourrait amener la situation à changer.

Conclusion

Il reste encore du chemin à faire avant une couverture complète de tous les noms de domaine en .fr. Mais le fait est qu’aujourd’hui, la capacité de SPF, DKIM et DMARC de rendre plus difficile l’usurpation d’identité dans les courriers électroniques est suffisamment reconnue pour que de plus en plus de messageries publiques exigent qu’un domaine expéditeur ait adopté ces trois mécanismes. Avec DMARCbis qui apporte une réponse à quelques inconvénients du DMARC actuel et qui consolide une décennie de retours d’expérience, il faut s’attendre à ce que SPF, DKIM et DMARC deviennent un requisit pour que le courrier ait une chance d’être accepté, à l’instar d’autres mesures ayant eu pour but de lutter contre le spam.

L’adoption de BIMI reste timide et demeure cantonnée à des entreprises qui ont les moyens financiers et voient l’intérêt d’investir de l’argent dans les certificats nécessaires à un déploiement complet. Néanmoins, au vu du prix d’un tel certificat, il est étonnant de constater une part importante de déploiements de BIMI en mode certifié qui risquent fort de mener à un non-affichage du logo.

Quant à DMARCbis, quelques mesures seraient utiles à prendre dès maintenant afin d’être prêt lorsque la RFC sera publiée :

• Pour les registres : s’il est possible, ou s’il a été possible dans le passé, d’enregistrer un nom de domaine dans un suffixe de second niveau comme asso.fr ou co.uk, un enregistrement DMARC associé à ces suffixes, avec le terme psd=y serait souhaitable.
• Pour les administrateurs de domaines sous un suffixe de second niveau, l’ajout d’un terme psd=n à la politique DMARC associée au nom de domaine est recommandée pour éviter qu’une politique DMARC plus en haut dans l’arborescence ne s’applique.
• Pour toutes les politiques DMARC existantes, il faudra envisager de supprimer les termes rf, ri et pct des politiques DMARC existantes, car elles ne seront plus prises en compte par des mises en œuvre de DMARCbis.
• Quant aux fournisseurs de services de messagerie grand public, il y a peut-être des usagers qui reçoivent des rapports DMARC sur une adresse chez eux. Par exemple, il n’est pas rare de trouver des politiques DMARC qui désignent une adresse Gmail pour recevoir les rapports. Mais le nœud _report._dmarc.gmail.com n’existe pas dans le DNS, donc toute messagerie destinataire conforme à DMARCbis refuserait systématiquement d’envoyer le rapport à la moindre boîte Gmail. Dans ce cas, il y a deux options : l’administrateur du domaine désigne une adresse différente, ou bien Google doit publier une entrée TXT v=DMARC1; au nom joker *._report._dmarc.gmail.com.

Enfin, n’oubliez pas que 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.