316.6 milliards d’emails sont échangés chaque jour dans le monde (chiffres 2021, source Statista) dont une grosse majorité sont des spams. Bien sûr, en tant qu’entreprise ou administration publique, vous avez configuré un antispam qui protège vos utilisateurs de ce flot incessant. Jusque-là, tout va bien.
Et puis un jour vous vous apercevez que vos destinataires ne reçoivent plus vos messages ! Les emails partent mais n’arrivent pas. Votre service informatique est pourtant formel : tout est bien configuré, les voyants sont au vert : le problème n’est pas chez vous. Ce sont les autres qui n’acceptent plus vos emails et ça, c’est un problème d’authentification, pourtant facilement évitable.
Nous vous proposons un petit tour d’horizon du sujet de la sécurisation de vos emails, c’est parti !
Authentification de vos emails : pourquoi faire ?
L’authentification de vos emails est le processus par lequel le serveur mail de vos destinataires reconnait l’authenticité de vos messages. Pensez l’authentification des e-mails comme une carte d’identité numérique : c’est ce qui permet à votre serveur mail et aux systèmes de filtrage du spam de reconnaître que vos e-mails sont bien les vôtres.
L’authentification des e-mails est une nécessité pour les organisations car c’est ce qui assure leur délivrabilité. Sans authentification, vous risquez d’être automatiquement filtrés et vos emails ne parviennent plus à leurs destinataires.
Il existe trois principales normes d’authentification qui permettent de valider qu’un message électronique provient bien de la personne qu’il prétend être : SPF, DKIM et DMARC.
SPF : Sender Policy Framework
Le SPF permet de définir quelles adresses IP sont autorisées à envoyer des emails pour un domaine particulier et donc d’empêcher l’envoi d’emails avec votre domaine en adresse d’expédition par des serveurs autres que les vôtres. Les IP autorisées à envoyer des e-mails pour un nom de domaine sont répertoriées dans un enregistrement DNS TXT.
Cependant SPF n’est pas toujours suffisant.
Un mail validé par SPF peut être forgé
Il y a 2 adresses emails d’expédition dans un mail :
- L’adresse de l’enveloppe, utilisée par les serveurs pour le routage des mails,
- L’adresse présente dans l’email lui-même (dans les en-têtes), qui est celle affichée dans les clients de messagerie des utilisateurs.
Or le SPF se base uniquement sur l’adresse email expéditeur de l’enveloppe. Il est donc possible dans un email de modifier ou falsifier l’adresse email de l’expéditeur visible par un utilisateur alors que l’email est valide au niveau SPF !
Par exemple, il est possible pour un spammer, d’envoyer depuis un serveur un message dont le « from » (l’adresse d’expédition) de l’enveloppe est spam@spammer.fr mais dont l’adresse présente dans l’en-tête du mail est directeur@monentreprise.com.
Si le mail est émis depuis un serveur listé dans le SPF de spammer.fr vers le serveur de monentreprise.com, le SPF sera valide et le destinataire verra un mail « légitime » comme émis par directeur@monentreprise.com.
Problèmes avec les redirections de mails
Le SPF peut aussi poser des problèmes avec les redirections de mails si le support du SRS (Sender Rewriting Scheme) n’est pas ajouté.
Pour information, SRS est implémenté dans BlueMind à partir de BlueMind 4.7.
Le SPF seul se révèle vite insuffisant puisqu’il n’empêche pas l’usurpation de votre nom de domaine dans les en-têtes du message, soit l’adresse email que verra l’utilisateur. Les limites du SPF font partie des raisons pour lesquelles le DKIM a été créé.
DKIM : DomainKeys Identified Mail
Le DKIM permet d’ajouter une signature numérique aux messages émis afin que le destinataire du message puisse s’assurer que l’email n’a pas été altéré.
C’est le serveur mail d’émission ou système d’envoi des mails (qui peut être un antispam si le flux des emails en sortie passe par un antispam) qui signe les messages avec une clé privée associée au domaine d’émission. La clé publique est elle publiée dans le serveur DNS pour être accessible par tous.
Le serveur mail de destination (ou le système de réception) reçoit l’email signé et il doit déterminer si la signature DKIM est valide. Pour ce faire il va récupérer la clé publique du domaine d’expédition et vérifier qu’elle valide bien le message.
Cela permet de s’assurer que le message a bien été émis par les serveurs officiels du domaine de l’expéditeur, et que le message est bien le message original sans modification.
Le DKIM permet de prouver que :
- Les en-têtes de l’email n’ont pas été modifiées depuis l’envoi par l’expéditeur initial.
- L’expéditeur de l’e-mail possède le domaine DKIM, ou est autorisé par le propriétaire de ce domaine.
En général, les signatures DKIM ne sont pas visibles pour les utilisateurs finaux, la validation des mails entrants se fait au niveau du serveur ou est prise en charge par l’antispam d’entrée.
Avec BlueMind, si la signature DKIM n’est pas prise en compte par votre antispam de sortie (ou si vous n’avez pas d’antispam en sortie) vous pouvez facilement intégrer une solution comme openDKIM au niveau du serveur principal ou au niveau d’un edge (relai).
DMARC : Domain Based Message Authentication, Reporting & Conformance
Le DMARC est destiné à empêcher les hameçonneurs, les spammeurs et autres acteurs illégitimes de falsifier un domaine d’envoi et de se faire passer pour quelqu’un d’autre (spoofing).
Le DMARC unifie les mécanismes d’authentification SPF et DKIM dans un cadre commun et permet aux propriétaires de domaines de déclarer comment ils souhaitent que l’email soit traité s’il échoue aux normes SPF ou DKIM. Cela se fait par le biais de ce que l’on appelle une « policy », qui est définie dans l’enregistrement DNS DMARC. La policy peut être définie par l’une des trois options suivantes :
- None : Traitez tous les email envoyés depuis votre domaine comme ils le seraient sans aucune validation DMARC.
- Quarantine : Le serveur du destinataire peut accepter le courrier mais doit le placer ailleurs que dans la boîte de réception du destinataire (généralement, dans le dossier spam).
- Reject : rejeter complètement le message.
Notez que même si un email passe le test DMARC, cela ne garantit pas qu’il aboutira dans la boîte de réception. Avant d’atteindre sa destination finale, un courriel sera sans doute soumis à d’autres contrôles, tels que la recherche de contenu indésirable ou la vérification de la réputation de l’expéditeur.
Une mise en œuvre réussie de DMARC doit passer lentement de différents pourcentages de quarantaine à un rejet total. Une pratique réussie exige également que l’expéditeur surveille régulièrement les rapports DMARC. Ces rapports signalent toute tentative d’hameçonnage de votre domaine, ou si votre propre courrier est rejeté pour cause d’échec de DKIM ou SPF.
Faut-il impérativement implémenter les trois normes ?
Impérativement, non. Mais c’est très recommandé.
Alors que SPF et DKIM sont de plus en plus adoptés, DMARC tarde encore à s’imposer. Cela dit, les administrateurs de messagerie prudents vont configurer les trois pour les domaines qu’ils gèrent, car de plus en plus de FAI et de fournisseurs de messagerie commencent à appliquer strictement les trois.
La mise en place de ces trois normes d’authentification permet d’assurer l’émission de vos emails et d’en améliorer la délivrabilité en montrant que vos domaines de messagerie sont vraiment ceux qu’ils prétendent être. Cela montre également que vous suivez les meilleures pratiques et que vous faites votre part pour prévenir le spam, le phishing et d’autres problèmes de sécurité des e-mails.
Conclusion
Un mail authentifié est un mail auquel vous pouvez faire confiance, car l’émetteur et le contenu ont été validés comme conformes, via les vérifications SPF et DKIM.
Cette authentification n’a aucune incidence sur l’utilisateur ou l’usage de la messagerie, il n’y a donc pas de raisons de ne pas l’intégrer !
L’activation de l’authentification des emails n’est pas seulement une bonne pratique pour que vos messages soient délivrés, c’est aussi un outil essentiel pour protéger la réputation de votre marque en limitant les chances qu’un expéditeur non autorisé puisse utiliser votre domaine sans votre consentement ou à votre insu.
