Erreurs courantes dans la mise en œuvre de l'authentification des courriels

DKIM, DMARC et SPF sont des protocoles d'authentification importants qui protègent les domaines contre les tentatives d'hameçonnage et de spamming. Cependant, une mauvaise configuration de ces protocoles peut entraîner des problèmes majeurs, comme le fait que des courriels légitimes ne soient pas délivrés par votre domaine.  

Pour introduire le sujet, commençons par quelques définitions. Trois méthodes d'authentification sont actuellement utilisées :

• Sender Policy Framework (SPF) est une méthode d'authentification des courriels qui utilise des enregistrements DNS pour indiquer quels serveurs de messagerie sont autorisés à envoyer des courriels au nom d'un domaine particulier.
• DomainKeys Identified Mail (DKIM) est une technique d'authentification du courrier électronique qui repose sur une signature numérique, dont la clé publique peut être consultée par le biais d'une recherche DNS, afin de garantir qu'un courrier électronique a été envoyé par un expéditeur autorisé et que le contenu du courrier électronique n'a pas été modifié au cours du processus.
• La méthode DMARC (Domain-based Message Authentication, Reporting & Conformance) permet aux propriétaires de domaines de publier une politique dans un enregistrement DNS qui spécifie les mécanismes (par exemple, SPF, DKIM) utilisés pour authentifier les messages électroniques envoyés à partir de leur domaine, et ce qu'il convient de faire avec les messages qui échouent à l'authentification.

À une époque où le phishing est la porte d'entrée d'un grand pourcentage de cyberattaques, l'utilisation d'une ou de plusieurs de ces méthodes est devenue une norme industrielle. Cependant, de nombreuses erreurs sont encore commises.

Voici les problèmes les plus courants liés à la mise en œuvre de l'authentification par courrier électronique, par ordre décroissant d'occurrence.

Ne pas mettre en œuvre DKIM, DMARC ou SPF sur des domaines qui ne sont pas utilisés pour le courrier électronique

Un nombre étonnamment élevé d'entreprises ne mettent pas en œuvre l'authentification du courrier électronique sur des domaines qui ne sont pas utilisés pour le courrier électronique, comme un domaine contenant une marque de produit qui n'est utilisée que pour promouvoir le produit de l'entreprise. Elles se disent probablement que si "nous ne l'utilisons pas pour le courrier électronique, nous n'avons pas besoin de mettre en œuvre l'authentification par courrier électronique".  

Malheureusement, ce n'est pas le cas.  Ce sont ces domaines que les pirates recherchent pour les utiliser dans des attaques de phishing. Ils savent que si l'authentification du courrier électronique n'est pas mise en œuvre, n'importe qui peut usurper le domaine pour envoyer des courriers électroniques. Et si le domaine est utilisé à des fins de marketing, les destinataires peuvent le connaître et être moins enclins à se méfier d'une attaque par hameçonnage.

La politique DMARC est réglée sur "none", ce qui rend DMARC inutile.

DMARC indique au serveur destinataire ce qu'il doit faire des messages qui échouent à l'authentification. Voici à quoi ressemble un enregistrement DMARC TXT :

v=DMARC1 ; p=quarantine ; pct=50 ; rua=mailto:[email protected] ; ruf=mailto:[email protected]

L'attribut "p" spécifie la politique DMARC, et ce qu'il faut faire avec un message qui échoue à la validation DKIM ou SPF. Les valeurs possibles sont "none", "quarantine" ou "reject".

Dans les enregistrements que nous analysons, nous voyons souvent "p=none", ce qui rend DMARC inutile puisque chaque message provenant de la propriété du domaine ne peut pas être vérifié et est quand même délivré au destinataire. Cela revient à ne pas avoir de politique DMARC du tout. Vous devez au moins mettre en place une politique de "quarantaine". Le serveur de réception placera les messages qui échouent à l'authentification dans le dossier spam. Lorsque vous êtes sûr que tout fonctionne comme prévu, vous pouvez passer à la politique de "rejet". Dans ce cas, les messages non authentifiés seront rejetés par le serveur de réception.

Plusieurs enregistrements SPF pour le même domaine

De nombreuses entreprises autorisent plusieurs serveurs de messagerie à envoyer des courriels, comme un serveur de messagerie d'entreprise (Google business email ou Microsoft 365), une plateforme de marketing pour l'envoi de lettres d'information ou de courriels transactionnels, comme Mailchimp, Sendinblue ou Sendgrid, et une plateforme d'automatisation du marketing, comme Marketo, Hubspot ou Omnisend.

Les entreprises ajoutent souvent un enregistrement SPF pour chaque serveur de messagerie autorisé. Cependant, la norme SPF exige de ne conserver qu'un seul enregistrement TXT, qui peut contenir plusieurs adresses IP ou plages d'adresses pour plusieurs serveurs autorisés. Une partie de la confusion vient du fait que pour DKIM, c'est l'inverse : pour chaque expéditeur autorisé, un enregistrement différent est nécessaire.

Erreurs de syntaxe dans les enregistrements DKIM et SPF

La syntaxe correcte du nom de l'enregistrement DKIM TXT est essentielle au bon fonctionnement du processus DKIM. Le nom d'un enregistrement DKIM dans lequel la clé publique de la signature est stockée dans le DNS est structuré comme suit :

Selectorkey._domainkey.exampledomain, où les valeurs selectorkey et exampledomain sont variables.

Nous constatons souvent que le point de fin est oublié, que le "._" entre la valeur selectorkey et le mot domainkey est interverti, ou que l'un des deux symboles n'est pas présent.

La syntaxe d'un enregistrement SPF n'est pas simple non plus. En particulier, l'utilisation des symboles "+", "~" et "-" est une source d'erreurs.  Voici 4 exemples de valeurs d'enregistrements SPF qui se ressemblent beaucoup mais qui ont des résultats complètement différents.

V=SPF1 A ~ALL      les adresses IP spécifiées dans l'enregistrement A du domaine peuvent envoyer du courrier électronique

V=SPF1 +ALL (ou V=SPF1 ?ALL)       Toutes les adresses IP sur l'internet peuvent envoyer du courrier (bien que 'valide', ce n'est évidemment pas recommandé)

V=SPF1 ~ALL       Le domaine n'envoie aucun courrier (sauf si un domaine ou une adresse IP est ajouté à l'enregistrement SPF à l'aide du paramètre include :), laissant à la politique DMARC le soin de décider ce qu'il convient de faire du courrier.

V=SPF1 -ALL      Le domaine n'envoie aucun courrier (sauf si un domaine ou une adresse IP est ajouté(e) à l'enregistrement SPF à l'aide du paramètre include :). Même s'il n'y a pas de politique DMARC, le courrier doit être rejeté.

Trop de recherches dans l'enregistrement SPF

Comme les entreprises utilisent non seulement des serveurs de messagerie pour que les employés envoient et reçoivent des courriels, mais aussi de multiples solutions SaaS pour soutenir les activités de vente et de marketing, le nombre de plateformes qui doivent envoyer les courriels d'une entreprise a augmenté au fil des ans. Cependant, il ne peut y avoir qu'un seul enregistrement SPF par domaine. Cet enregistrement doit contenir tous les serveurs de messagerie autorisés à envoyer du courrier électronique. Le RFC spécifiant le mécanisme SPF (RFC7208) détermine que le nombre de consultations DNS dans un enregistrement SPF ne peut être supérieur à 10 afin de se défendre contre les attaques par déni de service. Si le nombre de consultations est supérieur à 10, le serveur de messagerie destinataire considérera que le domaine d'envoi est malveillant et le courrier électronique provenant de ce domaine sera rejeté.

Testez, testez, testez... et testez encore

La seule façon de s'assurer que l'authentification du courrier électronique fonctionne est de tester votre configuration après chaque modification. Il existe plusieurs outils disponibles sur l'internet, dont certains sont gratuits, qui peuvent être utilisés pour vérifier la validité des enregistrements SPF, DKIM et DMARC. La plupart des plateformes externes de gestion de la surface d'attaque (ASM) surveillent également l'authentification du courrier électronique.