Lorsque les organisations mettent en œuvre l’authentification, la création de rapports et la conformité des messages fondées sur le domaine (DMARC), elles s’attendent à renforcer la sécurité des e-mails et à se protéger contre l’usurpation d’identité et autres attaques par e-mail indésirable. Malheureusement, de nombreuses organisations rencontrent des erreurs et ne terminent pas la configuration de DMARC pour appliquer une politique DMARC, ce qui donne lieu à des systèmes de messagerie bien moins sécurisés qu’elles ne le pensent.
Cet article fournit les informations nécessaires pour aider une organisation à établir une politique DMARC robuste, notamment sur les points suivants :
- Résolution des problèmes liés à DMARC
- Raisons courantes des échecs de DMARC
- En bref : l’application de DMARC réduit le phishing
Résolution des problèmes liés à DMARC
La résolution des problèmes et le déploiement d’une politique correctement formatée d’authentification, création de rapports et conformité des messages fondées sur le domaine (DMARC) nécessiteront de la précision et du temps. Heureusement, de nombreuses ressources sont disponibles sur le site de DMARC.org, auprès des fournisseurs de messagerie et même de fournisseurs DMARC proposant des services complets, afin d’aider les équipes informatiques dans ce processus.
Processus général de résolution des problèmes
Lorsqu’elles tentent de corriger une politique DMARC après la configuration initiale, les organisations rencontrent divers problèmes. Les exigences de DMARC contribuent à définir les bonnes pratiques de résolution des problèmes, parmi lesquelles :
- Vérifier et contrôler en détail les politiques SPF, DKIM et DMARC
- Déployer DMARC en mode surveillance (p=none)
- Examiner le rapport DMARC pendant plusieurs semaines afin d’identifier les sources d’e-mails légitimes faisant l’objet de rejets
- Résoudre les problèmes de rejet en mettant à jour la politique appropriée (SPF, DKIM, DMARC ou paramètres du fournisseur de messagerie)
- Une fois les problèmes liés aux e-mails légitimes résolus
- Appliquer progressivement DMARC avec « p=quarantine » ou « p=reject »
- Rechercher de nouveaux problèmes de rejet
- Répéter les étapes jusqu’à ce que tous les domaines d’envoi soient vérifiés, protégés par une politique appliquée et entièrement sécurisés
- Vérifier régulièrement les rapports pour repérer les changements d’adresses IP ou les nouveaux conflits de domaines à résoudre, ainsi que les sites d’usurpation à signaler ou à bloquer
Guides de résolution des problèmes DMARC propres aux fournisseurs
La plupart des paramètres DMARC ne dépendent pas du fournisseur de messagerie utilisé, mais certains détails peuvent être propres à chaque fournisseur — notamment en ce qui concerne le déploiement DNS, l’activation de DMARC et la résolution des problèmes. Heureusement, la plupart des fournisseurs de messagerie proposent également des guides ou des tutoriels.
Microsoft 365 et Gmail proposent des tutoriels et des instructions spécialisées pour configurer correctement les politiques DMARC de leurs clients de messagerie. De même, des fournisseurs plus modestes tels que Twillio’s SendGrid publient leurs propres guides de résolution des problèmes. Les équipes informatiques devront donc consulter leurs fournisseurs de messagerie et de DNS pour obtenir des informations spécifiques.
Fournisseurs DMARC spécialisés
Les équipes informatiques débordées et manquant de ressources n’ont peut-être pas le temps d’étudier les exigences ou de résoudre les problèmes liés aux processus. Pour ces organisations, les fournisseurs DMARC spécialisés peuvent constituer une solution efficace permettant d’économiser du temps et de l’argent.
Seth Blank, directeur technique de Valimail et coprésident du groupe de travail DMARC, a suggéré : « Pour évaluer la capacité d’une plateforme à vous aider à atteindre l’application de la politique, examinez son expérience utilisateur, son automatisation et ses possibilités de personnalisation. » Les organisations doivent également vérifier que ces fournisseurs potentiels peuvent prendre en charge l’ensemble des politiques (SPF, DKIM, DMARC) et expliquer comment ils pourraient traiter des problèmes courants tels que les limites de recherche SPF.
Raisons courantes des échecs du déploiement de DMARC
Le déploiement de DMARC peut échouer pour de nombreuses raisons. Dans un premier temps, une organisation peut commettre des erreurs dans son enregistrement DMARC, ce qui entraîne l’échec des contrôles DMARC. Une fois l’enregistrement DMARC corrigé, l’organisation peut constater que de nombreux e-mails font l’objet d’un rejet DMARC, ce qui nécessite une nouvelle phase de résolution des problèmes.
Au-delà des problèmes techniques, DMARC peut également échouer en raison de ressources insuffisantes consacrées à sa prise en charge, voire parce que les paramètres DMARC ne sont pas renforcés. Une équipe informatique doit travailler avec les autres parties prenantes de l’organisation pour souligner l’importance de DMARC et surmonter ces obstacles.
Erreurs courantes liées à DMARC
Les fichiers texte sont petits et simples ; toutefois, cette simplicité signifie également que de petites erreurs peuvent créer de gros problèmes. Le groupe de travail DMARC publie une liste des problèmes courants liés aux enregistrements DMARC, qui présente des problèmes détaillés. Nous couvrons ici les principales catégories.
Enregistrements DNS non valides
Des enregistrements DMARC, DKIM et SPF publiés incorrectement, contenant du texte supplémentaire ou erroné, invalideront les enregistrements. Ces problèmes peuvent provenir de plusieurs types d’erreurs, notamment :
Les enregistrements génériques contiennent des caractères génériques ou du texte supplémentaire susceptible d’invalider l’enregistrement, par exemple :
- Enregistrements SPF utilisant l’adresse IP : ip4: 201.5.YY.ZZZ (au lieu de chiffres)
- Clés publiques de chiffrement DKIM incomplètes
- Texte ou commentaires aléatoires insérés dans l’enregistrement, tels que « Please contact your registrations service provider… », « *** » ou « This domain’s zone has been disabled »
- Nom du domaine ou du propriétaire du fournisseur inséré dans le fichier texte
Le non-respect des instructions peut s’apparenter aux enregistrements génériques, car il implique du texte supplémentaire ; toutefois, dans ce cas, il s’agit généralement d’instructions relatives au contenu qui sont restées dans le fichier, comme « texte descriptif » dans l’exemple suivant : « _dmarc.fromage.XXXXXXXX.fr texte descriptif v=DMARC1; p=reject;… »
Les erreurs courantes de formatage évitent les problèmes liés aux caractères génériques et au texte supplémentaire, mais créent des problèmes d’autres façons, notamment :
- Ordre des éléments : « v=DMARC1 » doit apparaître en premier et être écrit entièrement en majuscules ; ainsi, « p=none; v=DMARC1; rua=mailto:… » et « v=dmarc1;P=Reject;… » provoqueront des erreurs
- Oubli des balises variables ou d’une syntaxe correcte, par exemple l’écriture de
- « DMARC1 » au lieu de « v=DMARC1 »
- « rua=email@… » au lieu de « rua=mailto:email@… »
- Oubli des séparateurs point-virgule (;) ou utilisation d’un mauvais séparateur entre les variables, par exemple « v=DMARC1 p=none… » ou « v=DMARC1:p=none… » au lieu de « v=DMARC1;p=none… »
- Formatage autorisé, mais potentiellement problématique, comme :
- Utilisation de majuscules ailleurs que dans DMARC1, par exemple « V=DMARC1;P=NONE… » au lieu de « v=DMARC1;p=none… »
- Espaces inutiles, comme l’espace supplémentaire avant « mailto » dans « rua= mailto:email@… » au lieu de « rua=mailto:email@… »
Fautes de frappe et caractères supplémentaires s’introduisent souvent dans un enregistrement DNS à cause d’erreurs de copier-coller ou même d’exigences DNS spécifiques. Par exemple, certains serveurs DNS exigent que les points-virgules soient échappés à l’aide d’une barre oblique inverse (\) ; le fichier peut alors contenir trop de barres obliques inverses (\\) ou des barres obliques (/) utilisées par erreur.
Contenu d’enregistrement incorrect est répertorié séparément par dmarc.org, mais il présente de nombreux points communs avec les fautes de frappe et les erreurs de formatage. Par exemple, au lieu d’utiliser l’une des trois valeurs autorisées pour la balise « p » (none, quarantine, reject), l’enregistrement peut contenir des valeurs incorrectes (« blocked » ou « monitor ») ou mal orthographiées (« quarintine »).
Sous-domaines oubliés
Lors de la création de fichiers SPF, une organisation est limitée à 10 recherches DNS. Cela signifie souvent que les grandes organisations disposent de plusieurs fichiers SPF et séparent certains sous-domaines dans des enregistrements SPF distincts.
Cependant, lorsqu’elle crée son enregistrement DMARC, l’organisation peut se concentrer exclusivement sur le domaine de premier niveau (EX : SampleOrganization.com) et oublier ses sous-domaines (EX : ITNotifications.SampleOrganization.com ou SalesEmails.SampleOrganization.com).
Sauf s’ils sont explicitement traités séparément, la politique DMARC déployée sur le domaine de premier niveau s’applique automatiquement aux sous-domaines. Oublier les sous-domaines nécessitant un traitement distinct peut bloquer involontairement des e-mails légitimes provenant de serveurs hébergés sur ces sous-domaines.
Mises à jour DMARC oubliées
Tous les enregistrements DNS, y compris DMARC, doivent être mis à jour à mesure que les organisations évoluent. Par exemple, une organisation modifiera les adresses IP de ses serveurs de messagerie lors d’une mise à niveau ou d’une transition vers le cloud. Chaque changement d’adresse IP nécessite une mise à jour de la politique enregistrée.
De même, les entreprises envoient des campagnes d’e-mails depuis divers fournisseurs tiers pour le marketing (HubSpot, Mailchimp, etc.), les ventes (Salesforce, etc.), les enquêtes (SurveyMonkey, etc.), la comptabilité (Quickbooks, etc.) et les services d’assistance (Zendesk, etc.). Lorsqu’elles adoptent de nouveaux fournisseurs ou que ces derniers modifient leur infrastructure de messagerie, DMARC, SPF et DKIM doivent à nouveau être mis à jour pour suivre ces changements et éviter de bloquer des e-mails légitimes.
Rejets DMARC
Lors de la mise en œuvre de DMARC, les organisations commencent par « p=none » afin d’éviter de rejeter des e-mails légitimes mais mal configurés. Les trois méthodes les plus courantes de rejet des e-mails légitimes sont les suivantes :
- Absence de configuration des signatures DKIM pour les fournisseurs de messagerie — cela entraîne une discordance entre l’expéditeur (Gmail, Microsoft 365, etc.) et le domaine DMARC
- Absence de mise sur liste blanche des expéditeurs tiers auprès des fournisseurs DNS — ces fournisseurs signent par défaut les e-mails avec leur domaine, ce qui entraîne une discordance
- Modification du corps et des en-têtes par les entités de transfert — les services de retransmission, les passerelles et les solutions d’analyse des logiciels malveillants interceptent l’e-mail, puis le transfèrent. Le transfert remplace l’adresse IP de l’expéditeur, ce qui provoque une discordance DMARC
Les deux premiers problèmes peuvent être gérés en configurant correctement les signatures DKIM pour les fournisseurs de messagerie et en ajoutant correctement les expéditeurs tiers à la liste blanche des fournisseurs DNS. Malheureusement, il n’y a pas grand-chose à faire pour le troisième problème, à moins que l’organisation puisse contacter ou contrôler les serveurs de messagerie chargés du transfert.
En plus de ces trois problèmes courants, une organisation peut également rencontrer des problèmes d’alignement SPF et DKIM. L’alignement DMARC vise à empêcher l’usurpation de l’adresse « header from » en faisant correspondre :
- Le nom de domaine « header from » et le nom de domaine « MFROM » utilisés lors d’un contrôle SPF
- Le nom de domaine « header from » avec le « d=nom de domaine » de la signature DKIM
Souvent, les expéditeurs d’e-mails tiers provoquent des problèmes en utilisant leur propre domaine « MFROM ». Cela peut réussir le contrôle SPF ou DKIM, mais pas l’alignement. Ce problème nécessitera une coordination avec le fournisseur afin d’ajuster correctement les fichiers SPF, DKIM et DMARC.
Ressources insuffisantes
Les petites organisations ont toujours du mal à gérer les problèmes informatiques chronophages. Seth Blank a reconnu : « Franchement, la configuration de DMARC est complexe, ce qui explique l’écart entre les politiques et les politiques appliquées. »
Effectifs insuffisants
Malgré la simplicité des technologies concernées, la maintenance régulière nécessaire pour maintenir SPF, DKIM et DMARC à jour peut être difficile à assurer pour les grandes entreprises disposant d’équipes dédiées. Pour les petites organisations dotées de petites équipes informatiques, cette maintenance peut être quasiment impossible.
« DMARC est une norme complexe qui repose sur deux normes supplémentaires de messagerie, SPF et DKIM. Ces deux normes seraient déjà difficiles à configurer séparément. Les petites entreprises qui ne disposent pas d’un service informatique pouvant se consacrer à DMARC n’ont pas les ressources nécessaires pour mettre en œuvre ces enregistrements ensemble », a déclaré Blank.
Outils insuffisants
Les rapports agrégés et d’analyse envoyés par les fournisseurs de services de messagerie destinataires contiennent des informations essentielles sur l’écosystème des e-mails, mais les fichiers lisibles par machine ne sont ni intuitifs ni faciles à lire pour les humains. De plus, même pour les organisations de taille moyenne, le volume considérable de rapports reçus peut submerger une organisation qui tente de regrouper et d’analyser manuellement ces informations de manière pertinente. Heureusement, de nombreux outils de reporting DMARC peuvent être utilisés pour permettre une analyse rapide et pertinente des outils DMARC.
Absence de renforcement des paramètres DMARC
Le problème le plus important lié à DMARC vient du fait que les organisations ne renforcent pas leurs paramètres DMARC. Que ce soit par peur de bloquer des e-mails légitimes ou simplement parce que les équipes chargées de la mise en œuvre négligent cette étape, l’absence de passage de p=none à une politique plus stricte compromet l’efficacité de DMARC.
À moins qu’une organisation ne définisse une politique d’application sur « quarantine » ou « reject », même les e-mails reconnus comme frauduleux pourront continuer à parvenir aux boîtes de réception. Sans cette politique d’application plus restrictive, les organisations imposent une charge inutile aux applications de sécurité de la messagerie et augmentent la probabilité qu’une attaque de phishing usurpe efficacement l’identité d’une marque.
« Une politique qui n’est pas configurée sur « quarantine » ou « reject » pour les acteurs frauduleux ressemble à un videur qui contrôle les pièces d’identité et laisse entrer tout le monde, quel que soit l’âge », a déclaré Blank. « L’application de DMARC devrait constituer le premier niveau de protection… D’autres mesures de sécurité réseau, comme la surveillance fondée sur l’IA, peuvent être utiles, mais la vérification des pièces d’identité permet de voir qui tente d’obtenir un accès. »
En bref : l’application de DMARC réduit le phishing
Si chaque organisation déployait DMARC avec une application complète, les e-mails usurpés seraient considérablement réduits et les e-mails de phishing deviendraient bien moins efficaces. Bien que toutes les attaques par e-mail ne puissent pas être stoppées, la réduction des attaques crédibles par usurpation réduirait considérablement la charge pesant sur nos outils de sécurité de la messagerie ainsi que le nombre de victimes du phishing dans notre organisation et chez tous les autres destinataires. Il est temps de protéger votre marque, de vous défendre contre la compromission de messagerie professionnelle (BEC) et de réduire le SPAM à l’échelle mondiale grâce au déploiement complet de SPF, DKIM et DMARC.