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 de courriel 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, en tant que propriétaires de domaine, de protéger notre réputation par courriel en :

  • Déclarant des pratiques d'authentification des courriels,

  • Demandant un traitement pour les courriels qui échouent aux vérifications d'authentification, et

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




DMARC peut être un outil efficace pour nous aider dans notre lutte contre le courrier frauduleux qui cible notre nom de domaine (par exemple, le phishing et l'usurpation d'identité), et qui peut promouvoir une plus grande confiance parmi nos destinataires pour notre courrier. Cette confiance accrue devrait, à son tour, mener à un engagement plus élevé avec notre courrier, et les courriels ouverts et générant des clics stimulent les ventes et augmentent le ROI de nos campagnes par courriel.




En plus de protéger notre domaine, nous prévoyons que la mise en œuvre de DMARC dès maintenant sera un excellent moyen de "préparer notre domaine pour l'avenir". Ici chez Bird, nous croyons qu'à mesure que l'industrie évolue vers IPv6, il est presque certain qu'elle passera d'un modèle de réputation basé sur l'adresse 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 que cela ne devienne absolument nécessaire.




Dans cet article, nous vous dirons tout ce que vous devez savoir sur la façon d'utiliser DMARC pour protéger votre réputation par courriel et vous donnerons des conseils sur la façon de le configurer pour vos domaines.

Termes à connaître

Avant de configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons la même langue. Commençons par définir quelques 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 que le destinataire de notre e-mail voit habituellement lorsqu'il le lit. 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 effectivement des instantanés de l'apparence du message à ce moment-là, et le récepteur peut utiliser ces instantanés pour vérifier 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 forme de balise clé-valeur comme « d=signingDomain », et il est donc appelé le domaine DKIM d=.




Return-Path Domain

Le domaine Return-Path, parfois appelé RFC5321.From Domain ou Mail From domain, est le domaine vers lequel les rebonds sont acheminés ; c'est aussi le domaine sur lequel les vérifications SPF sont effectuées pendant la transaction de courrier électronique. Ce domaine n'est généralement pas vu par le destinataire sauf si le destinataire est suffisamment avisé pour examiner tous les en-têtes d'un message donné.

Par défaut, tous les courriers 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 voudrez profiter d'un domaine de rebond personnalisé, un qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lors de l'utilisation de votredomaine.com comme votre domaine d'envoi.




Domaine Organisationnel

Le terme « Domaine Organisationnel » fait référence 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 « Alignement de Domaine », et il se décline en deux variantes : « relâché » et « strict ».




Alignement de Domaine Relâché

Deux domaines quelconques sont dits en 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é à cause 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 en alignement que relâché.




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 alignés

  • Pour DKIM, le domaine RFC5322.From et le domaine DKIM d= doivent être alignés

L'alignement peut être relâché ou strict, selon la politique publiée du domaine d'envoi.

Avant de configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons la même langue. Commençons par définir quelques 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 que le destinataire de notre e-mail voit habituellement lorsqu'il le lit. 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 effectivement des instantanés de l'apparence du message à ce moment-là, et le récepteur peut utiliser ces instantanés pour vérifier 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 forme de balise clé-valeur comme « d=signingDomain », et il est donc appelé le domaine DKIM d=.




Return-Path Domain

Le domaine Return-Path, parfois appelé RFC5321.From Domain ou Mail From domain, est le domaine vers lequel les rebonds sont acheminés ; c'est aussi le domaine sur lequel les vérifications SPF sont effectuées pendant la transaction de courrier électronique. Ce domaine n'est généralement pas vu par le destinataire sauf si le destinataire est suffisamment avisé pour examiner tous les en-têtes d'un message donné.

Par défaut, tous les courriers 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 voudrez profiter d'un domaine de rebond personnalisé, un qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lors de l'utilisation de votredomaine.com comme votre domaine d'envoi.




Domaine Organisationnel

Le terme « Domaine Organisationnel » fait référence 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 « Alignement de Domaine », et il se décline en deux variantes : « relâché » et « strict ».




Alignement de Domaine Relâché

Deux domaines quelconques sont dits en 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é à cause 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 en alignement que relâché.




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 alignés

  • Pour DKIM, le domaine RFC5322.From et le domaine DKIM d= doivent être alignés

L'alignement peut être relâché ou strict, selon la politique publiée du domaine d'envoi.

Avant de configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons la même langue. Commençons par définir quelques 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 que le destinataire de notre e-mail voit habituellement lorsqu'il le lit. 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 effectivement des instantanés de l'apparence du message à ce moment-là, et le récepteur peut utiliser ces instantanés pour vérifier 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 forme de balise clé-valeur comme « d=signingDomain », et il est donc appelé le domaine DKIM d=.




Return-Path Domain

Le domaine Return-Path, parfois appelé RFC5321.From Domain ou Mail From domain, est le domaine vers lequel les rebonds sont acheminés ; c'est aussi le domaine sur lequel les vérifications SPF sont effectuées pendant la transaction de courrier électronique. Ce domaine n'est généralement pas vu par le destinataire sauf si le destinataire est suffisamment avisé pour examiner tous les en-têtes d'un message donné.

Par défaut, tous les courriers 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 voudrez profiter d'un domaine de rebond personnalisé, un qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lors de l'utilisation de votredomaine.com comme votre domaine d'envoi.




Domaine Organisationnel

Le terme « Domaine Organisationnel » fait référence 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 « Alignement de Domaine », et il se décline en deux variantes : « relâché » et « strict ».




Alignement de Domaine Relâché

Deux domaines quelconques sont dits en 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é à cause 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 en alignement que relâché.




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 alignés

  • Pour DKIM, le domaine RFC5322.From et le domaine DKIM d= doivent être alignés

L'alignement peut être relâché ou strict, selon la politique publiée du domaine d'envoi.

Comment DMARC Works to Protect Your Email Reputation

Lorsque nous parlons d'un fournisseur de boîte de réception ou d'un autre domaine « checking DMARC », ou « validating DMARC », ou « applying DMARC policy », 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 passe 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 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 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 qui effectue une validation DMARC et voit des courriers prétendant provenir de notre domaine, et nous seront envoyés au moins quotidiennement. Les rapports viendront sous deux formats :

  • Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courriers vue par le rapporteur de chaque source, quels étaient 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 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 éventuellement l'identification de tendances dans les sources d'emails non authentifiés, potentiellement frauduleux.

  • Rapports juridiques, 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 juridiques devraient contenir des en-têtes et corps de message complets, mais de nombreux rapporteurs suppriment ou caviardent certaines informations en raison de préoccupations concernant la confidentialité. Néanmoins, le rapport juridique peut encore être utile à la fois pour résoudre les problèmes d'authentification de notre domaine et pour identifier, à partir des URIs dans les corps de message, des domaines malveillants et des sites Web utilisés pour frauder les clients du propriétaire de notre 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@ourdomain.com et afrf_reports@ourdomain.com. Notez que ces noms de boîtes aux lettres sont complètement arbitraires, et il n'y a aucune exigence pour le nommage de la partie locale de la boîte aux lettres ; nous sommes libres de choisir les noms que nous souhaitons, mais gardons les deux séparées pour un traitement plus facile.




Une fois les noms de boîtes aux lettres choisis et créés dans notre domaine, la prochaine étape consiste à 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és, qui, rappelons-le, sont conçus pour être analysés par des machines, plutôt que lus par un humain. Les rapports juridiques, quant à eux, peuvent être gérables simplement en les lisant nous-mêmes, mais notre capacité à le faire dépendra à la fois de la compréhension de 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 (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 propose trois choix pour que les propriétaires de domaine précisent leur traitement préféré des e-mails qui échouent 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 la Inbox du destinataire (généralement dans le dossier spam)

  • reject, ce qui signifie rejeter le message purement et simplement




Il est important de garder à l'esprit que le propriétaire du domaine ne peut demander un tel traitement que dans son enregistrement DMARC ; c'est au destinataire du message de décider s'il souhaite respecter 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 mettre uniquement dans le dossier spam les courriels lorsque la politique du domaine est reject.




Nous recommandons à tous nos clients de commencer par une politique de none, juste pour être en sécurité. Bien que nous soyons confiants dans notre capacité à authentifier correctement votre courrier grâce à la signature DKIM, il est toujours préférable de prendre le temps d'examiner les rapports concernant 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 en publiant un enregistrement DNS TXT à un endroit spécifique dans l’espace de noms DNS, à savoir « _dmarc.nomdedomaine.tld » (notez le soulignement initial). Un enregistrement de politique DMARC basique 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 doivent être envoyés

  • pct=100 est le pourcentage de courriels 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 grand volume 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.




Il existe d'autres options de configuration disponibles pour un propriétaire de domaine à utiliser dans son enregistrement de politique DMARC également, mais les conseils que nous avons fournis devraient constituer un bon début.

Résumé

Il y a beaucoup d'informations à traiter dans le texte 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 l'importance de DMARC vous aide à comprendre pourquoi vous devriez commencer à utiliser cet outil important pour protéger votre réputation par e-mail.




Bien sûr, il ne s'agit pas d'un document complet ou faisant autorité sur le sujet. Si vous souhaitez approfondir ou obtenir plus d'aide, un excellent point de départ est la FAQ officielle sur DMARC. Et, il va sans dire que l'équipe de support Bird est prête à vous aider à configurer votre compte Bird pour DMARC également.




Merci de votre lecture—et commencez à protéger vos domaines avec DMARC dès aujourd'hui !

Rejoignez notre 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.

Rejoignez notre 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.

Rejoignez notre 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.

Pinterest logo
Uber logo
Logo Square
Logo Adobe
Meta logo
logo PayPal

Company

Paramètres de confidentialité

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.

Uber logo
Logo Square
Logo Adobe
Meta logo

Company

Paramètres de confidentialité

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.

Uber logo
Logo Adobe
Meta logo

Reach

Grow

Manage

Automate

Resources

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.