DMARC : Comment protéger votre réputation par email
Oiseau
13 avr. 2016
1 min read
Points Clés
DMARC aide à protéger votre domaine contre le phishing, l'usurpation et l'utilisation non autorisée des emails en publiant vos pratiques d'authentification et en demandant un traitement spécifique pour les messages échoués.
Il fonctionne en parallèle avec SPF et DKIM pour assurer l'alignement des domaines et empêcher le courrier frauduleux de nuire à votre réputation d'expéditeur.
Des politiques DMARC robustes soutiennent une plus grande confiance, un plus grand engagement, et rendent votre domaine prêt pour l'avenir alors que l'écosystème se déplace vers des modèles de réputation basés sur les domaines.
Les vérifications de validation DMARC reposent sur l'alignement du domaine entre le domaine Du, le domaine Return-Path (SPF), et le domaine de signature DKIM.
Configurer DMARC nécessite de recevoir des rapports, de comprendre les données agrégées vs. les données médico-légales, et de configurer des outils pour les analyser.
Vous commencez avec une politique de p=none sécurisée pour surveiller le trafic avant de passer à quarantine ou reject.
Publier un enregistrement DMARC implique de créer une entrée DNS TXT à _dmarc.yourdomain.com avec des politiques, des adresses de rapport et des paramètres optionnels comme le déploiement en pourcentage.
Des boîtes aux lettres de rapport appropriées (agrégées + médico-légales) et des outils d'analyse sont essentiels pour surveiller la conformité, détecter l'usurpation et assurer que l'alignement est correct.
DMARC ne nécessite que un des éléments suivants pour réussir : SPF aligné ou DKIM aligné.
La mise en œuvre de DMARC renforce la sécurité des emails et joue un rôle clé dans l'intégrité de la marque, la confiance, et la délivrabilité à long terme.
Points forts des Q&A
Qu'est-ce que DMARC et pourquoi est-ce important ?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) est une politique publiée dans le DNS qui protège votre domaine contre l'usurpation d'identité et le phishing en appliquant l'alignement du domaine et en permettant la visibilité grâce aux rapports.
Le DMARC est-il un protocole d'authentification ?
Non. DMARC n'est pas une authentification en soi—il s'appuie sur SPF et DKIM pour authentifier le courrier et utilise une politique + des rapports pour contrôler comment les serveurs de réception gèrent les échecs.
Qu'est-ce que DMARC vérifie ?
Il vérifie :
Authentification SPF + alignement
Authentification DKIM + alignement
Un expéditeur a seulement besoin de l'un de ces éléments pour que DMARC réussisse.
Qu'est-ce que « domain alignment » ?
C'est l'exigence selon laquelle le domaine visible De correspond (strict) ou partage le même domaine organisationnel (relâché) avec soit le domaine SPF Return-Path soit le domaine de signature DKIM.
Pourquoi DMARC améliore-t-il la délivrabilité ?
Car les fournisseurs de messagerie font davantage confiance aux domaines authentifiés et alignés. DMARC empêche les messages usurpés de nuire à votre réputation et améliore le placement dans la boîte de réception pour le courrier légitime.
Quelle est la différence entre les rapports DMARC agrégés et les rapports DMARC forensiques?
Rapports agrégés (RUA) : Résumés XML des résultats d'authentification sur l'ensemble du trafic.
Rapports médico-légaux (RUF) : Échantillons individuels de messages échoués pour une analyse approfondie.
Quels mailboxes do I need before publishing DMARC?
Vous devriez créer deux adresses, telles que :
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Cela permet de garder les flux de rapports séparés et plus faciles à analyser.
Quelle politique DMARC devrais-je commencer?
Commencez toujours par p=none. Il surveille l'activité d'authentification sans affecter la livraison, vous permettant d'identifier les problèmes d'alignement et les tentatives de spoofing en toute sécurité.
Quelles sont les politiques DMARC disponibles ?
aucun : surveillance uniquement
quarantaine : envoyer les messages échoués dans le spam
rejeter : bloquer entièrement les messages échoués
Où puis-je publier un enregistrement DMARC ?
Dans votre DNS à :
_dmarc.yourdomain.com
Il doit être un enregistrement TXT spécifiant votre politique, version et points de terminaison de rapport.
À quoi ressemble un enregistrement DMARC basique ?
Exemple :
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
Que se passe-t-il si DMARC échoue ?
Le serveur de réception applique la politique que vous avez demandée (aucune, quarantaine, rejet), bien que le traitement final soit finalement à la discrétion du fournisseur. Une politique stricte peut réduire considérablement les tentatives de phishing utilisant votre domaine.
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 la même phrase que les protocoles d'authentification d'email 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 d'email en :
Annonce des pratiques d'authentification d'email,
Demandant un traitement pour le mail échouant aux vérifications d'authentification, et
Sollicitant des rapports sur le courrier prétendant provenir de son domaine.
DMARC peut être un outil efficace pour nous dans notre lutte contre les mails frauduleux qui ciblent notre nom de domaine (par ex., phishing et usurpation d'identité), et qui peuvent promouvoir une plus grande confiance parmi nos destinataires pour notre courrier. Pour les organisations nécessitant un chiffrement de bout en bout au-delà de l'authentification, la mise en œuvre de S/MIME avec des méthodes efficaces de collecte de clefs publiques des destinataires fournit des couches de sécurité supplémentaires. Cette confiance accrue devrait, à son tour, conduire à un engagement plus élevé avec notre courrier, et le courrier qui est ouvert et génère des clics stimule les ventes et un ROI plus élevé pour nos campagnes d'email.
En plus de protéger notre domaine, nous prévoyons que la mise en œuvre de DMARC maintenant sera un excellent moyen de "préparer notre domaine pour l'avenir." Ici chez Bird, nous croyons que, à mesure que l'industrie passe à l'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 qu'elle 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 d'email et vous donnerons des conseils sur la façon de le configurer pour vos domaines.
Souvent mentionné dans la même phrase que les protocoles d'authentification d'email 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 d'email en :
Annonce des pratiques d'authentification d'email,
Demandant un traitement pour le mail échouant aux vérifications d'authentification, et
Sollicitant des rapports sur le courrier prétendant provenir de son domaine.
DMARC peut être un outil efficace pour nous dans notre lutte contre les mails frauduleux qui ciblent notre nom de domaine (par ex., phishing et usurpation d'identité), et qui peuvent promouvoir une plus grande confiance parmi nos destinataires pour notre courrier. Pour les organisations nécessitant un chiffrement de bout en bout au-delà de l'authentification, la mise en œuvre de S/MIME avec des méthodes efficaces de collecte de clefs publiques des destinataires fournit des couches de sécurité supplémentaires. Cette confiance accrue devrait, à son tour, conduire à un engagement plus élevé avec notre courrier, et le courrier qui est ouvert et génère des clics stimule les ventes et un ROI plus élevé pour nos campagnes d'email.
En plus de protéger notre domaine, nous prévoyons que la mise en œuvre de DMARC maintenant sera un excellent moyen de "préparer notre domaine pour l'avenir." Ici chez Bird, nous croyons que, à mesure que l'industrie passe à l'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 qu'elle 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 d'email et vous donnerons des conseils sur la façon de le configurer pour vos domaines.
Souvent mentionné dans la même phrase que les protocoles d'authentification d'email 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 d'email en :
Annonce des pratiques d'authentification d'email,
Demandant un traitement pour le mail échouant aux vérifications d'authentification, et
Sollicitant des rapports sur le courrier prétendant provenir de son domaine.
DMARC peut être un outil efficace pour nous dans notre lutte contre les mails frauduleux qui ciblent notre nom de domaine (par ex., phishing et usurpation d'identité), et qui peuvent promouvoir une plus grande confiance parmi nos destinataires pour notre courrier. Pour les organisations nécessitant un chiffrement de bout en bout au-delà de l'authentification, la mise en œuvre de S/MIME avec des méthodes efficaces de collecte de clefs publiques des destinataires fournit des couches de sécurité supplémentaires. Cette confiance accrue devrait, à son tour, conduire à un engagement plus élevé avec notre courrier, et le courrier qui est ouvert et génère des clics stimule les ventes et un ROI plus élevé pour nos campagnes d'email.
En plus de protéger notre domaine, nous prévoyons que la mise en œuvre de DMARC maintenant sera un excellent moyen de "préparer notre domaine pour l'avenir." Ici chez Bird, nous croyons que, à mesure que l'industrie passe à l'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 qu'elle 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 d'email et vous donnerons des conseils sur la façon de le configurer pour vos domaines.
Termes à connaître
Avant de commencer à configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons la même langue. Commençons par définir certains termes que nous utiliserons tout au long de ce document.
RFC5322.From Domain
Le RFC5322.FromDomain est la partie domaine de l'adresse email qui est généralement vue par un destinataire de notre email lorsqu'il est lu. Dans l'exemple suivant, le RFC5322.From domaine est "joesbaitshop.com"
De : Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domaine
DKIM est un protocole d'authentification qui permet à un domaine de se porter responsable d'un message de manière à pouvoir être validée par le destinataire du message ; cela se fait par l'utilisation de signatures cryptographiques insérées dans les en-têtes du message lors de sa sortie de son point d'origine. Ces signatures sont effectivement des instantanés de l'aspect du message à ce moment-là et le destinataire 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 est appelé signature DKIM, et le domaine qui se porte responsable du message en le signant insère son nom dans l'en-tête dans une balise clé-valeur comme "d=signingDomain", et il est donc appelé le domaine DKIM d=.
Return-Path Domain
Le domaine Return-Path, parfois appelé le RFC5321. From Domain ou le Mail From domaine, est le domaine auquel les rebonds sont routés ; c'est également 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 visible par le destinataire sauf si le destinataire est suffisamment expérimenté pour regarder tous les en-têtes dans un message donné.
Par défaut, tout le courrier envoyé par bird.com aura birdmail.com comme son domaine Return-Path, comme dans l'exemple suivant :
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Cependant, afin de faire fonctionner DMARC pour votre domaine, vous voudrez profiter d'un domaine de rebond personnalisé, un qui se terminera dans le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lorsque vous utilisez votredomaine.com comme votre domaine d'envoi.
Domaine Organisationnel
Le terme "Domaine Organisationnel" fait référence au domaine qui a été soumis à un registrar 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 existe en deux variantes : "relaxé" et "strict".
Alignement de Domaine Relaxé
Deux domaines sont dits en alignement de domaine relaxé lorsque leurs domaines organisationnels sont les mêmes. Par exemple, a.mail.bird.com et b.foo.bird.com ont un alignement de domaine relaxé 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. D'un autre côté, foo.bird.com et bar.foo.bird.com ne sont qu'en alignement relaxé.
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 relaxé ou strict, selon la politique publiée du domaine d'envoi.
Avant de commencer à configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons la même langue. Commençons par définir certains termes que nous utiliserons tout au long de ce document.
RFC5322.From Domain
Le RFC5322.FromDomain est la partie domaine de l'adresse email qui est généralement vue par un destinataire de notre email lorsqu'il est lu. Dans l'exemple suivant, le RFC5322.From domaine est "joesbaitshop.com"
De : Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domaine
DKIM est un protocole d'authentification qui permet à un domaine de se porter responsable d'un message de manière à pouvoir être validée par le destinataire du message ; cela se fait par l'utilisation de signatures cryptographiques insérées dans les en-têtes du message lors de sa sortie de son point d'origine. Ces signatures sont effectivement des instantanés de l'aspect du message à ce moment-là et le destinataire 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 est appelé signature DKIM, et le domaine qui se porte responsable du message en le signant insère son nom dans l'en-tête dans une balise clé-valeur comme "d=signingDomain", et il est donc appelé le domaine DKIM d=.
Return-Path Domain
Le domaine Return-Path, parfois appelé le RFC5321. From Domain ou le Mail From domaine, est le domaine auquel les rebonds sont routés ; c'est également 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 visible par le destinataire sauf si le destinataire est suffisamment expérimenté pour regarder tous les en-têtes dans un message donné.
Par défaut, tout le courrier envoyé par bird.com aura birdmail.com comme son domaine Return-Path, comme dans l'exemple suivant :
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Cependant, afin de faire fonctionner DMARC pour votre domaine, vous voudrez profiter d'un domaine de rebond personnalisé, un qui se terminera dans le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lorsque vous utilisez votredomaine.com comme votre domaine d'envoi.
Domaine Organisationnel
Le terme "Domaine Organisationnel" fait référence au domaine qui a été soumis à un registrar 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 existe en deux variantes : "relaxé" et "strict".
Alignement de Domaine Relaxé
Deux domaines sont dits en alignement de domaine relaxé lorsque leurs domaines organisationnels sont les mêmes. Par exemple, a.mail.bird.com et b.foo.bird.com ont un alignement de domaine relaxé 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. D'un autre côté, foo.bird.com et bar.foo.bird.com ne sont qu'en alignement relaxé.
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 relaxé ou strict, selon la politique publiée du domaine d'envoi.
Avant de commencer à configurer DMARC pour votre domaine, nous voulons nous assurer que nous parlons la même langue. Commençons par définir certains termes que nous utiliserons tout au long de ce document.
RFC5322.From Domain
Le RFC5322.FromDomain est la partie domaine de l'adresse email qui est généralement vue par un destinataire de notre email lorsqu'il est lu. Dans l'exemple suivant, le RFC5322.From domaine est "joesbaitshop.com"
De : Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domaine
DKIM est un protocole d'authentification qui permet à un domaine de se porter responsable d'un message de manière à pouvoir être validée par le destinataire du message ; cela se fait par l'utilisation de signatures cryptographiques insérées dans les en-têtes du message lors de sa sortie de son point d'origine. Ces signatures sont effectivement des instantanés de l'aspect du message à ce moment-là et le destinataire 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 est appelé signature DKIM, et le domaine qui se porte responsable du message en le signant insère son nom dans l'en-tête dans une balise clé-valeur comme "d=signingDomain", et il est donc appelé le domaine DKIM d=.
Return-Path Domain
Le domaine Return-Path, parfois appelé le RFC5321. From Domain ou le Mail From domaine, est le domaine auquel les rebonds sont routés ; c'est également 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 visible par le destinataire sauf si le destinataire est suffisamment expérimenté pour regarder tous les en-têtes dans un message donné.
Par défaut, tout le courrier envoyé par bird.com aura birdmail.com comme son domaine Return-Path, comme dans l'exemple suivant :
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Cependant, afin de faire fonctionner DMARC pour votre domaine, vous voudrez profiter d'un domaine de rebond personnalisé, un qui se terminera dans le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lorsque vous utilisez votredomaine.com comme votre domaine d'envoi.
Domaine Organisationnel
Le terme "Domaine Organisationnel" fait référence au domaine qui a été soumis à un registrar 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 existe en deux variantes : "relaxé" et "strict".
Alignement de Domaine Relaxé
Deux domaines sont dits en alignement de domaine relaxé lorsque leurs domaines organisationnels sont les mêmes. Par exemple, a.mail.bird.com et b.foo.bird.com ont un alignement de domaine relaxé 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. D'un autre côté, foo.bird.com et bar.foo.bird.com ne sont qu'en alignement relaxé.
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 relaxé 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 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
Rechercher la politique DMARC de ce domaine dans le DNS
Effectuer la validation de la signature DKIM
Effectuer la validation SPF
Vérifier l'alignement du domaine
Appliquer la politique DMARC
Pour qu’un message réussisse la validation DMARC, il doit réussir uniquement 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 les domaines RFC5322.From et Return-Path sont alignés, ou
Le message réussit la validation DKIM et les domaines RFC5322.From et DKIM d= sont alignés, ou
Les deux conditions ci-dessus sont vraies
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
Rechercher la politique DMARC de ce domaine dans le DNS
Effectuer la validation de la signature DKIM
Effectuer la validation SPF
Vérifier l'alignement du domaine
Appliquer la politique DMARC
Pour qu’un message réussisse la validation DMARC, il doit réussir uniquement 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 les domaines RFC5322.From et Return-Path sont alignés, ou
Le message réussit la validation DKIM et les domaines RFC5322.From et DKIM d= sont alignés, ou
Les deux conditions ci-dessus sont vraies
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
Rechercher la politique DMARC de ce domaine dans le DNS
Effectuer la validation de la signature DKIM
Effectuer la validation SPF
Vérifier l'alignement du domaine
Appliquer la politique DMARC
Pour qu’un message réussisse la validation DMARC, il doit réussir uniquement 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 les domaines RFC5322.From et Return-Path sont alignés, ou
Le message réussit la validation DKIM et les domaines RFC5322.From et 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 :
Préparer la réception des rapports DMARC
Décider quelle politique DMARC utiliser pour votre domaine
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.
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 :
Préparer la réception des rapports DMARC
Décider quelle politique DMARC utiliser pour votre domaine
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.
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 :
Préparer la réception des rapports DMARC
Décider quelle politique DMARC utiliser pour votre domaine
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 devrait 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 un courrier prétendant provenir de notre domaine, et nous seront envoyés au moins quotidiennement. Les rapports seront fournis sous deux formats :
Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courrier vue par le rapporteur de chaque source, les résultats de l'authentification, et la manière dont 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, l'audit des flux de messages de notre domaine, et peut-être l'identification des tendances dans les sources de courriels non authentifiés, potentiellement frauduleux.
Rapports médico-légaux, 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 médico-légaux sont censés contenir des en-têtes et des corps de message complets, mais de nombreux rapporteurs retirent ou obscurcissent certaines informations en raison de préoccupations en matière de confidentialité. Néanmoins, le rapport médico-légal peut toujours être utile tant pour le dépannage des problèmes d'authentification de notre domaine que pour identifier, à partir des URI dans les corps de message, les domaines et sites web malveillants utilisés pour tromper les clients de notre propriétaire de domaine.
La préparation à recevoir ces rapports implique tout d'abord la création de 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 la dénomination de la partie locale de la boîte aux lettres ; nous sommes libres de choisir les noms que nous souhaitons, mais gardez les deux séparés pour un traitement plus facile.
Une fois que les noms de boîtes aux lettres sont sélectionnés et créés dans notre domaine, la prochaine étape 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 à nouveau sont conçus pour être analysés par machine, plutôt que lus par un humain. Les rapports médico-légaux, 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 dans le format AFRF et du volume de rapports que nous recevons.
Bien qu'il nous soit possible 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 les outils déjà disponibles pour la tâche.
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 qui effectue une validation DMARC et voit un courrier prétendant provenir de notre domaine, et nous seront envoyés au moins quotidiennement. Les rapports seront fournis sous deux formats :
Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courrier vue par le rapporteur de chaque source, les résultats de l'authentification, et la manière dont 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, l'audit des flux de messages de notre domaine, et peut-être l'identification des tendances dans les sources de courriels non authentifiés, potentiellement frauduleux.
Rapports médico-légaux, 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 médico-légaux sont censés contenir des en-têtes et des corps de message complets, mais de nombreux rapporteurs retirent ou obscurcissent certaines informations en raison de préoccupations en matière de confidentialité. Néanmoins, le rapport médico-légal peut toujours être utile tant pour le dépannage des problèmes d'authentification de notre domaine que pour identifier, à partir des URI dans les corps de message, les domaines et sites web malveillants utilisés pour tromper les clients de notre propriétaire de domaine.
La préparation à recevoir ces rapports implique tout d'abord la création de 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 la dénomination de la partie locale de la boîte aux lettres ; nous sommes libres de choisir les noms que nous souhaitons, mais gardez les deux séparés pour un traitement plus facile.
Une fois que les noms de boîtes aux lettres sont sélectionnés et créés dans notre domaine, la prochaine étape 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 à nouveau sont conçus pour être analysés par machine, plutôt que lus par un humain. Les rapports médico-légaux, 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 dans le format AFRF et du volume de rapports que nous recevons.
Bien qu'il nous soit possible 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 les outils déjà disponibles pour la tâche.
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 qui effectue une validation DMARC et voit un courrier prétendant provenir de notre domaine, et nous seront envoyés au moins quotidiennement. Les rapports seront fournis sous deux formats :
Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courrier vue par le rapporteur de chaque source, les résultats de l'authentification, et la manière dont 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, l'audit des flux de messages de notre domaine, et peut-être l'identification des tendances dans les sources de courriels non authentifiés, potentiellement frauduleux.
Rapports médico-légaux, 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 médico-légaux sont censés contenir des en-têtes et des corps de message complets, mais de nombreux rapporteurs retirent ou obscurcissent certaines informations en raison de préoccupations en matière de confidentialité. Néanmoins, le rapport médico-légal peut toujours être utile tant pour le dépannage des problèmes d'authentification de notre domaine que pour identifier, à partir des URI dans les corps de message, les domaines et sites web malveillants utilisés pour tromper les clients de notre propriétaire de domaine.
La préparation à recevoir ces rapports implique tout d'abord la création de 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 la dénomination de la partie locale de la boîte aux lettres ; nous sommes libres de choisir les noms que nous souhaitons, mais gardez les deux séparés pour un traitement plus facile.
Une fois que les noms de boîtes aux lettres sont sélectionnés et créés dans notre domaine, la prochaine étape 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 à nouveau sont conçus pour être analysés par machine, plutôt que lus par un humain. Les rapports médico-légaux, 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 dans le format AFRF et du volume de rapports que nous recevons.
Bien qu'il nous soit possible 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 les outils déjà disponibles pour la tâche.
Quelle DMARC Policy to Use
La spécification DMARC offre trois choix aux propriétaires de domaines pour spécifier leur traitement préféré du courrier qui échoue aux vérifications de validation DMARC. Ils sont :
aucun, ce qui signifie traiter le courrier de la même manière qu'il serait traité indépendamment des vérifications de validation DMARC
quarantaine, ce qui signifie accepter le courrier mais le placer ailleurs que dans la boîte de réception du destinataire (généralement le dossier spam)
rejeter, 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 ; c'est au destinataire du message de décider s'il respecte 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, par exemple, ne placer dans le dossier spam le courrier que lorsque la politique du domaine est de rejeter.
Nous recommandons à tous nos clients de commencer avec une politique de aucun, simplement pour être en sécurité. Bien que nous soyons confiants dans notre capacité à authentifier correctement votre courrier via la signature DKIM, il est toujours préférable de prendre le temps d'examiner les rapports sur votre domaine avant de devenir plus agressif avec votre politique DMARC.
La spécification DMARC offre trois choix aux propriétaires de domaines pour spécifier leur traitement préféré du courrier qui échoue aux vérifications de validation DMARC. Ils sont :
aucun, ce qui signifie traiter le courrier de la même manière qu'il serait traité indépendamment des vérifications de validation DMARC
quarantaine, ce qui signifie accepter le courrier mais le placer ailleurs que dans la boîte de réception du destinataire (généralement le dossier spam)
rejeter, 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 ; c'est au destinataire du message de décider s'il respecte 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, par exemple, ne placer dans le dossier spam le courrier que lorsque la politique du domaine est de rejeter.
Nous recommandons à tous nos clients de commencer avec une politique de aucun, simplement pour être en sécurité. Bien que nous soyons confiants dans notre capacité à authentifier correctement votre courrier via la signature DKIM, il est toujours préférable de prendre le temps d'examiner les rapports sur votre domaine avant de devenir plus agressif avec votre politique DMARC.
La spécification DMARC offre trois choix aux propriétaires de domaines pour spécifier leur traitement préféré du courrier qui échoue aux vérifications de validation DMARC. Ils sont :
aucun, ce qui signifie traiter le courrier de la même manière qu'il serait traité indépendamment des vérifications de validation DMARC
quarantaine, ce qui signifie accepter le courrier mais le placer ailleurs que dans la boîte de réception du destinataire (généralement le dossier spam)
rejeter, 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 ; c'est au destinataire du message de décider s'il respecte 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, par exemple, ne placer dans le dossier spam le courrier que lorsque la politique du domaine est de rejeter.
Nous recommandons à tous nos clients de commencer avec une politique de aucun, simplement pour être en sécurité. Bien que nous soyons confiants dans notre capacité à authentifier correctement votre courrier via la signature DKIM, il est toujours 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 trait de soulignement en tête). 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étaillant cet enregistrement, nous avons :
v=DMARC1 spécifie la version DMARC (1 est le seul choix pour le moment)
p=none spécifie le traitement préféré, ou 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 criminelle doivent être envoyés
pct=100 est le pourcentage de courrier auquel le propriétaire du domaine souhaite appliquer sa politique. Les domaines qui démarrent avec DMARC, en particulier ceux susceptibles de générer un volume élevé de rapports, peuvent vouloir commencer par un chiffre 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 qu'un propriétaire de domaine utilise dans son enregistrement de politique DMARC également, mais les conseils que nous avons fournis devraient être un bon point de départ.
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 trait de soulignement en tête). 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étaillant cet enregistrement, nous avons :
v=DMARC1 spécifie la version DMARC (1 est le seul choix pour le moment)
p=none spécifie le traitement préféré, ou 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 criminelle doivent être envoyés
pct=100 est le pourcentage de courrier auquel le propriétaire du domaine souhaite appliquer sa politique. Les domaines qui démarrent avec DMARC, en particulier ceux susceptibles de générer un volume élevé de rapports, peuvent vouloir commencer par un chiffre 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 qu'un propriétaire de domaine utilise dans son enregistrement de politique DMARC également, mais les conseils que nous avons fournis devraient être un bon point de départ.
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 trait de soulignement en tête). 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étaillant cet enregistrement, nous avons :
v=DMARC1 spécifie la version DMARC (1 est le seul choix pour le moment)
p=none spécifie le traitement préféré, ou 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 criminelle doivent être envoyés
pct=100 est le pourcentage de courrier auquel le propriétaire du domaine souhaite appliquer sa politique. Les domaines qui démarrent avec DMARC, en particulier ceux susceptibles de générer un volume élevé de rapports, peuvent vouloir commencer par un chiffre 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 qu'un propriétaire de domaine utilise dans son enregistrement de politique DMARC également, mais les conseils que nous avons fournis devraient être un bon point de départ.
Résumé
Il y a beaucoup à déballer dans les informations ci-dessus ! Nous espérons que vous trouvez le guide pour créer un enregistrement de politique DMARC utile. 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 email.
Bien sûr, ce n'est pas un document complet ou autoritaire sur le sujet. Si vous voulez approfondir ou souhaitez 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 Bird est prête à vous aider à configurer votre compte Bird pour DMARC également.
Merci de lire—et commencez à protéger vos domaines avec DMARC aujourd'hui!
Il y a beaucoup à déballer dans les informations ci-dessus ! Nous espérons que vous trouvez le guide pour créer un enregistrement de politique DMARC utile. 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 email.
Bien sûr, ce n'est pas un document complet ou autoritaire sur le sujet. Si vous voulez approfondir ou souhaitez 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 Bird est prête à vous aider à configurer votre compte Bird pour DMARC également.
Merci de lire—et commencez à protéger vos domaines avec DMARC aujourd'hui!
Il y a beaucoup à déballer dans les informations ci-dessus ! Nous espérons que vous trouvez le guide pour créer un enregistrement de politique DMARC utile. 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 email.
Bien sûr, ce n'est pas un document complet ou autoritaire sur le sujet. Si vous voulez approfondir ou souhaitez 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 Bird est prête à vous aider à configurer votre compte Bird pour DMARC également.
Merci de lire—et commencez à protéger vos domaines avec DMARC aujourd'hui!
