À un niveau général, la mise en œuvre de la norme d’authentification, de signalement et de conformité des messages basée sur le domaine (DMARC) peut s’effectuer simplement pour les e-mails sortants, en ajoutant un fichier texte à l’enregistrement DNS d’une organisation. En pratique, toutefois, la complexité des organisations modernes peut considérablement compliquer le processus et imposer une approche itérative afin de s’assurer qu’aucun expéditeur d’e-mails légitime ne soit soudainement signalé comme indésirable.
Les étapes de base sont les suivantes :
- Publier un enregistrement DMARC auprès du fournisseur DNS
- Surveiller les rapports DMARC afin d’identifier les expéditeurs légitimes qui échouent au contrôle DMARC
- Modifier SPF, DKIM et DMARC si nécessaire pour s’assurer que les sources légitimes passent le contrôle
- Renforcer les restrictions DMARC
- Surveiller les rapports DMARC pour repérer les sources légitimes qui échouent et les sources potentiellement malveillantes qui tentent d’usurper l’identité de l’organisation
Bien sûr, ces étapes de base nécessitent souvent des précisions supplémentaires pour être exécutées correctement. Cet article détaille donc les points suivants :
- Comment configurer un enregistrement DMARC
- Les balises d’un enregistrement DMARC en détail
- Tests et mise en œuvre de DMARC
- En résumé : mettez en place une configuration DMARC efficace pour en tirer les bénéfices
Pour ceux qui auraient besoin d’un rappel sur DMARC, nous vous conseillons de lire Qu’est-ce que DMARC ? Définitions, avantages, inconvénients et plus encore en premier.
Comment configurer un enregistrement DMARC
La création d’un enregistrement DMARC peut être simple. Il s’agit toutefois d’une norme qui dépend d’autres standards d’authentification des e-mails. La configuration d’un enregistrement DMARC nécessite donc d’abord d’établir ces standards dépendants, puis de publier l’enregistrement DMARC.
Standards d’authentification des e-mails requis
DMARC dépend de la mise en place réussie de Sender Policy Framework (SPF) et de la norme d’authentification DomainKeys Identified Mail (DKIM). Il est possible de définir une politique DMARC dans un enregistrement DNS sans avoir préalablement configuré SPF et DKIM, mais elle ne pourra rien faire. Les politiques DMARC définissent la manière dont les enregistrements SPF et DKIM doivent être traités par les serveurs de messagerie.
Il est important de tester la configuration de SPF, DKIM et DMARC pour vérifier que les politiques définies fonctionnent comme prévu et ne finissent pas par bloquer des e-mails légitimes. Bien que ce point soit abordé plus en détail ci-dessous, dans la section consacrée aux tests et à la mise en œuvre de DMARC, ces tests expliquent pourquoi il est recommandé de commencer avec les options « relaxed » et « quarantine ».
Publier DMARC
Pour configurer DMARC, une organisation publie un fichier texte, appelé enregistrement DMARC, auprès de ses bureaux d’enregistrement DNS. Les enregistrements DMARC peuvent être publiés gratuitement et l’entreprise peut modifier son fichier texte aussi souvent qu’elle le souhaite. L’enregistrement DMARC se présente sous la forme d’une simple ligne et, pour de nombreuses organisations, il suffit de :
- Se connecter à leur bureau d’enregistrement de domaine
- Cliquer sur l’option permettant de gérer ou de configurer les paramètres DNS
- Cliquer sur l’option « Add a New Record » et choisir un enregistrement « TXT »
- Copier-coller le texte de l’enregistrement DMARC dans le champ prévu à cet effet
Dans de nombreuses configurations d’hébergement, le nom de domaine est automatiquement ajouté au nom du fichier. Dans le cas contraire, il faudra nommer manuellement l’enregistrement :
- Syntaxe : _dmarc.<domaine ou sous-domaine>
- Exemple de sous-domaine : _dmarc.mailservers.ExampleDomain.com
- Exemple de domaine : _dmarc.NonProfitHealthcareExample.org
Les différents fournisseurs DNS peuvent avoir des exigences ou des procédures différentes. Une organisation doit donc examiner attentivement les options proposées par son fournisseur. Les politiques DMARC peuvent être établies séparément pour les sous-domaines, mais un sous-domaine dépourvu de politique DMARC héritera de celle du domaine parent.
Bien sûr, même si l’enregistrement DMARC peut être publié facilement et ne consiste qu’en un fichier texte, certains sous-estimeront la facilité avec laquelle une erreur peut être commise. Pour éviter les problèmes, il faut comprendre en détail les balises d’un enregistrement DMARC.
Les balises d’un enregistrement DMARC en détail
Pour comprendre l’enregistrement DMARC, commençons par un exemple, puis examinons en détail les options de chaque balise.
v=DMARC1;p=none;rua=mailto:dmarc@dxampledomain.com;ruf=mailto:dmarc@exampledomain.com;rf=afrf;pct=100Parmi ces champs, seuls les deux premiers, « v » et « p », sont obligatoires et doivent être indiqués en premier et dans cet ordre. Les autres variables sont facultatives, mais la plupart sont recommandées et peuvent apparaître dans n’importe quel ordre, à condition que « v » soit la première, suivie de « p ».
Les balises sont séparées par des points-virgules ( ; ), sans espaces supplémentaires. Lorsqu’on utilise la balise rua pour envoyer les rapports DMARC par e-mail, il faut ajouter le préfixe mailto: devant chaque adresse e-mail. Bien que seule la balise « v » soit sensible à la casse, il est recommandé d’utiliser uniquement des lettres minuscules pour toutes les balises, à l’exception de « v ».
v=DMARC1
La balise « v » désigne l’identifiant de version, qui sera toujours « DMARC1 ». Lorsqu’un serveur destinataire analyse l’enregistrement DNS du domaine ayant envoyé le message, il recherche cette valeur. Si le domaine ne contient pas d’enregistrement texte commençant par « v=DMARC1 », le serveur destinataire n’effectuera pas de contrôle DMARC. La balise « v » est la seule option sensible à la casse et DMARC1 doit être entièrement écrit en majuscules.
p=none
La balise « p » désigne la politique et indique au serveur de messagerie destinataire participant ce qu’il doit faire des messages qui ne passent pas les contrôles SPF ou DKIM tout en prétendant provenir de votre domaine. Dans ce cas, la politique sera « none ».
Les trois options de politique sont les suivantes :
- p=none : le paramètre le plus permissif ; « none » indique au serveur de messagerie destinataire de n’appliquer aucune action aux messages non conformes
- p=quarantine : cette commande légèrement plus stricte indique au serveur de messagerie destinataire d’isoler les messages non conformes, généralement en les envoyant dans le dossier des spams
- p=reject : le paramètre le plus strict ; « reject » indique au serveur de messagerie destinataire de refuser tous les messages non conformes destinés au domaine. Seuls les messages vérifiés comme étant signés par votre domaine peuvent tenter d’atteindre la boîte de réception du destinataire ; tous les autres sont supprimés afin de limiter les faux positifs.
Notez que les instructions DMARC peuvent être ignorées ou modifiées par le serveur de messagerie destinataire. Par exemple, Microsoft Office 365 traite de la même manière les options reject et quarantine et place les e-mails ayant échoué au contrôle DMARC dans le dossier des spams.
rua=mailto:dmarc@exampledomain.com
Un élément particulièrement important de la politique DMARC est qu’elle fournit également un mécanisme de signalement, afin que les administrateurs de domaine puissent déterminer si des e-mails échouent ou si un attaquant tente d’usurper un domaine donné.
« rua=mailto: » et l’adresse e-mail qui suit la balise définissent l’adresse à laquelle doivent être envoyés les rapports agrégés sur les échecs DMARC. Ces rapports contiennent des informations générales sur les échecs DMARC, sans détails.
ruf=mailto:dmarc@exampledomain.com
À l’instar de l’autre balise d’e-mail, « ruf=mailto: » définit l’adresse e-mail à utiliser pour les rapports d’analyse détaillés sur les échecs DMARC. Ces rapports contiennent de nombreux détails sur chaque échec et les serveurs de réception des e-mails envoient ces fichiers en temps réel, au moment où les échecs se produisent.
Dans notre exemple, « rua » et « ruf » utilisent la même adresse e-mail, mais les organisations peuvent choisir des destinataires différents. Elles doivent toutefois savoir que, contrairement à la balise « rua », l’adresse e-mail « mailto: » de « ruf » doit appartenir au domaine ayant publié l’enregistrement DMARC.
rf=afrf
La balise « rf », ou format de rapport, prend par défaut la valeur « afrf », qui signifie « aggregate failure reporting format ».
pct=100
La variable « pct », ou pourcentage, indique au serveur de messagerie destinataire quel pourcentage des e-mails entrants doit respecter les spécifications de la politique DMARC, sous la forme d’une valeur comprise entre 1 et 100. Dans notre exemple, « pct=100 » exige que 100 % des e-mails qui échouent au contrôle DMARC soient rejetés. En revanche, si la valeur était fixée à 5 %, seuls 5 % des e-mails en échec seraient rejetés.
sp
La balise sp, qui désigne la politique applicable aux sous-domaines, indique si le serveur de messagerie destinataire doit appliquer la politique DMARC aux sous-domaines de l’organisation.
aspf=r
La balise « aspf », ou balise d’alignement SPF, indique si le domaine MailFROM et le champ « From » de l’en-tête, également contrôlé par SPF, doivent correspondre exactement ou peuvent présenter une relation parent/enfant. La valeur « r » indique un alignement relâché, qui autorise une correspondance parent/enfant, tandis que la valeur « s », correspondant à un alignement strict, exige une correspondance exacte.
Par exemple :
| Domaine From | Domaine SPF | Contrôle relâché | Contrôle strict |
|---|---|---|---|
| Example.org | Example.org | Réussite | Réussite |
| Example.org | Mail.Example.org | Réussite | Échec |
| Mail.Example.org | Mail.Example.org | Réussite | Réussite |
| Mail.Example.org | Example.org | Réussite | Échec |
| Example.Mail.org | Example.org | Échec | Échec |
adkim
La balise « adkim », ou balise d’alignement DKIM, peut prendre la valeur « s » pour strict ou « r » pour relâché. Le paramètre strict garantit que DKIM ne réussira que si le champ « d= » de la signature correspond exactement au domaine « from ». Le paramètre relâché permet la réussite de DKIM dans tous les cas où le champ « d= » correspond au domaine racine de l’adresse « from ».
fo
La balise « fo », ou option de signalement des échecs, prend par défaut la valeur « 0 ». Une organisation peut toutefois sélectionner manuellement l’une des options suivantes :
- 0 = un rapport d’échec DMARC ou d’analyse est envoyé si l’e-mail échoue à la fois à l’alignement SPF et à l’alignement DKIM
- 1 = un rapport d’échec DMARC ou d’analyse est envoyé si l’e-mail échoue à l’alignement SPF ou à l’alignement DKIM
- d = un rapport d’échec DKIM est envoyé si l’e-mail échoue à la validation DKIM, qu’il soit aligné ou non
- s = un rapport d’échec SPF est envoyé si l’e-mail échoue à la validation SPF, qu’il soit aligné ou non
ri
La balise « ri » prend par défaut la valeur « 86400 » et définit l’intervalle entre deux rapports agrégés consécutifs.
Tests et mise en œuvre de DMARC
La publication de l’enregistrement DMARC active DMARC pour un domaine donné. Toutefois, la simple configuration de DMARC ne constitue que le début de la démarche. Une organisation doit tester l’exactitude des enregistrements, surveiller les résultats inattendus, corriger les problèmes et renforcer progressivement les paramètres DMARC afin de commencer à bloquer les e-mails non autorisés.
Remarque : le DNS peut mettre un certain temps à se propager. Une partie de ces tests doit donc être effectuée plusieurs jours après la mise à jour du DNS.
Tests de SPF, DKIM et DMARC
Une recherche Google sur les tests de SPF, les tests de DKIM et les tests de DMARC fournira une liste de sources proposant des outils en ligne capables de détecter les problèmes de formatage et l’utilisation incorrecte de variables. Ces tests doivent être effectués en premier afin de repérer les erreurs simples.
Toutefois, ces tests ne peuvent pas détecter les erreurs typographiques dans les domaines, les adresses e-mail ou les adresses IP. L’organisation devra plutôt envoyer des e-mails de test afin de vérifier ces types de problèmes. Pour obtenir des informations plus détaillées sur le dépannage et les erreurs courantes, consultez Pourquoi DMARC échoue : 3 problèmes critiques liés au déploiement de DMARC.
Surveillance de DMARC
Lors de la configuration initiale de DMARC, une organisation doit définir « p=none » et surveiller les rapports afin de repérer les résultats inattendus. Elle peut par exemple découvrir qu’un service d’envoi tiers ou qu’un serveur de messagerie inattendu envoie des e-mails qui n’avaient pas été pris en compte dans la configuration de SPF ou de DKIM. En outre, même si l’organisation peut souvent identifier à l’avance la plupart des fournisseurs de services marketing, des systèmes d’assistance, des services de boîte de réception et des services d’envoi d’e-mails automatisés, d’autres sources d’e-mails sont régulièrement négligées, notamment les alertes provenant des serveurs et des outils d’administration.
Les organisations mettent généralement plusieurs semaines à plusieurs mois à surveiller les résultats de DMARC et à mettre à jour SPF et DKIM avec des serveurs de messagerie supplémentaires.
Aligner les sources d’e-mails connues sur DMARC, DKIM et SPF
À mesure que de nouvelles sources d’e-mails sont identifiées, l’équipe informatique devra les ajouter aux fichiers DKIM et SPF afin de garantir leur alignement pour DMARC. L’identification de chaque source peut être délicate. Pour faciliter cette tâche, il est possible de créer une liste de toutes les sources de l’organisation connues pour envoyer des e-mails.
Lorsque de nouvelles sources apparaissent dans les rapports, l’organisation peut essayer de les faire correspondre aux sources connues, telles que les fournisseurs d’e-mails, les systèmes de commerce électronique et les services marketing. Parmi les exemples courants figurent Google Apps (Gmail), Salesforce, Intercom, Campaign Monitor, Mailchimp et Microsoft 365.
Les rapports peuvent être difficiles à comprendre sans utiliser d’outils tiers qui aident à organiser les données importantes et à les mettre en évidence. Certains analyseurs de rapports ajoutent par exemple des informations utiles, comme la résolution de l’adresse IP source des serveurs de messagerie afin d’indiquer l’emplacement et le propriétaire de l’adresse IP. Ces informations peuvent être essentielles pour déterminer la légitimité de la source d’e-mails.
Des services comme Zendesk, Campaign Monitor, Google Apps et Rackspace proposent des articles indiquant quels enregistrements SPF ou DKIM ajouter à votre DNS. Dans certains cas, la difficulté liée à la gestion des exigences des serveurs internes peut amener certaines organisations à migrer leur messagerie vers un service capable de gérer également la configuration de DKIM et de SPF.
Certaines sources ou certains domaines et adresses IP en échec peuvent sembler incohérents. Il s’agit souvent de messages légitimes transférés par des utilisateurs qui n’ont pas réussi à conserver les en-têtes SPF et DKIM. Les sources d’e-mails secondaires ayant envoyé moins de 10 e-mails sur une période donnée peuvent généralement être ignorées.
Renforcer les balises de politique DMARC
Après avoir ajouté à SPF et DKIM toutes les sources d’e-mails détectées par la surveillance, l’organisation doit faire évoluer la balise de politique vers « quarantine » ou « reject ». Tant que ce dernier ajustement n’est pas effectué, les usurpateurs et les spammeurs qui tentent d’usurper la marque de l’organisation ne seront pas bloqués.
En résumé : mettez en place une configuration DMARC efficace pour en tirer les bénéfices
La mise en œuvre d’une politique DMARC efficace peut améliorer de 5 à 10 % la distribution des campagnes d’e-mail marketing, améliorer la réputation du domaine et réduire considérablement les e-mails indésirables et d’usurpation qui tentent d’imiter la marque d’une organisation. Ces avantages importants ne peuvent être obtenus que si l’organisation configure correctement son enregistrement DMARC, mais ils justifient le temps et les efforts investis.
Cet article a été rédigé et publié à l’origine par Sean Michael Kerner le 24 janvier 2018, puis mis à jour par Chad Kime le 1er juin 2023.