DKIM – SPF – DMARC – Sécurisez vos emails d'entreprise !

Aujourd’hui, nous allons nous concentrer sur un sujet assez méconnu et pour le moins complexe : l’envoi des emails. Vous allez me dire que tout le monde arrive à envoyer des emails, et c’est bien vrai ! Mais pouvez-vous tous assurer que vos mails ne filent pas directement dans les SPAM de votre destinataire ? C’est moins sûr… Rentrons dans le vif du sujet, et voyons comment fonctionne l’envoi de mails et surtout, comment sécuriser ses mails.

La problématique de l’envoi des emails dans le SI

Dans un système d’information classique, la majorité des applications sont susceptibles d’envoyer des emails. Les sources d’envoi d’email s’avèrent être de plus en plus fréquentes et multiples. On peut citer par exemple :

• Le site web qui vous notifie d’une mise à jour
• Une demande de contact
• Votre CRM pour un rappel
• Le système de monitoring
• Votre newsletter
• Votre ERP
• Vos applications mobile
• Vos relances clients…

Tous ces outils sont amenés, à un moment ou à un autre, à envoyer un email avec le nom de votre société. Une question se pose alors : comment assurer à votre destinataire que cet email provient bien de chez vous et qu’il est légitime ? Que ce ne soit pas du phishing ?

Back to basic : l’envoi d’un email – SMTP

Le protocole d’envoi d’un email (SMTP) est excessivement simple. Si vous souhaitez envoyer un email à jean[a]acme.com, les opérations sont les suivantes :

• Votre serveur va chercher dans le DNS (enregistrement MX), quel est le serveur responsable des emails de ce domaine.
• Il s’y connecte et délivre le mail.
• Notons que le champs « from » de l’objet email permet de savoir d’où provient l’email.

Avec ce fonctionnement, vous l’avez peut-être compris… TOUT LE MONDE PEUT DONC ENVOYER DES MAILS EN VOTRE NOM ! Heureusement, pour éviter ce problème, de nombreuses sécurités existent.

L’enregistrement SPF – Quels sont les serveurs autorisés à envoyer un mail en votre nom ?

Je vais simplifier volontairement le propos de la partie à venir pour qu’il soit accessible au plus grand nombre. L’enregistrement DNS SPF permet de dire au récepteur de l’email (la boite de réception du destinataire) quels sont les serveurs qui sont autorisés à envoyer un email au nom de la société.

Prenons l’exemple suivant d’AXOPEN.COM : 

v=spf1 include:_spf.google.com ~all  include:servers.mcsv.net ?all

Ici, on explique que les serveurs de Google ont le droit d’envoyer des emails en notre nom, ainsi que les serveurs de MSCV.net (Mailchimp). De fait, lors de la réception de l’email par le destinataire, il va pouvoir effectuer une vérification du serveur émetteur et prendre la décision de rejeter, ou non, l’email.

Arrêtons nous un instant sur la notion suivante : rejeter l’email. C’est toujours le récepteur qui décide ce qu’il va faire de l’email. Cette décision dépend donc de sa politique de sécurité. Il est effectivement possible que votre email ne valide pas l’enregistrement SPF et que pourtant votre email arrive à bon port.

Nous verrons plus loin comment renforcer la sécurité.

Le DKIM – Si si, c’est bien moi qui l’envoie !

Avec l’enregistrement SPF, on s’est assuré que l’email provient bien de vos serveurs. Mais attention, une faille majeur existe ! Comment s’assurer que l’email que vous avez envoyé n’a pas été altéré (modifié) par une tiers personne ? Et comment s’assurer que la personne n’ait pas réussi à envoyer un email en se faisant passer pour un de de vos serveurs ?

Encore une fois une solution existe : le DKIM.

Comment fonctionne le DKIM ?

Le DKIM n’est ni plus ni moins qu’une solution de signature électronique des emails.

Le principe repose sur le grand classique de la clé privée et clé publique. Votre serveur d’email possède une clé privée avec laquelle, il crée une signature de l’email (imaginez ici un simple hash). Cette signature est ajoutée en part de l’email qui est envoyé. Le récepteur prend la clé publique dans le DNS.

v=DKIM1; k=rsa; t=s;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjYk9XHhZwCCTAwxIo/5A2SK19F8k/
qddqsdqs/Gyjl03Y6g9C3NfCC/nfcwBV
AfHXz9+uaIr5P/2ca21kVlZYMSEX+EBMirS3v+Dbd0/5f5ovXtBXx/hsbODTtnQKXtzmDepgeQu
Hu6jg9/Kq6lBY0740HSWssBQ+hbI1HYG2YjJzUsL9xiwR9Sfywk2NtkVxsaaVSHarUasm5IkWqB
W3gZOV244QigeAU4ks/qyoq+paqsdsbKAn90ReM/6Ne52UsRIUMiHiKKI770whh4T6hzVVtnP5Sa
9yQbnZGxUIG7QIDAQABqsd

Ici, l’exemple d’AXOPEN.COM valide que cet email est bien signé avec le clé privée. Ainsi, on est certain que l’email n’a pas été altéré.

Ce qui est super, c’est qu’il est possible de créer plusieurs clés DKIM pour séparer par exemple l’envoi d’email de vos boites mails avec celui de la mailing list par exemple. Il faut pour cela utiliser les selector DKIM.

DMARC : Votre politique de sécurité

Dernier enregistrement et non des moindres, le DMARC. Le DMARC permet de spécifier quelle politique appliquer pour tous les emails de votre domaine. Il vous est par exemple possible de dire : tous les emails qui ne sont pas signés, et qui ne viennent pas de nos serveurs, doivent être considérés comme SPAM ou tout simplement doivent être rejetés !

De plus, vous pouvez dire au récepteur de vous informer à une adresse spéciale si il détecte que des emails ne respectent pas la politique que vous avez défini. Cela vous permet notamment de comprendre ce qu’il se passe.

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:xxx@axopen.com!10m; ruf=mailto:xxx@axopen.com; rf=afrf; pct=100; ri=86400

Prenons une nouvelle fois l’exemple AXOPEN. Si jamais le DKIM ou le SPF failed, alors on doit considérer l’email en tant que SPAM. Il est possible de choisir soit de ne rien faire, soit de rejeter simplement l’email.

_Exemple d’un email valide mais qui ne valide par l’enregistrement DMARC : 

En conclusion, il est temps de s’y mettre !

Ces enregistrements semblent complexes à mettre en place au premier abord, mais s’avère plus simple qu’il n’y parait 🙂 Seule la première étape est assez touchy, car elle consiste à répertorier qui envoie des emails au sein du SILe SI désigne le système d'informations d'une organisation..

Il faut savoir que ce n’est pas parce que seulement la moitié de vos emails seront signés que les autres partiront en SPAM, nous pouvons donc très naturellement mettre la signature de manière progressive et seulement en dernier ressort, mettre en place la politique DMARC (la plus stricte).

Pour information, nous avons mis un an pour tout mettre en place chez AXOPEN et s’assurer de ne pas faire de bêtise ! Si si je vous jure… ça fait pas sérieux en tant que société de services informatiques quand vos emails partent en SPAM 🙂