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 pour utiliser DMARC afin de protéger votre réputation par e-mail, et nous vous donnerons des conseils sur la façon de le configurer pour vos domaines.
Dans cet article, nous vous dirons tout ce que vous devez savoir pour utiliser DMARC afin de protéger votre réputation par e-mail, et nous vous donnerons des conseils sur la façon de le configurer pour vos domaines.
Dans cet article, nous vous dirons tout ce que vous devez savoir pour utiliser DMARC afin de protéger votre réputation par e-mail, et nous vous donnerons des conseils sur la façon de le configurer pour vos domaines.
Un outil efficace pour combattre le courrier frauduleux
Souvent mentionné dans le même souffle que les protocoles d'authentification 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 email en:
Annonce des pratiques d'authentification des emails,
Demande de traitement pour les emails qui échouent aux vérifications d'authentification, et
Demande de rapports sur le courrier prétendant provenir de son domaine.
DMARC peut être un outil efficace pour nous dans notre lutte contre les courriels frauduleux qui ciblent notre nom de domaine (par exemple, phishing et usurpation d'identité), et qui peut 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, mettre en œuvre S/MIME avec des méthodes efficaces de collecte de clés publiques des destinataires fournit des couches de sécurité supplémentaires. Cette confiance accrue devrait, en retour, mener à un engagement accru avec notre courrier, et le courrier qui est ouvert et génère des clics stimule les ventes et un retour sur investissement plus élevé pour nos campagnes email.
En plus de protéger notre domaine, nous prévoyons que la mise en œuvre de DMARC maintenant sera un excellent moyen de « protéger l'avenir » de notre domaine. Ici chez Bird, nous croyons que, alors 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, en concert avec DKIM et SPF, aidera les domaines à établir une réputation basée sur le domaine bien avant qu'elle ne devienne absolument nécessaire.
Dans cet article, nous vous dirons tout ce que vous devez savoir sur l'exploitation de DMARC pour protéger votre réputation email et vous donnerons des indications sur la façon de le configurer pour vos domaines.
Souvent mentionné dans le même souffle que les protocoles d'authentification 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 email en:
Annonce des pratiques d'authentification des emails,
Demande de traitement pour les emails qui échouent aux vérifications d'authentification, et
Demande de rapports sur le courrier prétendant provenir de son domaine.
DMARC peut être un outil efficace pour nous dans notre lutte contre les courriels frauduleux qui ciblent notre nom de domaine (par exemple, phishing et usurpation d'identité), et qui peut 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, mettre en œuvre S/MIME avec des méthodes efficaces de collecte de clés publiques des destinataires fournit des couches de sécurité supplémentaires. Cette confiance accrue devrait, en retour, mener à un engagement accru avec notre courrier, et le courrier qui est ouvert et génère des clics stimule les ventes et un retour sur investissement plus élevé pour nos campagnes email.
En plus de protéger notre domaine, nous prévoyons que la mise en œuvre de DMARC maintenant sera un excellent moyen de « protéger l'avenir » de notre domaine. Ici chez Bird, nous croyons que, alors 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, en concert avec DKIM et SPF, aidera les domaines à établir une réputation basée sur le domaine bien avant qu'elle ne devienne absolument nécessaire.
Dans cet article, nous vous dirons tout ce que vous devez savoir sur l'exploitation de DMARC pour protéger votre réputation email et vous donnerons des indications sur la façon de le configurer pour vos domaines.
Souvent mentionné dans le même souffle que les protocoles d'authentification 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 email en:
Annonce des pratiques d'authentification des emails,
Demande de traitement pour les emails qui échouent aux vérifications d'authentification, et
Demande de rapports sur le courrier prétendant provenir de son domaine.
DMARC peut être un outil efficace pour nous dans notre lutte contre les courriels frauduleux qui ciblent notre nom de domaine (par exemple, phishing et usurpation d'identité), et qui peut 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, mettre en œuvre S/MIME avec des méthodes efficaces de collecte de clés publiques des destinataires fournit des couches de sécurité supplémentaires. Cette confiance accrue devrait, en retour, mener à un engagement accru avec notre courrier, et le courrier qui est ouvert et génère des clics stimule les ventes et un retour sur investissement plus élevé pour nos campagnes email.
En plus de protéger notre domaine, nous prévoyons que la mise en œuvre de DMARC maintenant sera un excellent moyen de « protéger l'avenir » de notre domaine. Ici chez Bird, nous croyons que, alors 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, en concert avec DKIM et SPF, aidera les domaines à établir une réputation basée sur le domaine bien avant qu'elle ne devienne absolument nécessaire.
Dans cet article, nous vous dirons tout ce que vous devez savoir sur l'exploitation de DMARC pour protéger votre réputation email et vous donnerons des indications sur la façon de le configurer pour vos domaines.
Terms to Know
Avant de 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 allons utiliser tout au long de ce document.
RFC5322.From Domain
Le RFC5322.FromDomain est la partie domaine de l'adresse e-mail généralement vue par le destinataire de notre e-mail lorsqu'il est lu. Dans l'exemple suivant, le domaine RFC5322.From est « joesbaitshop.com »
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
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 grâce à des 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 assume 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=.
Return-Path Domain
Le domaine Return-Path, parfois appelé le RFC5321.From Domain ou le domaine Mail From, est le domaine vers lequel sont routés les rebonds; c'est aussi le domaine sur lequel les vérifications SPF sont effectuées au cours de la transaction e-mail. Ce domaine n'est généralement pas vu par le destinataire à moins que le destinataire ne soit suffisamment averti 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é, qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lorsque vous utilisez votredomaine.com comme votre domaine d'envoi.
Organizational Domain
Le terme « Organizational Domain » se réfère au domaine qui a été soumis à un registraire pour créer la présence du domaine sur Internet. Pour Bird, nos domaines organisationnels sont bird.com et birdmail.com.
Domain Alignment
Le dernier terme à comprendre concernant DMARC est « Alignement de Domaine », et il existe en deux variantes : « relâché » et « strict ».
Relaxed Domain Alignment
Deux domaines sont dits avoir un alignement de domaine relâché lorsque leurs domaines organisationnels sont les mêmes. 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.
Strict Domain Alignment
Deux domaines sont dits être 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'autre part, foo.bird.com et bar.foo.bird.com sont seulement en alignement relâché.
DMARC Domain Alignment Requirements
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, basé sur 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 certains termes que nous allons utiliser tout au long de ce document.
RFC5322.From Domain
Le RFC5322.FromDomain est la partie domaine de l'adresse e-mail généralement vue par le destinataire de notre e-mail lorsqu'il est lu. Dans l'exemple suivant, le domaine RFC5322.From est « joesbaitshop.com »
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
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 grâce à des 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 assume 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=.
Return-Path Domain
Le domaine Return-Path, parfois appelé le RFC5321.From Domain ou le domaine Mail From, est le domaine vers lequel sont routés les rebonds; c'est aussi le domaine sur lequel les vérifications SPF sont effectuées au cours de la transaction e-mail. Ce domaine n'est généralement pas vu par le destinataire à moins que le destinataire ne soit suffisamment averti 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é, qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lorsque vous utilisez votredomaine.com comme votre domaine d'envoi.
Organizational Domain
Le terme « Organizational Domain » se réfère au domaine qui a été soumis à un registraire pour créer la présence du domaine sur Internet. Pour Bird, nos domaines organisationnels sont bird.com et birdmail.com.
Domain Alignment
Le dernier terme à comprendre concernant DMARC est « Alignement de Domaine », et il existe en deux variantes : « relâché » et « strict ».
Relaxed Domain Alignment
Deux domaines sont dits avoir un alignement de domaine relâché lorsque leurs domaines organisationnels sont les mêmes. 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.
Strict Domain Alignment
Deux domaines sont dits être 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'autre part, foo.bird.com et bar.foo.bird.com sont seulement en alignement relâché.
DMARC Domain Alignment Requirements
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, basé sur 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 certains termes que nous allons utiliser tout au long de ce document.
RFC5322.From Domain
Le RFC5322.FromDomain est la partie domaine de l'adresse e-mail généralement vue par le destinataire de notre e-mail lorsqu'il est lu. Dans l'exemple suivant, le domaine RFC5322.From est « joesbaitshop.com »
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
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 grâce à des 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 assume 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=.
Return-Path Domain
Le domaine Return-Path, parfois appelé le RFC5321.From Domain ou le domaine Mail From, est le domaine vers lequel sont routés les rebonds; c'est aussi le domaine sur lequel les vérifications SPF sont effectuées au cours de la transaction e-mail. Ce domaine n'est généralement pas vu par le destinataire à moins que le destinataire ne soit suffisamment averti 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é, qui se terminera par le même domaine que votre domaine d'envoi, par exemple, bounces.votredomaine.com lorsque vous utilisez votredomaine.com comme votre domaine d'envoi.
Organizational Domain
Le terme « Organizational Domain » se réfère au domaine qui a été soumis à un registraire pour créer la présence du domaine sur Internet. Pour Bird, nos domaines organisationnels sont bird.com et birdmail.com.
Domain Alignment
Le dernier terme à comprendre concernant DMARC est « Alignement de Domaine », et il existe en deux variantes : « relâché » et « strict ».
Relaxed Domain Alignment
Deux domaines sont dits avoir un alignement de domaine relâché lorsque leurs domaines organisationnels sont les mêmes. 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.
Strict Domain Alignment
Deux domaines sont dits être 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'autre part, foo.bird.com et bar.foo.bird.com sont seulement en alignement relâché.
DMARC Domain Alignment Requirements
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, basé sur la politique publiée du domaine d'envoi.
Comment DMARC fonctionne pour protéger votre réputation email
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 des domaines
Appliquer la politique DMARC
Pour qu'un message réussisse la validation DMARC, il doit passer une seule des deux vérifications d'authentification et d'alignement. Ainsi, un message réussira la validation DMARC si l'une des conditions suivantes est vraie :
Le message passe les contrôles SPF et les domaines RFC5322.From et Return-Path sont alignés, ou
Le message passe la validation DKIM et les domaines RFC5322.From et DKIM d= sont alignés, ou
Les deux conditions ci-dessus sont vraies
Aperçu des chemins de validation DMARC
Chemin d'authentification | Domaines comparés | Alignement requis | Condition de passage DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relâché ou strict | SPF réussi et les domaines sont alignés |
DKIM | RFC5322.From ↔ DKIM d= | Relâché ou strict | DKIM réussi et les domaines sont alignés |
SPF + DKIM | Les deux ci-dessus | Soit aligné | Un ou les deux contrôles alignés réussissent |
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 des domaines
Appliquer la politique DMARC
Pour qu'un message réussisse la validation DMARC, il doit passer une seule des deux vérifications d'authentification et d'alignement. Ainsi, un message réussira la validation DMARC si l'une des conditions suivantes est vraie :
Le message passe les contrôles SPF et les domaines RFC5322.From et Return-Path sont alignés, ou
Le message passe la validation DKIM et les domaines RFC5322.From et DKIM d= sont alignés, ou
Les deux conditions ci-dessus sont vraies
Aperçu des chemins de validation DMARC
Chemin d'authentification | Domaines comparés | Alignement requis | Condition de passage DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relâché ou strict | SPF réussi et les domaines sont alignés |
DKIM | RFC5322.From ↔ DKIM d= | Relâché ou strict | DKIM réussi et les domaines sont alignés |
SPF + DKIM | Les deux ci-dessus | Soit aligné | Un ou les deux contrôles alignés réussissent |
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 des domaines
Appliquer la politique DMARC
Pour qu'un message réussisse la validation DMARC, il doit passer une seule des deux vérifications d'authentification et d'alignement. Ainsi, un message réussira la validation DMARC si l'une des conditions suivantes est vraie :
Le message passe les contrôles SPF et les domaines RFC5322.From et Return-Path sont alignés, ou
Le message passe la validation DKIM et les domaines RFC5322.From et DKIM d= sont alignés, ou
Les deux conditions ci-dessus sont vraies
Aperçu des chemins de validation DMARC
Chemin d'authentification | Domaines comparés | Alignement requis | Condition de passage DMARC |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Relâché ou strict | SPF réussi et les domaines sont alignés |
DKIM | RFC5322.From ↔ DKIM d= | Relâché ou strict | DKIM réussi et les domaines sont alignés |
SPF + DKIM | Les deux ci-dessus | Soit aligné | Un ou les deux contrôles alignés réussissent |
Faire fonctionner DMARC pour votre domaine
Maintenant que nous avons expliqué la mécanique de DMARC, parlons de comment faire fonctionner DMARC pour nous, ce qui implique les trois étapes suivantes :
Préparations pour recevoir des rapports DMARC
Décider de la politique DMARC à utiliser pour votre domaine
Publier votre enregistrement DMARC
Nous examinerons chacun de ces éléments en détail ci-dessous, mais nous vous dirons directement que l'étape 1 ci-dessus consommera environ 95 % de votre temps de préparation.
Maintenant que nous avons expliqué la mécanique de DMARC, parlons de comment faire fonctionner DMARC pour nous, ce qui implique les trois étapes suivantes :
Préparations pour recevoir des rapports DMARC
Décider de la politique DMARC à utiliser pour votre domaine
Publier votre enregistrement DMARC
Nous examinerons chacun de ces éléments en détail ci-dessous, mais nous vous dirons directement que l'étape 1 ci-dessus consommera environ 95 % de votre temps de préparation.
Maintenant que nous avons expliqué la mécanique de DMARC, parlons de comment faire fonctionner DMARC pour nous, ce qui implique les trois étapes suivantes :
Préparations pour recevoir des rapports DMARC
Décider de la politique DMARC à utiliser pour votre domaine
Publier votre enregistrement DMARC
Nous examinerons chacun de ces éléments en détail ci-dessous, mais nous vous dirons directement que l'étape 1 ci-dessus consommera environ 95 % de votre temps de préparation.
Préparation à Recevoir les 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 un courrier prétendant provenir de notre domaine, et ils nous seront envoyés au moins quotidiennement. Les rapports seront présentés sous deux formats :
Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courrier observée par le rapporteur pour 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 machine, avec leurs données stockées quelque part pour permettre une analyse globale du trafic, un audit des flux de messages de notre domaine et peut-être l'identification de tendances dans les sources d'e-mails non authentifiés, potentiellement frauduleux.
Rapports judiciaires, qui sont des copies individuelles de messages ayant échoué à l'authentification, chacun étant inclus dans un message électronique complet utilisant un format appelé AFRF. Les rapports judiciaires sont censés contenir des en-têtes complets et des corps de message, mais de nombreux rapporteurs suppriment ou masquent certaines informations pour des raisons de confidentialité. Néanmoins, le rapport judiciaire peut toujours être utile à la fois pour dépanner les problèmes d'authentification de notre domaine et pour identifier, à partir des URI dans les corps des messages, des domaines et sites Web 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 la création de deux boîtes aux lettres dans notre domaine pour gérer ces rapports, comme agg_reports@nondedomaine.com et afrf_reports@nondedomaine.com. Notez que ces noms de boîtes aux lettres sont complètement arbitraires, et il n'y a aucune exigence quant à 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ées pour un traitement plus facile.
Une fois les noms de boîtes aux lettres sélectionnés et créés dans notre domaine, la prochaine chose à faire ici est de mettre en place des outils pour lire ces boîtes aux lettres et exploiter les données, en particulier les rapports de données agrégées, qui sont encore une fois conçus pour être analysés par machine, plutôt que lus par un humain. Les rapports judiciaires, en revanche, peuvent être gérables simplement en les lisant nous-mêmes, mais notre capacité à le faire dépendra à la fois de la compréhension par notre client de messagerie de la façon d'afficher les messages au format AFRF et du volume de rapports que nous recevons.
Bien qu'il nous soit possible d'écrire nos propres outils pour traiter les rapports DMARC, jusqu'à ce que Bird fournisse de tels services aux 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.
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 un courrier prétendant provenir de notre domaine, et ils nous seront envoyés au moins quotidiennement. Les rapports seront présentés sous deux formats :
Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courrier observée par le rapporteur pour 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 machine, avec leurs données stockées quelque part pour permettre une analyse globale du trafic, un audit des flux de messages de notre domaine et peut-être l'identification de tendances dans les sources d'e-mails non authentifiés, potentiellement frauduleux.
Rapports judiciaires, qui sont des copies individuelles de messages ayant échoué à l'authentification, chacun étant inclus dans un message électronique complet utilisant un format appelé AFRF. Les rapports judiciaires sont censés contenir des en-têtes complets et des corps de message, mais de nombreux rapporteurs suppriment ou masquent certaines informations pour des raisons de confidentialité. Néanmoins, le rapport judiciaire peut toujours être utile à la fois pour dépanner les problèmes d'authentification de notre domaine et pour identifier, à partir des URI dans les corps des messages, des domaines et sites Web 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 la création de deux boîtes aux lettres dans notre domaine pour gérer ces rapports, comme agg_reports@nondedomaine.com et afrf_reports@nondedomaine.com. Notez que ces noms de boîtes aux lettres sont complètement arbitraires, et il n'y a aucune exigence quant à 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ées pour un traitement plus facile.
Une fois les noms de boîtes aux lettres sélectionnés et créés dans notre domaine, la prochaine chose à faire ici est de mettre en place des outils pour lire ces boîtes aux lettres et exploiter les données, en particulier les rapports de données agrégées, qui sont encore une fois conçus pour être analysés par machine, plutôt que lus par un humain. Les rapports judiciaires, en revanche, peuvent être gérables simplement en les lisant nous-mêmes, mais notre capacité à le faire dépendra à la fois de la compréhension par notre client de messagerie de la façon d'afficher les messages au format AFRF et du volume de rapports que nous recevons.
Bien qu'il nous soit possible d'écrire nos propres outils pour traiter les rapports DMARC, jusqu'à ce que Bird fournisse de tels services aux 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.
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 un courrier prétendant provenir de notre domaine, et ils nous seront envoyés au moins quotidiennement. Les rapports seront présentés sous deux formats :
Rapports agrégés, qui sont des documents XML montrant des données statistiques sur la quantité de courrier observée par le rapporteur pour 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 machine, avec leurs données stockées quelque part pour permettre une analyse globale du trafic, un audit des flux de messages de notre domaine et peut-être l'identification de tendances dans les sources d'e-mails non authentifiés, potentiellement frauduleux.
Rapports judiciaires, qui sont des copies individuelles de messages ayant échoué à l'authentification, chacun étant inclus dans un message électronique complet utilisant un format appelé AFRF. Les rapports judiciaires sont censés contenir des en-têtes complets et des corps de message, mais de nombreux rapporteurs suppriment ou masquent certaines informations pour des raisons de confidentialité. Néanmoins, le rapport judiciaire peut toujours être utile à la fois pour dépanner les problèmes d'authentification de notre domaine et pour identifier, à partir des URI dans les corps des messages, des domaines et sites Web 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 la création de deux boîtes aux lettres dans notre domaine pour gérer ces rapports, comme agg_reports@nondedomaine.com et afrf_reports@nondedomaine.com. Notez que ces noms de boîtes aux lettres sont complètement arbitraires, et il n'y a aucune exigence quant à 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ées pour un traitement plus facile.
Une fois les noms de boîtes aux lettres sélectionnés et créés dans notre domaine, la prochaine chose à faire ici est de mettre en place des outils pour lire ces boîtes aux lettres et exploiter les données, en particulier les rapports de données agrégées, qui sont encore une fois conçus pour être analysés par machine, plutôt que lus par un humain. Les rapports judiciaires, en revanche, peuvent être gérables simplement en les lisant nous-mêmes, mais notre capacité à le faire dépendra à la fois de la compréhension par notre client de messagerie de la façon d'afficher les messages au format AFRF et du volume de rapports que nous recevons.
Bien qu'il nous soit possible d'écrire nos propres outils pour traiter les rapports DMARC, jusqu'à ce que Bird fournisse de tels services aux 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 utiliser
La spécification DMARC offre trois choix aux propriétaires de domaine pour spécifier le traitement préféré du courrier qui échoue aux contrôles 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 contrôles de validation DMARC
quarantine, 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)
reject, ce qui signifie rejeter le message complètement
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, comme ne mettre le courrier en 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 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 domaine pour spécifier le traitement préféré du courrier qui échoue aux contrôles 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 contrôles de validation DMARC
quarantine, 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)
reject, ce qui signifie rejeter le message complètement
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, comme ne mettre le courrier en 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 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 domaine pour spécifier le traitement préféré du courrier qui échoue aux contrôles 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 contrôles de validation DMARC
quarantine, 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)
reject, ce qui signifie rejeter le message complètement
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, comme ne mettre le courrier en 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 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.
Publier 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.nomdedomaine.tld » (notez le soulignement initial). Un enregistrement de politique DMARC de base pour notre domaine 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 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 de médecine légale doivent être envoyés
pct=100 est le pourcentage de courrier auquel le propriétaire du domaine aimerait que sa politique soit appliquée. Les domaines débutant 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.
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 être un bon début.
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.nomdedomaine.tld » (notez le soulignement initial). Un enregistrement de politique DMARC de base pour notre domaine 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 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 de médecine légale doivent être envoyés
pct=100 est le pourcentage de courrier auquel le propriétaire du domaine aimerait que sa politique soit appliquée. Les domaines débutant 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.
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 être un bon début.
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.nomdedomaine.tld » (notez le soulignement initial). Un enregistrement de politique DMARC de base pour notre domaine 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 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 de médecine légale doivent être envoyés
pct=100 est le pourcentage de courrier auquel le propriétaire du domaine aimerait que sa politique soit appliquée. Les domaines débutant 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.
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 être un bon début.
Résumé
Il y a beaucoup à déballer dans les informations ci-dessus ! Nous espérons que vous trouvez utile le guide pour créer un enregistrement de politique DMARC. Nous espérons également que notre explication sur l'importance du DMARC clarifie pourquoi vous devriez commencer à utiliser cet outil important pour protéger votre réputation d'email.
Bien sûr, ce n'est pas un document complet ou officiel 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 DMARC. Et, il va sans dire que l'équipe de support de MessageBird est prête à vous aider à configurer votre compte MessageBird pour DMARC également.
Merci de votre lecture—et commencez à protéger vos domaines avec DMARC dès aujourd'hui !
Il y a beaucoup à déballer dans les informations ci-dessus ! Nous espérons que vous trouvez utile le guide pour créer un enregistrement de politique DMARC. Nous espérons également que notre explication sur l'importance du DMARC clarifie pourquoi vous devriez commencer à utiliser cet outil important pour protéger votre réputation d'email.
Bien sûr, ce n'est pas un document complet ou officiel 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 DMARC. Et, il va sans dire que l'équipe de support de MessageBird est prête à vous aider à configurer votre compte MessageBird pour DMARC également.
Merci de votre lecture—et commencez à protéger vos domaines avec DMARC dès aujourd'hui !
Il y a beaucoup à déballer dans les informations ci-dessus ! Nous espérons que vous trouvez utile le guide pour créer un enregistrement de politique DMARC. Nous espérons également que notre explication sur l'importance du DMARC clarifie pourquoi vous devriez commencer à utiliser cet outil important pour protéger votre réputation d'email.
Bien sûr, ce n'est pas un document complet ou officiel 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 DMARC. Et, il va sans dire que l'équipe de support de MessageBird est prête à vous aider à configurer votre compte MessageBird pour DMARC également.
Merci de votre lecture—et commencez à protéger vos domaines avec DMARC dès aujourd'hui !
