DMARC

Renaud Garelli

Le DMARC est un mécanisme étroitement lié au SPF et au DKIM, permettant de garantir l’authenticité d’une adresse email émettrice dans le monde de l’Emailing.

 

Contrairement au SPF et au DKIM qui sont des protocoles techniques pouvant etre activés seul, le DMARC nécessite quant à lui d’etre systématiquement lié au SPF ou au DKIM pour fonctionner. En effet le DMARC constitue une extension de ces protocoles techniques, permettant d’optimiser leur mise en place et la protection qu’ils apportent en termes d’authentification du domaine émetteur d’un email.
Le DMARC permet donc au propriétaire d’un domaine internet de protéger ce dernier contre les risques d’usurpation par des acteurs malveillants, protégeant ainsi à la fois les personnes réceptionnaires contre du phihsing, et le domaine émetteur contre une dégradation de son image ou de sa réputation.

 

Dans son fonctionnement, le DMARC réside simplement dans la mise en place de l’ajout d’une entrée dans le DNS du domaine émetteur, laquelle doit permettre de répondre à une question clé : “que doit faire le domaine de réception lorsqu’un email reçu provient d’un email dont le SPF ou le DKIM est en échec?”
Cela permet donc au propriétaire du domaine source de donner des directives précises sur la manière dont il souhaite que les emails reçus en provenance de son domaine soient traités dans les cas où l’authentification de l’adresse émettrice n’a pas pu etre vérifiée (SPF et/ou DKIM en échec).
Il est ainsi possible de définir par exemple que l’on demande de refuser systématiquement tout emai qui serait reçu sans que l’authentification ne soit réussie, ou même encore que l’on demande d’accepter tous les emails mais d’envoyer en parallèle un rapport en cas de réception d’un email avec une authentification en échec.

 

Voici un exemple d’enregistrement DMARC, associé ici au domaine paypal.com :

 

"v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com"

 

On peut voir ici que la directive principale est définie sur “reject”, ce qui signifie que le domaine indique clairement qu’il souhaite que les emails reçu de type XXXX@paypal.com soient rejetés par les domaines en réception si ces emails ne sont pas correctement authentifiés par du SPF ou du DKIM.
Cette configuration stricte est celle qui permet le plus de sécurité et qui est celle qui est conseillée afin de garantir la meilleure protection contre le vol d’identité et le phishing email.

 

Le DMARC est relativement simple à mettre en place sur la partie technique, mais il faut garder en tête qu’une mauvaise configuration de ce dernier peut avoir des conséquences négatives très fortes.
Voici les conséquences possibles auxquelles peut faire face un domaine si son DMARC est mal configuré, avec une configuration trop (ou pas assez) stricte dans son utilisation :

 

– Possibilité pour un pirate de pouvoir usurper de manière transparente l’identité d’une adresse email du domaine

– Possibilité pour le domaine source de se voir refuser des emails légitimes (envoyés par des serveurs internes valides) si ces derniers viennent à avoir un problème dans leur configuration du SPF ou du DKIM

– Possibilité de perte de confiance envers le domaine (c’est à dire vis à vis de la marque) en cas d’incident de sécurité ou de phishing, ou sentiment de service défaillant de la part des utilisateurs si les emails attendus ne sont pas reçus (car rejetés par une mauvaise configuration DMARC)

 

Il convient donc d’etre spécialement prudent dans la phase préalable d’étude, dans le but d’identifier de manière précise l’ensemble des flux email associés un domaine émetteur donné, avant de décider d’activer le DMARC sur le domaine. Il est aussi recommandé de mettre en place la configuration DMARC dans un mode de détection sans blocage (mode “none”) au départ pendant quelques jours afin de vérifier qu’il n’y a pas de flux emails émis qui auraient été oubliés et qui seraient alors bloqués par erreur, grâce aux rapports DMARC journaliers envoyés.

 

Il faut également comprendre que malgré son bénéfice réel et la protection supplémentaire qu’il rajoute au-dessus de SPF et DKIM, le DMARC ne constitue pas pour autant un protection infaillible contre le vol d’identité numérique d’un domaine ou d’une adresse email. En effet, le DMARC indique la marche à suivre “conseillée” par le domaine source en cas de réception d’un email non authentifié, mais le domaine de réception est libre de choisir s’il souhaite ou non suivre cette directive.
De même, beaucoup de petits domaines internet non gérés par une solution d’email globale clé en main (type gsuite, office365, etc) peuvent tout simplement ne pas avoir implémenté la vérification SPF, DKIM ou DMARC dans les emails reçus : ainsi ces domaines s’exposent à des risques de phishing beaucoup plus grands car ils ne vérifient pas si les expéditeurs sont réellement ceux qu’ils prétendent être. Au contraire, tous les grands acteurs de l’emailing implémentent bien le respect des directives DMARC, et protègent donc bien leurs utilisateurs contre les tentatives de phishing lorsque le domaine source a correctement configuré son entrée DNS DMARC.
Ainsi, un pirate qui souhaiterait usurper un domaine émetteur pourra encore faire des tentatives en ciblant des destinataires sur des petits domaines spécifique, et ce malgré le fait que la directive DMARC soit correctement configuré sur le domaine : le DMARC ne protégeant pas à 100% contre le risque d’usurpation d’identité, mais en diminue toutefois nettement la portée. En présence d’une configuration DMARC stricte, et devant la plus faible portée possible de leurs actions malveillantes, les piratges préféreront donc ne pas insister et reporteront souvent leurs actions sur un domaine plus simple car moins sécurisé.

 

Il existe de multiples outils sur internet qui permettent de vérifier gratuitement que la configuration DMARC d’un domaine est conforme, dont notamment : Mxtoolbox ou Dmarcian .
Les sociétés derrière ces outils offrent souvent une expertise email dans la configuration et la sécurisation d’un domaine, dans le but d’enlever l’aspect technique et fastidieux de cette étape et permettre une intégration simplifiée de cette couche de sécurité dans un domaine émetteur.

 

Il faut également noter que depuis la diffusion à grande échelle du DMARC dans l’ensemble des providers gratuits d’email (gmail, hotmail, yahoo, aol, etc), cette directive a eut pour conséquence de bloquer la possibilité pour une personne d’utiliser son adresse email personnelle comme adresse émettrice lors d’envoi de bulk email au travers des routeurs email.
En effet, si l’on prend par exemple une adresse de type XXXX@gmail.com, alors la directive DMARC de gmail n’autorise pas les IP des routeurs emails à envoyer un email avec cette adresse source, ce qui aboutirait à des refus massif de réception des emails envoyés. Les routeurs emails ont donc réagi en déconseillant dans un premier temps l’utilisation de ce type d’adresse email “personnelle” dans leur outils, et ont dorénavant carrément bloqué cette possibilité à leurs utilisateurs.

 

En conclusion, même s’il n’est donc pas parfait en soi, le mécanisme DMARC représente aujourd’hui la meilleure sécurité qui existe pour diminuer au maximum les risques d’usurpation des adresses email émettrices, et devrait donc etre configuré systématiquement par tous les domaines internet. Lorsque la configuration est réalisée au départ, celle-ci est très simple et sans risque, mais elle peut devenir plus complexe et nécessiter une analyse minutieuse dans le cadre de son activation sur un domaine deja existant qui envoie des emails depuis longtemps.