Explications complètes sur SPF, DKIM, DMARC et ARC (et leurs pièges)

Si vous avez déjà géré votre propre domaine pour envoyer des mails, vous avez sûrement dû entendre parler des protocoles SPF, DKIM, DMARC (et peut-être de ARC, qui commence également à être répandu), qui servent à authentifier les mails que vous envoyez.

Ces protocoles sont indispensables si nous voulons que nos mails ne soient pas rejetés lorsqu'ils arrivent chez les autres fournisseurs. Cependant, ces protocoles sont souvent mal compris et sont sources de problèmes et de frustrations... et ont en plus quelques « pièges » qu'il vaut mieux connaître pour éviter de nombreuses incompréhensions.

Cet article donne donc des explications claires sur l'utilité de chaque protocole, et comment il fonctionne.

Le protocole SMTP : un protocole simple, trop simple

Tout d'abord, il faut se poser la première question : pourquoi a-t-on besoin de ces protocoles ?

Le protocole SMTP (celui qui sert à envoyer des mails, et les faire transiter jusqu'au serveur du destinataire) est ancien, très ancien même, puisque les premières versions datent de 1982 (ce qui représente l'Antiquité en informatique) ! Et malgré quelques ajouts au protocole, notamment en 2008, il n'a pas vraiment changé depuis. Et comme les mails sont au centre du monde numérique d'aujourd'hui, autant dire qu'il n'est pas près d'être remplacé.

Cependant, comme ce protocole est ancien, il comporte de nombreux « trous » et problèmes liés à la sécurité. Et le très gros problème, c'est qu'il n'a aucun mécanisme d'authentification de l'expéditeur, ni de chiffrement des mails. Tout comme je peux écrire n'importe quoi dans une lettre et sur une enveloppe que j'envoie par la poste, je peux théoriquement envoyer ce mail de mon propre serveur :

From: vladimir.putin@kremlin.ru
To: joe.biden@whitehouse.gov
Subject: Concours de missiles nucléaires

Nous venons d'envoyer un missile nucléaire vers Washington D.C.
Voyons voir qui a les meilleures armes atomiques !!!

... et, s'il n'y avait que SMTP, cela marcherait parfaitement, et le président des États-Unis recevrait le message.

Ne pas pouvoir identifier les messages illégitimes peut donc avoir de fâcheuses conséquences. Pour cette raison, on a mis au point des mécanismes pour authentifier les expéditeurs des mails.

Il y a deux entêtes From !

Avant de commencer à parler de ces quatre protocoles, il est primordial de comprendre quelque chose lorsqu'on parle des mails.

Les entêtes d'un mail incluent une entête From, où l'adresse mail de l'expéditeur (souvent accompagnée de son nom) est indiquée. C'est cette entête-là que l'on voit dans notre logiciel de messagerie ou notre boîte mail en ligne.

Mais... il y a aussi une autre entête From. Elle fait partie de l'enveloppe SMTP, et c'est celle que les serveurs de messagerie vont lire (tout comme un facteur va regarder l'adresse sur l'enveloppe, et non pas sur la lettre). C'est ce qu'on appelle le MAIL FROM.
Comme elle se trouve dans la transmission SMTP et non pas dans le message, elle n'était à l'époque pas écrite dans les entêtes du message, et la personne destinataire ne pouvait donc pas la connaître (cependant, aujourd'hui, les serveurs SMTP la rajoutent dans les entêtes du message)

Pour continuer avec l'analogie de l'enveloppe, voilà une représentation imagée :

Il est très important de comprendre cela car l'une ou l'autre des entêtes, voire les deux, vont être impliquées selon le protocole.

Le protocole SPF : « ce serveur a-t-il le droit d'utiliser ce domaine ? »

Le protocole SPF (Sender Policy Framework) est le premier mécanisme à être apparu au début des années 2000. SPF permet à un domaine d'annoncer quelles adresses IP sont autorisées à envoyer des mails de sa part.

Le concept est simple : dans les enregistrements DNS du domaine, un enregistrement TXT va être créé avec une syntaxe précise.

interieur.gouv.fr. 21599 IN TXT "v=spf1 mx include:_spf.interieur.gouv.fr ~all"

Lorsqu'un serveur SMTP va être le destinataire d'un mail en provenance d'une adresse en @interieur.gouv.fr, il va faire une requête DNS sur interieur.gouv.fr pour vérifier s'il y a un enregistrement TXT correspondant à une syntaxe SPF. Si c'est le cas, il va vérifier si l'IP dont provient le mail est mentionnée dans l'enregistrement.

Dans le cas de interieur.gouv.fr, nous pouvons voir que l'IP de l'enregistrement MX est autorisée (mx), mais également les IP mentionnées dans _spf.interieur.gouv.fr (include). Voyons voir lesquelles:

_spf.interieur.gouv.fr. 3598 IN TXT "v=spf1 ip4:143.196.250.170 ip4:143.196.250.171 ip4:143.196.250.172 ip4:92.103.164.16 ip4:92.103.164.17 ip4:92.103.164.18 ip4:37.235.90.62 -all"

Si le mail provient d'une de ces IP (ip4), le mail est accepté. Sinon, cela dépend de ce qu'on met devant le all : ici, les mails seront rejetés. (Pour plus d'informations sur la syntaxe, voir ici).

Simple, n'est-ce pas ?

Cependant, SPF vient avec un gros piège. J'ai dit juste avant qu'il y avait deux entêtes From, avec donc potentiellement deux adresses mail différentes, voire deux domaines différents. Et dans le cas de SPF, le domaine qui est pris en compte n'est pas celui du From dans le mail, mais le From de la transmission SMTP (MAIL FROM).

Ainsi, l'exemple ci-dessus avec Vladimir Poutine pourrait toujours marcher : je n'aurais qu'à mettre ma vraie adresse mail dans le MAIL FROM et mettre celle de Poutine dans le message, et comme j'autorise mon IP à envoyer des mails de ma part, alors le message serait quand même accepté. On n'est donc pas plus avancés...

Nous verrons plus tard que DMARC permet de corriger le tir.

Le protocole DKIM : « est-ce que le message n'a pas été modifié ? »

Si SPF sert à s'assurer que l'expéditeur est bien celui qu'on croit, DKIM (DomainKeys Identified Mail) permet de vérifier que le message n'a pas été modifié pendant sa transmission. En effet, je rappelle que les transmissions SMTP ne sont pas chiffrées, et que n'importe qui peut lire, voire modifier, votre message en cours de route...

DKIM permet de signer le corps du message, ainsi que les entêtes que l'on veut, grâce à une signature cryptographique. (Je ne rappellerai pas ici ce qu'est une signature cryptographique pour ne pas alourdir cet article déjà long... voici donc un lien qui l'explique bien).

Une entête nommée DKIM-Signature va être ajoutée au message, avec une syntaxe spécifique :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=mailer.humblebundle.com; s=scph0816; t=1635536100;
	i=@mailer.humblebundle.com;
	bh=5yS0HzsKb/VRAOAlTKiEDg4K3nvcGpRSE+HpaCMJSHU=;
	h=Content-Type:To:Message-ID:Date:Subject:From;
	b=Ka9SJ+4Rvl7VnNJbd+BFNQN0zUb4kPXAmQkgDlrHhRQdItiSY8yePJMrs89nyzjzN
	 jhFy9hmGoIB3xvLj/VrDsz/Cw+1jEGzPgsvjJVL9xm4blLImUjdoOrMNmlg9Zd66eI
	 KRabpS2g0uzeGBFjsHuqryQ4G26nni32ZcGiy+kI=

Nous pouvons voir à l'intérieur des informations comme l'algorithme utilisé (a=rsa-sha256), le domaine où aller chercher la clé publique (d=mailer.humblebundle.com; s=scph0816), les entêtes signées (h=Content-Type:To:Message-ID:Date:Subject:From) ainsi que les empreintes cryptographiques (bh pour les entêtes, b pour le corps), et bien d'autres (voir ici).
Comme pour SPF, la clé publique se trouve dans un enregistrement TXT du domaine spécifié par la clé d. Plus précisément, il se trouve dans un sous-domaine scph0816._domainkey.mailer.humblebundle.com, où scph0816 est le nom donné par s (c'est ce qu'on appelle le sélecteur dans la terminologie DKIM).

Voilà ce qu'on trouve dans le DNS. Nous pouvons voir la clé publique :

scph0816._domainkey.mailer.humblebundle.com. 300 IN TXT "k=rsa p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCCgJt0/mcwMGil9BhQ2z/Y7NTFBKOil2A0q5QleS8uvX2Gys4yLIRC871VpPNaHXv3KASDr2Pd3Mc0iQh1ZXVkEaA1CVjb1Xsyr5dtoikHfpGoTAwAzctXuenRQqjpekT4BIyqod/xN0e7rq/RJ0yKgye0NBmirbryFGHgXCkBdQIDAQAB"

Mais DKIM souffre du même problème que SPF. Je viens en effet de dire que le domaine où la vérification est faite est spécifié par la valeur d. Or, comme vous pouvez vous y attendre, cette valeur peut être ce que l'on veut, tant que les signatures sont valides.
Donc, encore une fois, si je voulais envoyer le mail que je mentionne au début, il suffit que je mentionne mon propre domaine dans l'entête DKIM, et même si les deux From sont différents, le mail passera quand même (bien que quelqu'un qui regarde les entêtes du mail pourra voir qu'il y a quelque chose de suspicieux)

En plus, DKIM cause un autre problème. Certains serveurs de mail – et c'est un cas très courant dans les listes de diffusion (mailing lists) ou les newsletters – changent le contenu du mail, souvent pour ajouter un tag dans le sujet du mail. Ainsi, bien que ce soit une opération légitime, elle est tout de même invalidée par le protocole DKIM. Pour cette raison, DKIM est difficile à mettre en oeuvre dans ce contexte (à moins d'utiliser ARC, comme on verra plus bas)

Le protocole DMARC : perfectionne SPF et DKIM, et ajoute des fonctionnalités

DMARC (Domain-based Message Authentication, Reporting and Conformance) est un protocole qui vient « chapeauter » SPF et DKIM. Il apporte quelques améliorations dans tout ce monde de l'authentification des mails :

• Un domaine peut dire à un serveur destinataire comment traiter un email entrant si ni SPF ni DKIM ne sont valides
• Permet à un administrateur de domaine de recevoir des rapports quant aux mails venant (ou semblant venir) de son domaine
• Corrige les défauts de SPF et DKIM mentionnés plus haut, grâce à une vérification supplémentaire nommée « alignement ».

Que faire si SPF et DKIM ne passent pas ?

Jusqu'ici, si un mail arrive et que ni SPF ni DKIM ne sont valides, le serveur destinataire n'a pas vraiment d'indication sur ce qu'il doit faire. Certains serveurs vont mettre le mail dans la quarantaine ou les spams de l'utilisateurs, d'autres vont tout simplement le supprimer, d'autres vont ajouter une mention dans le mail du type « attention, ce mail n'est pas certifié... ». D'autres peuvent juste ne rien faire et le laisser passer.

DMARC fonctionne, une nouvelle fois, grâce au DNS. Une entrée TXT est déclarée dans _dmarc.example.com, où example.com est le domaine spécifié dans l'entête From du mail:

_dmarc.doctolib.fr. 120 IN TXT "v=DMARC1 p=reject rua=mailto:4q5jhtt3@ag.eu.dmarcian.com, mailto:dmarc@doctolib.com, ruf=mailto:4q
5jhtt3@fr.eu.dmarcian.com, mailto:dmarc@doctolib.com; sp=reject; fo=0

Un serveur destinataire, lorsqu'il recevra un mail dont le From (dans l'email) sera en @doctolib.fr, va donc faire une requête DNS sur _dmarc.doctolib.fr et vérifier cet enregistrement. Si ni SPF ni DKIM ne sont valides, il va regarder la valeur p pour savoir quoi faire. Ici, la valeur est « reject » ce qui veut dire « supprime le message sans poser de questions ».

DKIM permet aussi de faire d'autres choses très intéressantes. Nous voyons, en plus de la valeur p, des valeurs rua et ruf dans l'enregistrement. Ces valeurs servent à indiquer une adresse mail à laquelle les serveurs destinataires peuvent envoyer des rapports lorsque les mails échouent les vérifications SPF et DKIM.
Ainsi, les administrateurs des serveurs liés au domaine de l'expéditeur (ici doctolib.fr) peuvent les recevoir. Cela est très utile pour investiguer des problèmes liés à leur configuration de DMARC, mais aussi pour voir si quelqu'un tente d'envoyer des messages en se faisant passer pour eux.

Plus d'informations sur la syntaxe DMARC ici.

Une autre vérification : l'alignement

Mais DMARC fait également quelque chose de très intéressant qui va corriger les défauts de SPF et de DKIM. Il va également vérifier ce qu'on appelle l'alignement.

Souvenez-vous, j'avais dit plus tôt que SPF ne vérifiait que le MAIL FROM et pas le From du message, et que DKIM ne se basait que sur le domaine indiqué dans la clé d.
DMARC va alors ajouter un critère pour que SPF et/ou DKIM soient valides : le domaine du From doit être le même que celui du MAIL FROM (pour SPF) ou de la clé d (pour DKIM).

Ainsi, les nouveaux critères sont :

• SPF est valide si le domaine du MAIL FROM autorise l'IP de l'expéditeur à envoyer des messages en son nom, ET si le domaine du MAIL FROM est le même que celui du From dans le message
• DKIM est valide si la signature cryptographique est valide, ET si le domaine de la clé d est le même que celui du From dans le message

Si SPF ou DKIM est valide (ou mieux, les deux) et que le serveur utilise DMARC, le mail est authentifié avec succès et il est donné à l'utilisateur. Sinon... cela dépend de la valeur p dans l'enregistrement DMARC, comme dit plus haut.

L'alignement est donc un mécanisme indispensable car il referme les brèches de SPF et DKIM. Il est désormais (enfin) impossible pour moi d'envoyer le fameux mail au nom de Poutine dont je parle depuis le début, car si j'essaye de tricher sur les vérifications SPF et DKIM, DMARC verra que les domaines ne sont pas les mêmes et comprendra qu'il y a quelque chose de suspicieux.

Le protocole ARC : au secours des messages légitimes refusés par DMARC

Bien que la combinaison de SPF, DKIM et DMARC permet d'atteindre un très bon niveau de sécurité, des problèmes peuvent se produire avec certains mails, et notamment les mails de listes de diffusion. En effet, la façon dont les listes de diffusion gèrent les mails peut invalider SPF et/ou DMARC :

• Comme dit plus haut avec DKIM, un serveur peut éditer le message pour ajouter un tag dans le sujet, un lien de désinscription dans le message, le pseudonyme du correspondant dans le champ From...
• Également, quelque chose qui est courant avec les listes de diffusion est d'avoir un réflecteur, c'est-à-dire un serveur qui fait office d'intermédiaire qui gère la liste de diffusion. Comme il renvoie le mail en utilisant son IP, cela peut invalider SPF, car l'IP du réflecteur ne sera pas forcément dans l'enregistrement SPF.

Pour contourner ce problème, un protocole (oui, encore un...) est là : il s'agit de ARC (Authenticated Received Chain). C'est un protocole qui est relativement nouveau (la spécification a été publiée en 2019) et son adoption par les principaux acteurs de la messagerie se fait progressivement.

Le concept est d'autoriser des serveurs intermédiaires à modifier le message, et d'inscrire ces modifications dans les entêtes avec une signature cryptographique. Ainsi, bien que DKIM ne sera pas valide, le serveur du destinataire pourra consulter l'historique des modifications, et voir qu'« à la base », le message était légitime. Cependant, cela inclut de faire confiance à des serveurs intermédiaires précis... c'est donc un affaiblissement de la sécurité, et c'est donc à réserver à ce genre de cas spécifiques.

Comme ce protocole est nouveau, est un peu complexe (c'est comme DKIM, mais en plus compliqué), et qu'il est peu probable que vous ayez affaire à lui à moins que vous êtes l'administrateur d'un serveur gérant des listes de diffusion, je vais me contenter d'un lien vers cet article (en anglais) qui l'explique bien.

Récapitulatif (avec un schéma)

L'article touche à sa fin, voici donc un schéma qui récapitule tout cela :

Très utile si comme moi vous aurez oublié tout ça d'ici quelques mois et que vous avez besoin de vous rafraîchir la mémoire :)

Cependant, il faut se rappeler de quelque chose : c'est de la responsabilité du serveur du destinataire de faire toutes ces vérifications. Si sa configuration est très mauvaise, il peut ignorer toutes ces vérifications, ou une partie d'entre elles... cela peut être le cas dans certaines entreprises où l'on désactive certains critères car certains correspondants n'ont pas configuré correctement leur SPF ou leur DKIM par exemple...

Enfin, je tiens à préciser quelque chose : bien que je puisse donner une mauvaise image de SMTP dans cet article, je considère que les mails sont une technologie précieuse en informatique, car ça marche partout, c'est standardisé, c'est relativement simple à mettre en place et à utiliser... et surtout, c'est décentralisé, ce qui est un énorme avantage dans un monde où les acteurs centralisés (Messenger, Discord, Whatsapp...) sont désormais omniprésents, et où toutes les alternatives décentralisées (Mastodon, Matrix...) n'arrivent pas à décoller.
C'est sûr que, si tout se passe chez un seul prestataire, il n'y aura plus de problèmes d'authentification, les problèmes seront tout autres...

Cependant, comme c'est un protocole ancien et qu'il est très difficilement modifiable (car désormais au centre du monde numérique d'aujourd'hui), on est obligé de recourir à des mécanismes de ce type pour compenser ses faiblesses. Au terme de cet article, on peut donc le constater : l'authentification des mails, c'est un défi complexe.