SPF, DKIM et DMARC : trois serrures sur une porte

Pourquoi c’est nécessaire

Le courriel a été conçu à une époque où les participants se connaissaient. Il ne comporte donc aucun contrôle sur l’identité de l’expéditeur. La ligne d’expéditeur est simplement un champ du message, et ce champ, vous le remplissez vous-même — comme vous pouvez écrire ce que vous voulez sur une enveloppe.

Il en découle la fraude que nous voyons le plus souvent en pratique, et ce n’est pas le courriel d’hameçonnage isolé plein de fautes. C’est la note soignée d’un fournisseur annonçant un changement de coordonnées bancaires. Ou le courriel du dirigeant à la comptabilité, bref et pressé, à propos d’un paiement à passer aujourd’hui.

Les deux fonctionnent parce que le destinataire n’a aucune raison de douter : une adresse connue figure en tête. Et les deux peuvent être empêchés côté serveur destinataire, à condition que vous ayez consigné qui a le droit d’envoyer au nom de votre domaine.

Il y a une autre raison de le faire, sans rapport avec la sécurité : arriver. Les grands fournisseurs de messagerie ont commencé en 2024 à exiger ces enregistrements de ceux qui envoient en volume. Un domaine sans DMARC finit plus souvent dans les indésirables, et cela se remarque sur vos factures et votre infolettre bien avant de se remarquer lors d’un incident.

SPF : qui peut envoyer en votre nom

SPF est une liste. Dans votre DNS, vous posez une ligne indiquant quels serveurs peuvent envoyer du courrier avec votre domaine en expéditeur. Le serveur destinataire regarde d’où vient le message, lit votre liste et constate si cela concorde.

Cela paraît plus simple que ce ne l’est, car cette liste n’est presque jamais votre seul serveur de messagerie. Il y a un logiciel comptable qui envoie des factures, un service d’infolettre, un système de recrutement, un système de tickets qui envoie des confirmations, et parfois un vieux serveur que personne ne reconnaît. Toute partie qui écrit en votre nom doit y figurer.

Deux choses y échouent d’office :

• La limite de dix requêtes. Un enregistrement SPF peut coûter au plus dix requêtes DNS. Chaque service ajouté compte, et une organisation avec une poignée de fournisseurs la dépasse vite. Une fois dépassée, la réponse n’est pas « invalide » mais « échec », ce qui peut toucher votre propre courrier.
• La fin de l’enregistrement. S’il se termine par ~all, votre domaine dit « le reste est suspect, mais livrez quand même ». S’il se termine par -all, il dit « le reste n’est pas de nous ». C’est ce dernier que l’on veut, et c’est aussi ce qui crée le risque quand votre liste est incomplète.

Là où SPF casse de toute façon, c’est le transfert. Si quelqu’un fait suivre votre courriel à une autre adresse, c’est son serveur qui l’envoie, et ce serveur n’est pas dans votre liste. Ce n’est pas un défaut que l’on corrige ; c’est la raison pour laquelle SPF seul ne suffit pas.

DKIM : une signature qui survit au transfert

DKIM résout exactement cela. Au lieu de regarder d’où vient un message, on y appose une signature. Votre serveur signe les messages sortants avec une clé privée ; la clé publique correspondante se trouve dans votre DNS. Le destinataire la récupère et vérifie que la signature correspond au contenu.

L’avantage est que cette signature est attachée au message et non au serveur. Le courriel est transféré, la signature voyage avec lui et reste valable. Le contenu est modifié en route, elle ne l’est plus — et c’est précisément ce que vous voulez savoir.

Ce qu’il faut surveiller ici :

• Chaque partie expéditrice signe séparément. Votre service d’infolettre a sa propre clé sous son propre sélecteur. Un enregistrement DKIM unique pour tout n’existe pas.
• Longueur de clé. Certaines installations anciennes sont encore en 1024 bits. Les nouvelles clés passent à 2048.
• Le remplacement fait partie du travail. Une clé en place depuis dix ans est une clé que plus personne ne gère. C’est le même raisonnement que dans gestion des clés.

SPF et DKIM ensemble couvrent presque tous les cas. Ce que ni l’un ni l’autre ne fait, c’est dire ce qui doit se passer quand cela échoue. Ils rendent un verdict et laissent le destinataire deviner.

DMARC : l’enregistrement dont il sort quelque chose

DMARC est la couche supérieure, et c’est le seul des trois dont un serveur destinataire tire une instruction. Il dit deux choses : ce que vous voulez qu’il advienne du courrier qui échoue à SPF ou DKIM, et où doivent aller les rapports.

Il y a trois positions, à parcourir dans cet ordre :

• Observer. Ne faites rien, mais envoyez-moi chaque jour un état de qui a envoyé au nom de mon domaine. C’est là qu’on commence et cela ne peut pas nuire.
• Mise en quarantaine. Ce qui échoue part dans les indésirables. Le courrier arrive encore, mais plus dans la boîte de réception.
• Rejet. Ce qui échoue est refusé et n’arrive nulle part. C’est l’objectif, et c’est aussi la position où un fournisseur oublié se signale par la disparition de son courrier.

Il y a ici une subtilité souvent manquée. DMARC ne regarde pas seulement si SPF ou DKIM passe, mais aussi si le domaine qui passe est le même que celui que voit le lecteur. Un service d’infolettre qui envoie et signe avec son propre domaine passe SPF et DKIM et échoue tout de même à DMARC. C’est pourquoi ces services doivent être réglés pour envoyer depuis votre domaine — presque tous les fournisseurs disposent d’un réglage pour cela.

Les rapports quotidiens que vous recevez sont en XML et ne se lisent pas à la main. Des services les transforment en un état lisible, et cela vaut l’investissement : sans ces rapports, vous franchissez la dernière étape en aveugle.

L’ordre dans lequel on l’active

La plupart des textes sur le sujet parlent des enregistrements. Le vrai travail est dans les semaines intermédiaires, et c’est aussi là que cela dérape quand quelqu’un veut boucler l’affaire en une après-midi.

Voici comment nous procédons :

• Semaine un : inventaire et observation. Poser SPF et DKIM pour les parties connues, DMARC en observation. Rien ne change encore à la livraison.
• Semaines deux à quatre : lire les rapports. C’est là que remonte la liste de ce qui envoie encore en votre nom. C’est toujours plus que ce que l’on croyait : une ancienne boutique en ligne, le logiciel de pointage, un service marketing d’une campagne d’il y a deux ans.
• Semaine quatre : nettoyer et raccorder. Ce que vous voulez garder est proprement raccordé à votre domaine. Ce que personne ne reconnaît est coupé — en général la moitié.
• Semaine cinq : quarantaine. Passez à la position intermédiaire et continuez à lire les rapports. Ce que vous avez manqué se signale maintenant, par un collègue qui dit que ses courriels de confirmation sont dans les indésirables.
• Alors seulement : rejet. Si rien de nouveau n’apparaît dans les rapports pendant deux semaines, c’est un non-événement. Plus tôt, cela ne l’est pas.

Comptez six à huit semaines du début à la fin, dont l’essentiel est de l’attente et de la lecture. Ce n’est pas lent ; c’est ce qui sépare un domaine fermé d’un domaine dont les factures n’arrivent plus.

Et posez ensuite un rappel. Tout nouveau service qui se met à écrire en votre nom — un nouveau logiciel RH, un autre prestataire d’infolettre — doit y être ajouté, et le jour où quelqu’un l’oublie, son courrier n’arrive pas.