DMARC : Comment protéger votre réputation par email

Email

1 min read

DMARC : Comment protéger votre réputation par email

Email

1 min read

DMARC : Comment protéger votre réputation par email

Dans cet article, nous vous dirons tout ce que vous devez savoir sur l'utilisation de DMARC pour protéger votre réputation par e-mail, et nous vous donnerons des conseils sur la façon de l'installer pour vos domaines.

Un outil efficace pour lutter contre le courrier frauduleux

Souvent mentionné dans le même souffle 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, le but de DMARC est de nous permettre, les propriétaires de domaines, de protéger notre réputation de courrier électronique en :

  • Annonçant des pratiques d'authentification de courrier électronique,

  • Demandant un traitement pour les mails qui échouent aux contrôles d'authentification, et

  • Sollicitant des rapports sur les mails prétendant provenir de son domaine.


DMARC peut être un outil efficace pour nous aider dans notre lutte contre les courriels frauduleux qui ciblent notre nom de domaine (par exemple, le phishing et le spoofing), et qui peuvent promouvoir une confiance accrue parmi nos destinataires pour nos courriels. Cette confiance accrue devrait, à son tour, mener à un engagement plus élevé avec nos courriels, et les courriels qui sont ouverts et génèrent des clics favorisent les ventes et un ROI plus élevé pour nos campagnes d'e-mail.

En plus de protéger notre domaine, nous prévoyons qu'implémenter DMARC maintenant sera une excellente façon de protéger l'avenir de notre domaine. Ici chez Bird, nous croyons que, à 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, de concert avec DKIM et SPF, aidera les domaines à établir une réputation basée sur le domaine bien avant que cela ne devienne absolument nécessaire.

Dans ce post, nous vous dirons tout ce que vous devez savoir sur l'utilisation de DMARC pour protéger votre réputation de courrier électronique et vous donnerons des conseils sur comment le configurer pour vos domaines.

Termes à connaître

Avant de configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons le même langage. Commençons par définir certains termes que nous utiliserons tout au long de ce document.

RFC5322.From Domain

Le domaine RFC5322.From est la partie domaine de l'adresse e-mail généralement vue par un destinataire lorsque notre e-mail est lu. Dans l'exemple suivant, le domaine RFC5322.From est « joesbaitshop.com »

De: Joe’s Bait and Tackle <sales@joesbaitshop.com>

DKIM d= Domain

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 récepteur du message ; cela se fait par 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 en réalité des instantanés de ce à quoi ressemblait le message à ce moment-là, et le récepteur peut utiliser ces instantanés pour voir si le message est arrivé inchangé à sa destination. Le processus de production et d'insertion de ces instantanés s'appelle la signature DKIM, et le domaine qui prend la responsabilité du message en le signant insère son nom dans l'en-tête dans une balise clé-valeur sous la forme « d=signingDomain », et il est donc appelé le domaine DKIM d=.

Domaine Return-Path

Le domaine Return-Path, parfois appelé domaine RFC5321. From ou domaine Mail From, est le domaine vers lequel les rebonds sont acheminés ; c'est aussi le domaine sur lequel des vérifications SPF sont effectuées pendant la transaction d'e-mail. Ce domaine n'est généralement pas vu par le destinataire à moins que le destinataire ne soit suffisamment connaisseur pour regarder tous les en-têtes d'un message donné.

Par défaut, tout le courrier envoyé via bird.com aura birdmail.com comme son 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 voudrez profiter d'un domaine de rebond personnalisé, qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.yourdomain.com lors de l'utilisation de yourdomain.com comme domaine d'envoi.

Domaine Organisationnel

Le terme « Domaine Organisationnel » fait référence au domaine qui a été soumis à un enregistreur 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 « Alignement de Domaine », et il se présente sous deux variantes : « relâché » et « strict ».

Alignement Relâché de Domaine

Deux domaines sont dits avoir un alignement de domaine relâché lorsque leurs Domaines Organisationnels sont identiques. Par exemple, a.mail.bird.com et b.foo.bird.com ont un alignement de domaine relâché en raison de leur Domaine Organisationnel commun, bird.com.

Alignement Strict de Domaine

Deux domaines sont dits en alignement strict de domaine 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 sont seulement en alignement relâché.

Exigences d'Alignement de Domaine DMARC

Pour que les contrôles de validation DMARC réussissent, 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 relâché ou strict, basé sur la politique publiée du domaine d'envoi.

Avant de configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons le même langage. Commençons par définir certains termes que nous utiliserons tout au long de ce document.

RFC5322.From Domain

Le domaine RFC5322.From est la partie domaine de l'adresse e-mail généralement vue par un destinataire lorsque notre e-mail est lu. Dans l'exemple suivant, le domaine RFC5322.From est « joesbaitshop.com »

De: Joe’s Bait and Tackle <sales@joesbaitshop.com>

DKIM d= Domain

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 récepteur du message ; cela se fait par 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 en réalité des instantanés de ce à quoi ressemblait le message à ce moment-là, et le récepteur peut utiliser ces instantanés pour voir si le message est arrivé inchangé à sa destination. Le processus de production et d'insertion de ces instantanés s'appelle la signature DKIM, et le domaine qui prend la responsabilité du message en le signant insère son nom dans l'en-tête dans une balise clé-valeur sous la forme « d=signingDomain », et il est donc appelé le domaine DKIM d=.

Domaine Return-Path

Le domaine Return-Path, parfois appelé domaine RFC5321. From ou domaine Mail From, est le domaine vers lequel les rebonds sont acheminés ; c'est aussi le domaine sur lequel des vérifications SPF sont effectuées pendant la transaction d'e-mail. Ce domaine n'est généralement pas vu par le destinataire à moins que le destinataire ne soit suffisamment connaisseur pour regarder tous les en-têtes d'un message donné.

Par défaut, tout le courrier envoyé via bird.com aura birdmail.com comme son 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 voudrez profiter d'un domaine de rebond personnalisé, qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.yourdomain.com lors de l'utilisation de yourdomain.com comme domaine d'envoi.

Domaine Organisationnel

Le terme « Domaine Organisationnel » fait référence au domaine qui a été soumis à un enregistreur 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 « Alignement de Domaine », et il se présente sous deux variantes : « relâché » et « strict ».

Alignement Relâché de Domaine

Deux domaines sont dits avoir un alignement de domaine relâché lorsque leurs Domaines Organisationnels sont identiques. Par exemple, a.mail.bird.com et b.foo.bird.com ont un alignement de domaine relâché en raison de leur Domaine Organisationnel commun, bird.com.

Alignement Strict de Domaine

Deux domaines sont dits en alignement strict de domaine 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 sont seulement en alignement relâché.

Exigences d'Alignement de Domaine DMARC

Pour que les contrôles de validation DMARC réussissent, 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 relâché ou strict, basé sur la politique publiée du domaine d'envoi.

Avant de configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons le même langage. Commençons par définir certains termes que nous utiliserons tout au long de ce document.

RFC5322.From Domain

Le domaine RFC5322.From est la partie domaine de l'adresse e-mail généralement vue par un destinataire lorsque notre e-mail est lu. Dans l'exemple suivant, le domaine RFC5322.From est « joesbaitshop.com »

De: Joe’s Bait and Tackle <sales@joesbaitshop.com>

DKIM d= Domain

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 récepteur du message ; cela se fait par 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 en réalité des instantanés de ce à quoi ressemblait le message à ce moment-là, et le récepteur peut utiliser ces instantanés pour voir si le message est arrivé inchangé à sa destination. Le processus de production et d'insertion de ces instantanés s'appelle la signature DKIM, et le domaine qui prend la responsabilité du message en le signant insère son nom dans l'en-tête dans une balise clé-valeur sous la forme « d=signingDomain », et il est donc appelé le domaine DKIM d=.

Domaine Return-Path

Le domaine Return-Path, parfois appelé domaine RFC5321. From ou domaine Mail From, est le domaine vers lequel les rebonds sont acheminés ; c'est aussi le domaine sur lequel des vérifications SPF sont effectuées pendant la transaction d'e-mail. Ce domaine n'est généralement pas vu par le destinataire à moins que le destinataire ne soit suffisamment connaisseur pour regarder tous les en-têtes d'un message donné.

Par défaut, tout le courrier envoyé via bird.com aura birdmail.com comme son 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 voudrez profiter d'un domaine de rebond personnalisé, qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.yourdomain.com lors de l'utilisation de yourdomain.com comme domaine d'envoi.

Domaine Organisationnel

Le terme « Domaine Organisationnel » fait référence au domaine qui a été soumis à un enregistreur 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 « Alignement de Domaine », et il se présente sous deux variantes : « relâché » et « strict ».

Alignement Relâché de Domaine

Deux domaines sont dits avoir un alignement de domaine relâché lorsque leurs Domaines Organisationnels sont identiques. Par exemple, a.mail.bird.com et b.foo.bird.com ont un alignement de domaine relâché en raison de leur Domaine Organisationnel commun, bird.com.

Alignement Strict de Domaine

Deux domaines sont dits en alignement strict de domaine 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 sont seulement en alignement relâché.

Exigences d'Alignement de Domaine DMARC

Pour que les contrôles de validation DMARC réussissent, 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 relâché ou strict, basé sur la politique publiée du domaine d'envoi.

Comment DMARC Works to Protect Your Email Reputation

Lorsque nous parlons d'un fournisseur de boîtes 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 :

  1. Déterminer le domaine RFC5322.From du message

  2. Rechercher la politique DMARC de ce domaine dans le DNS

  3. Effectuer la validation de la signature DKIM

  4. Effectuer la validation SPF

  5. Vérifier l'alignement du domaine

  6. Appliquer la politique DMARC


Pour qu'un message réussisse la validation DMARC, il doit réussir seulement l'un des deux contrôles d'authentification et d'alignement. Ainsi, un message passera la validation DMARC si l'une des conditions suivantes est vraie :

  • Le message réussit les contrôles SPF et le domaine RFC5322.From et le domaine Return-Path sont alignés, ou

  • Le message réussit la validation DKIM et le domaine RFC5322.From et le domaine DKIM d= sont alignés, ou

  • Les deux conditions 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 faire fonctionner DMARC pour nous, ce qui implique les trois étapes suivantes :

  1. Préparer la réception des rapports DMARC

  2. Décider quelle politique DMARC utiliser pour votre domaine

  3. Publier votre enregistrement DMARC

Nous couvrirons chacun de ces points en détail ci-dessous, mais nous vous dirons tout de suite que l'étape 1 ci-dessus consommera environ 95 % de votre temps de préparation.

Préparation à la réception des rapports DMARC

Tout domaine qui publie une politique DMARC doit 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 mails prétendant provenir de notre domaine, et ils nous seront envoyés au moins quotidiennement. Les rapports seront disponibles sous deux formats :

  • Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de mails vus par le rapporteur de chaque source, quels ont été les résultats de l'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 des machines, avec leurs données stockées quelque part pour permettre une analyse globale du trafic, l'audit des flux de messages de notre domaine, et peut-être l'identification des tendances dans les sources d'email non authentifié, potentiellement frauduleux.

  • Rapports techniques, qui sont des copies individuelles de messages ayant échoué à l'authentification, chacun étant inclus dans un message email complet utilisant un format appelé AFRF. Les rapports techniques sont censés contenir des en-têtes complets et des corps de message, mais de nombreux rapporteurs retirent ou anonymisent certaines informations en raison de préoccupations en matière de confidentialité. Néanmoins, le rapport technique peut toujours être utile à la fois pour résoudre les problèmes d'authentification de notre propre domaine et pour identifier, à partir des URI dans les corps des messages, les domaines et sites Internet malveillants utilisés pour frauder les clients du propriétaire de notre domaine.


La préparation à la réception de ces rapports implique d’abord de créer deux boîtes mail dans notre domaine pour gérer ces rapports, telles que agg_reports@ourdomain.com et afrf_reports@ourdomain.com. Notez que ces noms de boîte mail sont complètement arbitraires, et qu'il n'y a pas d'exigences pour la dénomination de la partie locale de la boîte mail ; nous sommes libres de choisir les noms que nous voulons, mais les garder séparés pour un traitement plus facile.

Une fois les noms des boîtes mail sélectionnés et créés dans notre domaine, la prochaine étape consiste à mettre en place des outils pour lire ces boîtes mails et utiliser les données, surtout les rapports de données agrégées, qui encore une fois sont conçus pour être analysés par des machines, plutôt que lus par un humain. Les rapports techniques, d'autre part, peuvent simplement être gérés en les lisant nous-mêmes, mais notre capacité à le faire dépendra à la fois de la compréhension par notre client mail de la manière d'afficher les messages au format AFRF et du volume de rapports que nous recevrons.

Bien qu’il nous soit possible de créer nos propres outils pour traiter les rapports DMARC, tant que Bird n'offre pas encore de tels services pour les clients de bird.com (quelque chose que nous envisageons, mais que nous ne promettons pas encore), nous recommandons d'utiliser des outils déjà disponibles pour cette tâche.

Quelle DMARC Policy to Use

La spécification DMARC fournit trois choix pour que les propriétaires de domaine spécifient leur traitement préféré du courrier qui échoue aux vérifications de validation DMARC. Ils sont :

  • none, ce qui signifie traiter le courrier de la même manière qu'il serait traité indépendamment des vérifications de validation DMARC

  • quarantine, ce qui signifie accepter le courrier mais le placer ailleurs que dans l'Inbox du destinataire (typiquement le dossier spam)

  • reject, ce qui signifie rejeter le message directement


Il est important de garder à l'esprit que le propriétaire du domaine ne peut que demander un tel traitement dans son enregistrement DMARC ; il appartient au destinataire du message de décider d'honorer ou non la politique demandée. Certains le feront, tandis que d'autres peuvent être un peu plus indulgents dans l'application de la politique, comme ne déplacer le courrier vers le dossier spam que lorsque la politique du domaine est reject.

Nous recommandons à tous nos clients de lancer avec une politique de none, simplement pour être prudents. Bien que nous soyons confiants dans notre capacité à authentifier correctement votre courrier via la signature DKIM, il est préférable de prendre le temps d'examiner les rapports sur votre domaine avant de devenir plus agressif avec votre politique DMARC.

Publication de Votre Politique DMARC

La politique DMARC d’un domaine est annoncée par la publication d’un enregistrement DNS TXT à un endroit spécifique dans l’espace de noms DNS, à savoir « _dmarc.domainname.tld » (notez le soulignement au début). Un enregistrement de politique DMARC de base pour notre domaine d’exemple précédent, 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"

En décomposant cet enregistrement, nous avons :

  • v=DMARC1 spécifie la version DMARC (1 est le seul choix pour l’instant)

  • 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 d’analyse judiciaire doivent être envoyés

  • pct=100 est le pourcentage de mail auquel le propriétaire du domaine souhaite appliquer sa politique. Les domaines qui commencent tout juste avec DMARC, en particulier ceux susceptibles de générer un volume élevé de rapports, peuvent vouloir commencer avec un nombre beaucoup plus bas ici pour voir comment leurs processus de gestion des rapports résistent à 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éballer dans les informations ci-dessus ! Nous espérons que vous trouverez utile le guide pour créer un enregistrement de politique DMARC. Nous espérons également que notre explication sur pourquoi DMARC est important vous aide à comprendre pourquoi vous devriez commencer à utiliser cet outil important pour protéger votre réputation de courriel.

Bien sûr, ce n'est pas un document complet ou autoritaire sur le sujet. Si vous souhaitez approfondir ou si vous 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 de lire - et commencez à protéger vos domaines avec DMARC dès aujourd'hui !

Connectons-vous avec un expert Bird.
Découvrez toute la puissance du Bird en 30 minutes.

En soumettant, vous acceptez que Bird puisse vous contacter au sujet de nos produits et services.

Vous pouvez vous désabonner à tout moment. Consultez la Déclaration de confidentialité de Bird pour plus de détails sur le traitement des données.

Company

Newsletter

Restez à jour avec Bird grâce aux mises à jour hebdomadaires dans votre boîte de réception.

En soumettant, vous acceptez que Bird puisse vous contacter au sujet de nos produits et services.

Vous pouvez vous désabonner à tout moment. Consultez la Déclaration de confidentialité de Bird pour plus de détails sur le traitement des données.

Connectons-vous avec un expert Bird.
Découvrez toute la puissance du Bird en 30 minutes.

En soumettant, vous acceptez que Bird puisse vous contacter au sujet de nos produits et services.

Vous pouvez vous désabonner à tout moment. Consultez la Déclaration de confidentialité de Bird pour plus de détails sur le traitement des données.

Company

Newsletter

Restez à jour avec Bird grâce aux mises à jour hebdomadaires dans votre boîte de réception.

En soumettant, vous acceptez que Bird puisse vous contacter au sujet de nos produits et services.

Vous pouvez vous désabonner à tout moment. Consultez la Déclaration de confidentialité de Bird pour plus de détails sur le traitement des données.

Connectons-vous avec un expert Bird.
Découvrez toute la puissance du Bird en 30 minutes.

En soumettant, vous acceptez que Bird puisse vous contacter au sujet de nos produits et services.

Vous pouvez vous désabonner à tout moment. Consultez la Déclaration de confidentialité de Bird pour plus de détails sur le traitement des données.

R

Atteindre

G

Grow

M

Manage

A

Automate

Company

Newsletter

Restez à jour avec Bird grâce aux mises à jour hebdomadaires dans votre boîte de réception.

En soumettant, vous acceptez que Bird puisse vous contacter au sujet de nos produits et services.

Vous pouvez vous désabonner à tout moment. Consultez la Déclaration de confidentialité de Bird pour plus de détails sur le traitement des données.