Un Outil Efficace pour Lutter Contre les Courriers Frauduleux
Souvent mentionné dans le même contexte que les protocoles d'authentification des e-mails SPF et DKIM, DMARC, ou Domain-based Message Authentication, Reporting, and Conformance, n'est pas en soi un protocole d'authentification. Au lieu de cela, l'objectif de DMARC est de permettre à nous, les propriétaires de domaine, de protéger notre réputation par e-mail en :
Annonçant les pratiques d'authentification des e-mails,
Demandant un traitement pour les courriers qui échouent aux vérifications d'authentification, et
Sollicitant des rapports concernant les courriers prétendant provenir de son domaine.
DMARC peut être un outil efficace pour nous dans notre lutte contre les courriers frauduleux qui ciblent notre nom de domaine (par exemple, phishing et usurpation), et qui peut promouvoir une plus grande confiance parmi nos destinataires pour nos e-mails. Cette confiance accrue devrait, à son tour, conduire à un engagement plus élevé avec nos e-mails, et les e-mails qui sont ouverts et génèrent des clics entraînent des ventes et un meilleur retour sur investissement pour nos campagnes e-mail.
En plus de protéger notre domaine, nous prévoyons qu'implémenter DMARC maintenant sera un excellent moyen de « protéger notre domaine pour l'avenir ». Ici chez Bird, nous croyons qu'à mesure que l'industrie passe à IPv6, il est presque certain qu'elle passera d'un modèle de réputation basé sur l'IP à un modèle de réputation basé sur le domaine. La réputation basée sur le domaine nécessitera une authentification basée sur le domaine, et DMARC, en concert avec DKIM et SPF, aidera les domaines à établir une réputation basée sur le domaine bien avant qu'elle ne devienne absolument nécessaire.
Dans ce post, nous vous expliquerons tout ce que vous devez savoir sur l'exploitation de DMARC pour protéger votre réputation par e-mail et vous donnerons des conseils sur la façon de le mettre en place pour vos domaines.
Termes à Connaître
Avant que nous nous lancions dans la mise en place de DMARC pour votre domaine, nous voulons nous assurer que nous parlons le même langage. Commençons par définir quelques termes que nous utiliserons tout au long de ce document.
Domaine RFC5322.From
Le domaine RFC5322.From est la partie domaine de l'adresse e-mail généralement vue par un destinataire de notre e-mail lorsqu'il est lu. Dans l'exemple suivant, le domaine RFC5322.From est « joesbaitshop.com »
From : Joe’s Bait and Tackle <sales@joesbaitshop.com>
Domaine DKIM d=
DKIM est un protocole d'authentification qui permet à un domaine de prendre la responsabilité d'un message d'une manière qui peut être validée par le destinataire du message ; cela se fait grâce à l'utilisation de signatures cryptographiques insérées dans les en-têtes du message lorsqu'il quitte son point d'origine. Ces signatures sont effectivement des instantanés de ce à quoi ressemblait le message à ce moment-là, et le destinataire peut les utiliser pour voir si le message est arrivé inchangé à sa destination. Le processus de production et d'insertion de ces instantanés est appelé signature DKIM, et le domaine qui prend la responsabilité du message en le signant insère son nom dans l'en-tête sous la forme d'une balise clé-valeur comme « d=signingDomain », et c'est donc ce qu'on appelle le domaine DKIM d=.
Domaine Return-Path
Le domaine Return-Path, parfois appelé le domaine RFC5321.From ou le domaine Mail From, est le domaine vers lequel les rebonds sont routés ; c'est aussi le domaine sur lequel les vérifications SPF sont effectuées lors de la transaction e-mail. Ce domaine n'est généralement pas vu par le destinataire à moins que celui-ci ne soit assez avisé pour regarder tous les en-têtes d'un message donné.
Par défaut, tous les e-mails envoyés via bird.com auront birdmail.com comme domaine Return-Path, comme dans l'exemple suivant :
Return-Path : <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Cependant, pour que DMARC fonctionne pour votre domaine, vous souhaiterez tirer parti d'un domaine de rebond personnalisé, un qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.votre_domaine.com lors de l'utilisation de votre_domaine.com comme domaine d'envoi.
Domaine Organisationnel
Le terme « Domaine Organisationnel » se réfère au domaine qui a été soumis à un registraire pour créer la présence du domaine sur Internet. Pour Bird, nos domaines organisationnels sont bird.com et birdmail.com.
Alignement de Domaine
Le dernier terme à comprendre concernant DMARC est l'« Alignement de Domaine », et il se décline en deux variantes : « détendu » et « strict ».
Alignement de Domaine Détendu
Deux domaines sont dits avoir un alignement de domaine détendu lorsque leurs domaines organisationnels sont les mêmes. Par exemple, a.mail.bird.com et b.foo.bird.com ont un alignement de domaine détendu en raison de leur domaine organisationnel commun, bird.com.
Alignement de Domaine Strict
Deux domaines sont dits en alignement de domaine strict si et seulement s'ils sont identiques. Ainsi, foo.bird.com et foo.bird.com sont en alignement strict, car les deux domaines sont identiques. En revanche, foo.bird.com et bar.foo.bird.com ne sont qu'en alignement détendu.
Exigences d'Alignement de Domaine DMARC
Pour que les vérifications de validation DMARC passent, DMARC exige qu'il y ait un alignement de domaine comme suit :
Pour SPF, le domaine RFC5322.From et le domaine Return-Path doivent être en alignement
Pour DKIM, le domaine RFC5322.From et le domaine DKIM d= doivent être en alignement
L'alignement peut être détendu ou strict, en fonction de la politique publiée du domaine d'envoi.
Comment DMARC Fonctionne pour Protéger Votre Réputation par E-mail
Lorsque nous parlons d'un fournisseur de boîte aux lettres ou d'un autre domaine « vérifiant DMARC », ou « validant DMARC », ou « appliquant la politique DMARC », ce que nous voulons dire, c'est que le domaine recevant un message effectue les étapes suivantes :
Déterminer le domaine RFC5322.From du message
Consulter la politique DMARC de ce domaine dans le DNS
Effectuer la validation de la signature DKIM
Effectuer la validation SPF
Vérifier l'alignement de domaine
Appliquer la politique DMARC
Pour qu'un message passe la validation DMARC, le message doit passer l'une des deux vérifications d'authentification et d'alignement. Ainsi, un message passera la validation DMARC si l'une des affirmations suivantes est vraie :
Le message réussit les vérifications SPF et le domaine RFC5322.From et le domaine Return-Path sont en alignement, ou
Le message réussit la validation DKIM et le domaine RFC5322.From et le domaine DKIM d= sont en alignement, ou
Les deux affirmations ci-dessus sont vraies
Faire Fonctionner DMARC pour Votre Domaine
Maintenant que nous avons expliqué le fonctionnement de DMARC, parlons de la façon de le faire fonctionner pour nous, ce qui implique les trois étapes suivantes :
Préparer à recevoir des rapports DMARC
Décider de la politique DMARC à utiliser pour votre domaine
Publier votre enregistrement DMARC
Nous allons couvrir chacune de ces étapes en détail ci-dessous, mais nous vous dirons directement que la première étape ci-dessus consommera environ 95 % de votre temps de préparation.
Se Préparer à Recevoir des Rapports DMARC
Tout domaine qui publie une politique DMARC devrait d'abord se préparer à recevoir des rapports concernant son domaine. Ces rapports seront générés par tout domaine effectuant une validation DMARC et voyant des courriers prétendant provenir de notre domaine, et seront envoyés à nous au moins quotidiennement. Les rapports arriveront dans deux formats :
Rapports Agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courriers vus par le rapporteur à partir de chaque source, quels ont été les résultats d'authentification, et comment les messages ont été traités par le rapporteur. Les rapports agrégés sont conçus pour être analysés par machine, avec leurs données stockées quelque part pour permettre une analyse globale du trafic, un audit des flux de messages de notre domaine, et peut-être l'identification de tendances dans les sources des e-mails potentiellement frauduleux non authentifiés.
Rapports Judiciaires, qui sont des copies individuelles de messages ayant échoué à l'authentification, chacun étant inclus dans un message e-mail complet utilisant un format appelé AFRF. Les rapports judiciaires sont censés contenir des en-têtes complets et des corps de message, mais de nombreux rapporteurs suppriment ou masquent certaines informations pour des raisons de confidentialité. Néanmoins, le rapport judiciaire peut encore être utile tant pour résoudre les problèmes d'authentification de notre domaine que pour identifier, à partir des URI dans les corps des messages, des domaines malveillants et des sites Web utilisés pour frauder les clients du propriétaire du domaine.
La préparation pour recevoir ces rapports implique d'abord de créer deux boîtes aux lettres dans notre domaine pour gérer ces rapports, telles que agg_reports@notredomaine.com et afrf_reports@notredomaine.com. Notez que ces noms de boîtes aux lettres sont complètement arbitraires, et il n'y a aucune exigence concernant le nommage de la partie locale de la boîte aux lettres ; nous sommes libres de choisir n'importe quels noms que nous souhaitons, mais gardons les deux séparés pour un traitement plus facile.
Une fois que les noms de boîte aux lettres ont été sélectionnés et créés dans notre domaine, la prochaine chose à faire ici est de mettre en place des outils pour lire ces boîtes aux lettres et utiliser les données, en particulier les rapports de données agrégées, qui, encore une fois, sont conçus pour être analysés par machine, plutôt que par un humain. Les rapports judiciaires, en revanche, pourraient être gérables simplement en les lisant nous-mêmes, mais notre capacité à le faire dépendra à la fois de la compréhension par notre client de messagerie de la façon d'afficher les messages au format AFRF et du volume de rapports que nous recevons.
Bien qu'il soit possible pour nous d'écrire nos propres outils pour traiter les rapports DMARC, jusqu'à ce que Bird fournisse de tels services pour les clients de bird.com (ce que nous envisageons, mais ne promettons pas encore), nous recommandons de faire usage d'outils déjà disponibles pour cette tâche.
Quelle Politique DMARC Utiliser
La spécification DMARC fournit trois choix pour les propriétaires de domaine afin de spécifier leur traitement préféré des courriers qui échouent aux vérifications de validation DMARC. Ce sont :
aucun, signifiant traiter le courrier de la même manière qu'il serait traité indépendamment des vérifications de validation DMARC
mise en quarantaine, signifiant accepter le courrier mais le placer ailleurs que la boîte de réception du destinataire (typiquement le dossier spam)
rejeter, signifiant rejeter le message directement
Il est important de garder à l'esprit que le propriétaire du domaine ne peut demander un tel traitement que dans son enregistrement DMARC ; il appartient au destinataire du message de décider s'il souhaite ou non respecter la politique demandée. Certains le feront, tandis que d'autres peuvent être un peu plus indulgents dans l'application de la politique, par exemple en classant dans le dossier spam les courriers lorsque la politique du domaine est de rejeter.
Nous recommandons à tous nos clients de commencer avec une politique de aucun, simplement pour être prudents. Bien que nous soyons confiants dans notre capacité à authentifier correctement vos e-mails via la signature DKIM, il est encore préférable de prendre un certain temps pour examiner les rapports concernant votre domaine avant de devenir plus agressif avec votre politique DMARC.
Publier Votre Politique DMARC
La politique DMARC d'un domaine est annoncée en publiant un enregistrement DNS TXT à un endroit spécifique dans l'espace de noms DNS, à savoir « _dmarc.nomdedomaine.tld » (notez le underscore en tête). Un enregistrement de politique DMARC de base pour notre exemple de domaine ci-dessus, joesbaitshop.com, pourrait ressembler à ceci :
_dmarc.joesbaitship.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:agg_reports@joesbait.com\; ruf=mailto:afrf_reports@joesbait.com\; pct=100"
Décomposons cet enregistrement, nous avons :
v=DMARC1 spécifie la version DMARC (1 est le seul choix en ce moment)
p=none spécifie le traitement préféré, ou la politique DMARC
rua=mailto:agg_reports@joesbait.com est la boîte aux lettres à laquelle les rapports agrégés doivent être envoyés
ruf=mailto:afrf_reports@joesbait.com est la boîte aux lettres à laquelle les rapports judiciaires doivent être envoyés
pct=100 est le pourcentage de courriers auxquels le propriétaire du domaine souhaite appliquer sa politique. Les domaines qui commencent à utiliser DMARC, en particulier ceux susceptibles de générer un volume élevé de rapports, peuvent souhaiter commencer par un chiffre beaucoup plus bas ici pour voir comment leurs processus de gestion de rapports tiennent face à la charge.
D'autres options de configuration sont également disponibles pour un propriétaire de domaine dans son enregistrement de politique DMARC, mais les conseils que nous avons fournis devraient constituer un bon point de départ.
Résumé
Il y a beaucoup d'informations à traiter dans ce qui précède ! Nous espérons que notre guide pour créer un enregistrement de politique DMARC vous sera utile. Nous espérons également que notre explication de l'importance de DMARC clarifie pourquoi vous devriez commencer à utiliser cet outil important pour protéger votre réputation par e-mail.
Bien sûr, ce n'est pas un document complet ou autoritaire sur le sujet. Si vous souhaitez approfondir ou avez besoin de plus d'aide, un excellent point de départ est la FAQ officielle de DMARC. Et, il va sans dire que l'équipe de support de Bird est prête à vous aider à configurer votre compte Bird pour DMARC également.
Merci d'avoir lu - et commencez à protéger vos domaines avec DMARC dès aujourd'hui !