Domain-based Message Authentication, Reporting & Conformance (DMARC) est une spécification conçue pour aider à réduire les abus de messages électroniques, tels que les messages entrants de spam et de phishing qui présentent faussement leur origine dans l'en-tête FROM : du message. DMARC permet aux propriétaires de domaines d'utiliser le système de noms de domaines (DNS) pour informer les serveurs de réception de leur politique DMARC, c'est-à-dire de la manière dont ils souhaitent que ces serveurs traitent les messages censés provenir de leur domaine mais dont l'origine ne peut être authentifiée. Cette politique, qui est récupérée par le serveur de réception via une requête DNS lors du traitement du message entrant, peut indiquer que le serveur doit mettre en quarantaine ou rejeter les messages qui ne sont pas conformes à la politique, ou ne prendre aucune mesure (c'est-à-dire laisser le message se dérouler normalement). Dans l'enregistrement DNS DMARC du domaine, on peut également demander au serveur d'envoyer à certains des rapports DMARC indiquant le nombre de messages entrants censés provenir de ce domaine et précisant si l'authentification a été réussie ou échouée, avec des détails sur les échecs. Les fonctions de rapport DMARC peuvent être utiles pour déterminer l'efficacité de vos procédures d'authentification du courrier électronique et la fréquence à laquelle votre nom de domaine est utilisé dans des messages falsifiés.
Dans la section Authentification de l'expéditeur de la boîte de dialogue Paramètres de sécurité, trois écrans permettent de configurer les fonctions de vérification et de rapport DMARC de MDaemon : Vérification DMARC, Rapports DMARC et Paramètres de rapports DMARC.
Vérification DMARC
Dans le cadre du processus de vérification DMARC, MDaemon effectue une requête DNS DMARC sur le domaine figurant dans l' en-tête FROM : de chaque message entrant. Cela permet de déterminer si le domaine utilise ou non DMARC et, si c'est le cas, de récupérer son enregistrement DNS DMARC, qui contient sa politique et d'autres informations relatives à DMARC. En outre, DMARC utilise SPF et DKIM pour valider chaque message et exige qu'il réussisse au moins l'un de ces tests pour passer la vérification DMARC. Si le message passe avec succès, il sera acheminé normalement par le reste des processus de distribution et de filtrage de MDaemon. Si le message échoue, son sort est déterminé par la politique DMARC du domaine et par la façon dont vous avez configuré MDaemon pour traiter ces messages.
Si un message échoue à la vérification DMARC et que le domaine DMARC a une politique "p=none", aucune mesure punitive ne sera prise et le traitement normal des messages se poursuivra. Inversement, lorsque le domaine DMARC a une politique restrictive de"p=quarantine" ou "p=reject", MDaemon peut optionnellement filtrer le message automatiquement dans la liste de "spam" (c'est-à-dire de courrier indésirable) de l'utilisateur destinataire. Dossier de courrier indésirable ( spam)de l'utilisateur destinataire .Vous pouvez également choisir de demander à MDaemon de rejeter complètement le message lorsque le domaine utilise la stratégie"p=reject". De plus, pour les messages ayant échoué et dont la politique est restrictive, MDaemon insère l'en-tête "X-MDDMARC-Fail-policy : quarantine" ou "X-MDDMARC-Fail-policy : reject", en fonction de la politique. Cela vous permet d'utiliser le Filtre de contenu pour effectuer une action basée sur la présence de ces en-têtes, telle que l'envoi du message dans un dossier spécifique pour un examen plus approfondi.
La vérification DMARC est activée par défaut et recommandée dans la plupart des configurations de MDaemon.
Rapport DMARC
Lorsque MDaemon signale au DNS un enregistrement DMARC, celui-ci peut contenir des balises indiquant que le propriétaire du domaine souhaite recevoir des rapports d'échec ou d'agrégation DMARC concernant les messages prétendant provenir de ce domaine. Les options de l'écran DMARC Report permettent d'indiquer si l'on souhaite ou non envoyer les types de rapports demandés et de spécifier les Métadonnées du rapportARC que ces rapports doivent contenir. Les rapports globaux sont envoyés quotidiennement à minuit UTC et les rapports d'échec sont envoyés par message, au fur et à mesure que se produit l'incident qui déclenche le rapport. Les rapports sont toujours envoyés sous forme de fichiers XML zippés, et plusieurs outils d'analyse sont disponibles en ligne pour permettre aux destinataires de les consulter facilement.
Par défaut, MDaemon n'envoie pas de rapports globaux ou de rapports d'échec. Si vous souhaitez envoyer l'un ou l'autre type de rapport, activez les options correspondantes dans l'écran Rapports DMARC.
Paramètres DMARC
L'écran Paramètres DMARC contient diverses options permettant d'inclure certaines informations dans les rapports DKIM, de journaliser les enregistrements DNS DMARC et de mettre à jour le fichier de suffixes publics utilisé par MDaemon pour DMARC.
Vérification DMARC et listes de diffusion
Dans la mesure où l'objectif de DMARC est de s'assurer que le domaine figurant dans l' en-tête FROM :d'un message n 'a pas été falsifié, le serveur d'envoi doit être autorisé à envoyer des messages au nom de ce domaine. Cela peut poser un problème particulier pour les listes de diffusion, car il est courant que les listes distribuent des messages au nom de leurs membres à partir de domaines extérieurs, tout en laissant l'en-tête From : inchangé. Cela signifie que lorsqu'un serveur récepteur tente d'utiliser la vérification DMARC pour l'un de ces messages, le message aura été envoyé par un serveur qui n'est pas officiellement affilié au domaine de l'en-tête From :. Si le domaine DMARC utilise une politique DMARC restrictive, le message peut être mis en quarantaine ou même rejeté par le serveur destinataire. Dans certains cas, le destinataire peut également être retiré de la liste. Pour contourner ce problème, lorsque MDaemon constate qu'un message destiné à une liste provient d'un domaine soumis à une politique DMARC restrictive, il remplace l' en-tête From : du message par l'adresse de la liste de diffusion. Vous pouvez également configurer MDaemon pour qu'il refuse d'accepter tout message destiné à une liste et provenant d'un domaine soumis à une politique restrictive. Cette dernière option rendrait impossible l'envoi d'un message à la liste par un utilisateur d'un domaine ayant une politique restrictive. L'option de remplacement de l' en-tête From : se trouve dans l'écran Headers de l'éditeur de listes de diffusion . L'option de rejet des messages se trouve dans l' écranParamètres.
Utiliser DMARC pour vos domaines MDaemon
Si vous souhaitez utiliser DMARC pour l'un de vos domaines, c'est-à-dire si vous voulez que les serveurs de messagerie qui prennent en charge DMARC utilisent DMARC pour vérifier les messages qui prétendent provenir de vous, vous devez d'abord vous assurer que vous avez créé des enregistrements DNS SPF et DKIM correctement formatés pour le domaine ; au moins l'une de ces options doit fonctionner correctement pour utiliser DMARC. Si vous utilisez DKIM, vous devez également configurer les Options DKIM Signing deMDaemon pour signer les messages du domaine. En outre, vous devez créer un enregistrement DNS DMARC pour le domaine. En interrogeant le DNS pour cet enregistrementTXT spécialement formaté , le serveur de réception peut déterminer votre politique DMARC et divers paramètres facultatifs tels que : le mode d'authentification que vous utilisez, si vous souhaitez ou non recevoir des rapports globaux, l'adresse électronique à laquelle les rapports doivent être envoyés, et d'autres encore.
Une fois que vous avez correctement configuré DMARC et que vous avez commencé à recevoir des rapports DMARC XML, il existe une variété d'outils en ligne que vous pouvez utiliser pour lire ces rapports et diagnostiquer tout problème potentiel. Pour vous faciliter la tâche, un outil DMARC Reporter vous est également fourni dans le dossier \MDaemon\App\. Voir DMARCReporterReadMe.txt pour savoir comment l'utiliser.
Définition d'un enregistrement de ressource DMARC TXT
Ce qui suit est une vue d'ensemble des composants les plus élémentaires et les plus couramment utilisés d'un enregistrement DMARC. Pour des informations plus détaillées, ou pour des informations sur des configurations plus avancées, voir : www.dmarc.org.
Champ À : le propriétaire
Le champ Propriétaire (également appelé "Nom" ou "gauche") de l'enregistrement de ressource DMARC doit toujours être _dmarc, ou il peut prendre la forme _dmarc.domain.name si vous souhaitez spécifier le domaine ou le sous-domaine auquel l'enregistrement s'applique.
Exemple :
Enregistrement DMARC pour le domaine example.com
_dmarc IN TXT "v=DMARC1;p=none"
Cet enregistrement s'appliquerait aux courriels provenant de user@example.com ou de tout sous-domaine de example.com, comme user@support.example.com, user@mail.support.example.com, etc.
_dmarc.support.example.com IN TXT "v=DMARC1;p=none"
Cet enregistrement ne s'appliquerait qu'aux courriels provenant de user@support.example.com, et non à ceux provenant, par exemple, de user@example.com.
_dmarc.support IN TXT "v=DMARC1;p=none"
Cet enregistrement s'applique aux courriels provenant de : user@support.example.com, user@a.support.example.com, user@a.b.support.example.com, et ainsi de suite.
Balises et valeurs des enregistrements DMARC
Balises requises
Balise |
Valeur |
Notes |
v= |
DMARC1 |
Dans est la balise Version, qui doit être la première balise dans la partie texte spécifique à DMARC de l'enregistrement. Bien que les valeurs des autres balises DMARC ne soient pas sensibles à la casse, la valeur de la balise v= doit être en majuscules : DMARC1. Exemple : _dmarc IN TXT "v=DMARC1;p=none" |
p= |
aucun quarantaine rejet |
Dans ce cas, il s'agit de la balise Policy, qui doit être la deuxième balise de l'enregistrement DMARC, après la balisev=. p=none signifie que le serveur de réception ne doit prendre aucune mesure en fonction des résultats de la requête DMARC. Les messages qui échouent au contrôle DMARC ne doivent pas être mis en quarantaine ou rejetés sur la base de cet échec. Ils peuvent encore être mis en quarantaine ou rejetés pour d'autres raisons, par exemple parce qu'ils ont échoué aux tests du filtre anti-spam ou à d'autres contrôles de sécurité sans rapport avec DMARC. L'utilisation de p=none est parfois appelée "surveillance" ou "mode surveillance" parce que vous pouvez l'utiliser avec la balise rua= pour recevoir des rapports globaux des domaines destinataires concernant vos messages, mais ces messages ne seront pas pénalisés par les domaines parce qu'ils n'ont pas passé le contrôle DMARC. C'est la politique à utiliser jusqu'à ce que vous ayez testé à fond votre implémentation DMARC et que vous soyez sûr d'être prêt à passer à la politique plus restrictive p=quarantine. p=quarantine est la stratégie à utiliser lorsque vous souhaitez que les autres serveurs de messagerie traitent un message comme suspect lorsque son en-tête FROM : indique qu'il provient de vous mais que le message ne passe pas le contrôle DMARC. En fonction de la politique locale du serveur, cela peut signifier soumettre le message à un examen plus approfondi, le placer dans le dossier spam du destinataire, l'acheminer vers le serveur DMARC ou l'envoyer à un autre serveur. du destinataire, l'acheminer vers un autre serveur ou prendre une autre mesure. p=reject indique que vous souhaitez que le serveur de réception rejette tout message dont la vérification DMARC échoue. Certains serveurs peuvent toutefois accepter ces messages mais les mettre en quarantaine ou les soumettre à un examen plus approfondi. Il s'agit de la politique la plus restrictive et elle ne devrait généralement pas être utilisée à moins que vous n'ayez une confiance totale dans vos politiques de messagerie et dans les types de messages ou de services que vous souhaitez permettre à vos comptes d'utiliser. Si, par exemple, vous souhaitez permettre à vos utilisateurs de s'inscrire sur des listes de diffusion tierces, d'utiliser des services de transfert de courrier, d'utiliser des fonctions de "partage" sur des sites web, etc., l'utilisation de p=reject entraînera très certainement le rejet de certains messages légitimes. Il se peut également que certains utilisateurs soient automatiquement exclus ou bannis de certaines listes de diffusion. Exemple : _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:dmarc-report@example.net" |
Balises optionnelles
Toutes les balises énumérées ci-dessous sont facultatives. Lorsque l'une de ces balises n'est pas utilisée dans un enregistrement, sa valeur par défaut est prise en compte.
Balise |
Valeur |
Remarques |
sp= |
aucun quarantaine rejeter - Non (par défaut) : Si sp= n'est pas utilisé, la balisep= s'applique au domaine et aux sous-domaines. |
Cette balise permet de spécifier une politique à utiliser pour les sous-domaines du domaine auquel s'applique l'enregistrement DMARC. Exemple : si cette balise est utilisée dans un enregistrement ayant une portée sur example.com, la politique indiquée dans la balise p= s'appliquera aux messages provenant de example.com et la politique indiquée dans la balise sp= s'appliquera aux messages provenant des sous-domaines de example.com, tels que mail.example.com. Si cette balise est omise dans l'enregistrement, la balisep= s'appliquera au domaine et à ses sous-domaines. Exemple : _dmarc IN TXT "v=DMARC1;p=quarantine;sp=reject" |
rua= |
Liste d'adresses e-mail, séparées par des virgules, auxquelles les rapports DMARC agrégés doivent être envoyés. Les adresses doivent être saisies sous la forme d'URI : - Non (par défaut) Si cette balise n'est pas utilisée, aucun rapport global ne sera envoyé. |
Cette balise indique que vous souhaitez recevoir des rapports globaux DMARC de la part des serveurs qui reçoivent des messages se réclamant de : un expéditeur de votre domaine. Spécifiez une ou plusieurs adresses électroniques par des virgules ) sous la forme : mailto:user@example.com, en séparant plusieurs adresses électroniques par des virgules. Exemple : _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:user01@example.com,mailto:user02@example.com" En règle générale, ces adresses se trouvent dans le domaine couvert par cet enregistrement. Si vous souhaitez envoyer des rapports à une adresse située dans un autre domaine, le fichier de zone DNS de ce domaine doit également contenir un enregistrement DMARC spécial indiquant qu'il acceptera les rapports DMARC pour le domaine. Exemple d'enregistrement chez example.com : _dmarc IN TXT "v=DMARC1;p=quarantine;rua=mailto:non-local-user@example.net" Enregistrement requis sur exemple.net : Exemple.com._report._dmarc TXT "v=DMARC1" |
ruf= |
Liste d'adresses électroniques, séparées par des virgules, auxquelles les rapports d'échec DMARC doivent être envoyés. Les adresses doivent être saisies en tant qu'URI sous la forme : - Non (par défaut) Si cette balise n'est pas utilisée, aucun rapport d'échec ne sera envoyé. |
Cette balise indique que vous souhaitez recevoir des rapports d'échec DMARC de la part des serveurs qui reçoivent des messages prétendant provenir de : un expéditeur de votre domaine, lorsque les conditions spécifiées dans la balise fo= sont remplies. Non (par défaut), lorsque aucune balise fo= n'est spécifiée, les rapports d'échec sont envoyés lorsque le message échoue à tous les contrôles de vérification DMARC (c'est-à-dire qu'il échoue à la fois à SPF et à DKIM). Spécifiez une ou plusieurs adresses e-mail par des virgules sous la forme : mailto:user@example.com, en séparant plusieurs adresses électroniques par des virgules. Exemple : _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:dmarc-failures@example.com" En règle générale, ces adresses se trouvent dans le domaine couvert par cet enregistrement. Si vous souhaitez envoyer des rapports à une adresse située dans un autre domaine, le fichier de zone DNS de ce domaine doit également contenir un enregistrement DMARC spécial indiquant qu'il acceptera les rapports DMARC pour le domaine. Exemple d'enregistrement chez example.com : _dmarc IN TXT "v=DMARC1;p=quarantine;ruf=mailto:non-local-user@example.net" Enregistrement requis sur exemple.net : Exemple.com._report._dmarc TXT "v=DMARC1" |
Pour de plus amples informations sur la spécification DMARC, voir : www.dmarc.org.
Voir :
