SPF, DKIM et DMARC : les gardiens de votre boîte mail

Vous êtes concernés par SPF, DKIM et DMARC si vous remplissez n'importe laquelle des conditions suivantes :

• Vous avez acheté un nom de domaine (donc 99% des entreprises)

• Vous êtes propriétaire d'un site Web qui envoie des emails transactionnels (exemple : email de "mot de passe oublié" - donc tous les propriétaires de site Web WordPress sont concernés par exemple)

• Vous utilisez des emails @votredomaine.com

• Vous envoyez des emails marketing en masse

Comment fonctionne l'envoi d'un email ? Il s'agit d'une ligne de code qui se présente comme suit :

N'importe qui peut apprendre à envoyer un email dans un language de programmation en moins d'une heure. Vous avez remarqué l'email de l'expéditeur ? Dans l'exemple ci-dessus : [email protected]

Et bien, quand on programme l'envoi d'un email, on peut mettre ce qu'on veut en tant qu'expéditeur. Vous pouvez envoyer des emails en tant que [email protected], [email protected], [email protected], etc. On voit tout de suite le problème que ça pose : usurpation d'identité (identity theft/fraud/impersonation en anglais).

L'éditeur dans lequel on écrit le code d'envoi d'email ne peut pas nous empêcher d'écrire n'importe quoi en tant qu'expéditeur ici. Cela reviendrait à pouvoir vous empêcher d'écrire dans un document Word "Je suis le pape et j'attends ma sœur" : ce n'est pas possible de vous en empêcher, même si c'est faux.

L'instruction d'envoi d'email ne peut donc pas vérifier la véracité des informations.

Etant donné que les emails ont la même valeur qu'un document papier :

En matière de droit des obligations, selon le Code civil français « l'écrit sur support électronique a la même force probante que l'écrit sur support-papier ». L'écrit électronique est de plus reconnu par le Code civil comme valide à titre de preuve afin de conclure un contrat.

Wikipedia sur les courriers électroniques

Cette possible usurpation d'identité ouvre la porte à tout ce que pouvez imaginer : phishing, comme se faire passer pour une banque et envoyer vers un faux site de banque qui récupère les informations de connexion, se faire passer pour un proche, pour un concurrent, pour un patron/employé/collègue, pour un docteur, pour un officiel ... ce n'est pas très pratique et on s'approche d'un chaos apocalyptique.

Mais alors, comment éviter l'apocalypse ? Il y a bien une vérification qui s'effectue : elle se fait plus tard, dans les tuyaux. Pas lors de l'envoi.

L'acheminement des courriels est soumis à des normes, routages et vérifications complexes - si approfondir le sujet vous intéresse, vous pouvez par exemple commencer par la définition Wikipedia. Concentrons-nous ici sur le paramétrage de SPF, DKIM et DMARC.

SPF, DKIM et DMARC sont des technologies qui permettent de lutter contre le spam et les emails frauduleux en vérifiant l'authenticité de l'expéditeur d'un email. En utilisant ces technologies ensemble, en tant que propriétaire de domaine, vous protégez vos utilisateurs et améliorez la réputation de votre nom de domaine.

En d'autres mots, ce sont des mesures de sécurité qu'il vous revient de mettre en place dans les zones DNS de votre domaine, en les paramétrant selon votre utilisation, afin d'authentifier vos envois d'emails, et d'éviter que quelqu'un d'autre n'envoie des emails en votre nom.

Analogie

Imaginez que vous recevez un colis à votre porte. Vous ne savez pas qui l'a envoyé, vous devez donc vérifier son authenticité. Vous pouvez le faire en regardant l'adresse de retour et en vérifiant si elle correspond à une personne ou une entreprise que vous connaissez. Vous pouvez également demander au facteur de confirmer l'identité de l'expéditeur.

SPF, DKIM et DMARC font la même chose pour les emails. Ils vérifient l'identité de l'expéditeur et s'assurent que l'email est authentique avant de le livrer à votre boîte mail.

SPF (Sender Policy Framework) est un protocole qui permet de vérifier l'authenticité de l'expéditeur d'un email. Il fonctionne en définissant une liste d'adresses IP autorisées à envoyer des emails au nom d'un domaine. Si l'adresse IP de l'expéditeur ne figure pas dans la liste SPF, l'email est considéré comme suspect et peut être marqué comme spam.

SPF se présente sous la forme d'un enregistrement dans les zones DNS de votre domaine. Cet enregistrement indique quels serveurs sont autorisés à envoyer des messages au nom de votre nom de domaine.

DKIM (DomainKeys Identified Mail) est un autre protocole d'authentification d'email. DKIM fonctionne en ajoutant une signature numérique à chaque email envoyé. Cette signature est créée à l'aide d'une clé privée stockée sur le serveur de messagerie de l'expéditeur. Le serveur de messagerie du destinataire peut ensuite vérifier la signature à l'aide d'une clé publique publiée dans les enregistrements DNS du domaine de l'expéditeur. Si la signature est valide, cela signifie que l'email a été envoyé par le propriétaire du domaine et n'a pas été modifié en cours de route.

DMARC (Domain-based Message Authentication, Reporting and Conformance) est un protocole qui s'appuie sur SPF et DKIM pour définir des instructions plus précises sur ce que les serveurs de messagerie doivent faire avec les emails non authentifiés.

Les propriétaires de domaine peuvent ainsi choisir de rejeter, mettre en quarantaine ou recevoir les emails qui ne passent pas les tests SPF et DKIM. DMARC permet également de recevoir des rapports sur les emails qui ont été envoyés au nom de votre domaine, ce qui vous permet de mieux surveiller l'activité de votre domaine et de détecter les tentatives d'usurpation d'identité.

SPF se règle avec un enregistrement de type TXT, à la racine du domaine (hôte « @ ») chez votre gestionnaire DNS. Sa valeur commence par « v=spf1 », liste les services autorisés à envoyer des emails pour votre domaine, et se termine généralement par « ~all » ou « -all ». Exemple pour Google Workspace :

Ajoutez tous vos services d'envoi dans ce même enregistrement : un domaine ne doit avoir qu'un seul enregistrement SPF, et la norme limite à 10 les mécanismes qui déclenchent une requête DNS (include, a, mx...).

Chaque enregistrement DKIM fait partie de la signature cryptographique que chaque serveur utilise pour prouver son authenticité et l'intégrité du courrier électronique.

Il y aura donc un enregistrement DKIM par serveur d'envoi, et vous devez laisser le serveur le créer pour vous (que vous copiez-collez ensuite pour le publier dans le DNS sous la forme d'un enregistrement TXT).

La politique DMARC, ou l'enregistrement DMARC, indique simplement au monde ce qu'il doit faire s'il reçoit un courriel prétendant provenir de votre domaine mais qui échoue aux contrôles SPF ou DKIM.

Il échouera s'il a été envoyé par un serveur non autorisé ou s'il a été altéré ou n'est pas authentique. Par conséquent, un DMARC par domaine (bien que vous puissiez faire des DMARC spécifiques à un sous-domaine si vous le souhaitez vraiment pour un cas d'utilisation spécifique).

DMARC doit finalement être réglé sur Reject (après s'être assuré que tous les expéditeurs légitimes sont correctement configurés) pour réellement "fonctionner" (bien que vous puissiez le laisser en Quarantine pour toujours, cela laisse au serveur de messagerie de réception le soin de décider s'il veut envoyer un mauvais message dans le dossier spam de l'utilisateur ou non, ce qui ne garantit pas qu'un message d'hameçonnage sera bloqué). S'il ne rejette pas (ou ne met pas en quarantaine), il ne contribue pas du tout à prévenir les attaques.

Tout ce qui concerne la surveillance des rapports, le resserrement progressif de la politique dmarc, le paiement de la surveillance, etc., tout cela est purement dû au fait que nous n'avons généralement pas une connaissance complète de ce que le propriétaire du domaine/notre client fait avec les courriels. Si vous connaissiez 100% des services qui envoient des courriels légitimes, que vous les ajoutiez tous à la liste SPF et que vous configuriez DKIM pour chacun d'entre eux, vous pourriez tout à fait passer immédiatement à 100% de rejet et ignorer les rapports. Ce n'est pas la réalité la plupart du temps, mais pour votre propre domaine, cela pourrait être le cas. Nous surveillons et implémentons souvent DMARC sur 30 jours simplement pour détecter des services légitimes que nous avons oublié de configurer (ou dont le propriétaire a oublié de mentionner l'existence) sans perturber les activités de l'entreprise, sans autre raison.

le domaine de l'email de rapport. Par défaut, ils doivent correspondre, mais j'ai appris récemment que vous pouvez utiliser un domaine différent si vous ajoutez un enregistrement au domaine de réception qui autorise l'envoi de rapports à d'autres domaines. Je n'ai pas pris le temps d'appliquer cela plus d'une fois sur un domaine de test, donc il y a peut-être d'autres nuances que je ne connais pas. MX Toolbox avait une explication utile sur la façon de former l'enregistrement requis si vous voulez l'essayer :

https://mxtoolbox.com/problem/dmarc/dmarc-external-validation

L'objectif initial de DMARC était d'empêcher les pirates d'envoyer des courriels (emails) en votre nom, que ce soit dans le cadre d'une opération d'hameçonnage (phishing) ou d'une simple tentative d'escroquerie (scam).

Il y a un gros sujet en 2024 à propos de DMARC.

Faites-le vous-même et haïssez votre vie à cause de tous les rapports que vous recevez, ou payez un bras et une jambe pour qu'un logiciel le fasse pour vous, avec des solutions allant de 30$ à 100$/mois par domaine.

Voici un guide pour paramétrer DMARC sur votre domaine.

ça ressemble à ça :

Certains vous diront que ce paramétrage est suffisant. Hors, en réalité, il ne faudrait pas utiliser la valeur "none". Utiliser "none" supprime toute l'utilité du DMARC. En utilisant "none", tout ce qu'on fait est dire aux emails providers que si quelqu'un envoie des emails frauduleusement en notre nom, on s'en fout, même s'ils font du phishing ou s'ils essayent de voler des gens.

Un paramétrage DMARC avec la valeur "none" passera quand même les tests de validation du DMARC, mais cela va complètement à l'encontre de l'objectif de DMARC.

Vous devriez utiliser le mode "quarantine" (quarantaine) ou "reject" (rejet).

Les rapports me donnent des informations détaillées sur les problèmes de délivrabilité en m'indiquant si les SPF et DKIM sont correctement alignés.
Les rapports vous indiquent tous les serveurs qui envoient des messages en tant que votre domaine. Cela inclut les services de newsletter et d'email transactionnel, les fournisseurs d'email, les serveurs web, etc.
Ces informations sont utiles pour déterminer si vos messages légitimes sont délivrés correctement ou si des tiers tentent d'utiliser votre domaine à des fins malveillantes.

Vous devez vous assurer que tout est correct dans les enregistrements SPF et DKIM de votre domaine ou du domaine de votre client. Ensuite, vous devez mettre votre politique DMARC en quarantaine. Les rapports que vous recevrez pour DMARC vous indiqueront si les informations contenues dans vos enregistrements SPF et DKIM sont correctes ou non. C'est pourquoi il est important de lire ces rapports, soit en faisant appel à un service tiers pour les rendre plus conviviaux, soit en payant quelqu'un pour le faire à votre place.

utiliser None lors de la première mise en place de DMARC, afin de pouvoir déterminer si le courrier électronique pose des problèmes ou s'il en pose. Réglez ensuite la mise en quarantine ou reject.

Vous devez mettre en place SPF et DKIM avant DMARC. Et Troy a raison de dire que si p=none satisfait pour l'instant les règles de google et yahoo, il ne protège pas autant votre email que la quarantaine ou le rejet.

Tant que vous avez les bons enregistrements DNS pour les services qui envoient au nom de votre domaine, tout va bien. Le problème survient lorsque vous n'avez pas ces enregistrements corrects et que les choses ne s'alignent pas correctement. Vous pouvez penser que vous avez les bons enregistrements mais ce n'est pas le cas et c'est là que les rapports entrent en jeu. Ils vous signalent les problèmes et vous devez les résoudre.

Tant que vous lisez les rapports, tout va bien. Beaucoup de gens le règlent sur none et s'en tiennent là.

Reject est la meilleure solution à condition d'avoir tous les enregistrements appropriés dans SPF et DKIM.

assurez-vous d'inclure les services tiers tels que les services de lettres d'information, les services d'email transactionnels et les services d'email eux-mêmes tels que Google Workplace et Microsoft 365, etc. Toute personne qui envoie comme votre domaine.

vous n'avez pas besoin d'un abonnement mensuel pour cela. Après 30 jours, vous devriez avoir une idée générale de ce qui est envoyé en tant que votre domaine à partir des rapports DMARC. Une fois que vous avez tout configuré correctement et que vous n'avez pas modifié de nouveaux services, tout fonctionnera comme il se doit. Vous devez simplement vous rappeler d'ajouter l'enregistrement DNS pour tous les nouveaux services que vous ajoutez.

Une fois qu'une personne a été mise en quarantaine pendant 30 jours pour contrôler ses rapports, recommandez-vous de passer au rejet et de rejeter progressivement 25% par semaine, de rejeter directement 100%, ou de rester en mode quarantaine ?

Voici comment je procède. Je configure la surveillance des courriers électroniques avec la politique "aucun". Au bout d'une semaine environ, je devrais avoir un bon rapport de Google, Microsoft et d'autres grandes plateformes de ce type. Une fois que je sais que tout est correct, je mets le message en quarantaine. Je le garde en quarantaine jusqu'à la fin des 30 jours et si tout semble correct, je le rejette.

Oui, l'enregistrement DMARC lui-même n'est qu'un enregistrement DNS. Et oui, selon la spécification technique, la seule balise requise est p= quelle que soit la politique choisie, qui peut être aucune.
Cependant, l'objectif de DMARC est de travailler avec les autres protocoles d'authentification du courrier électronique, SPF et DKIM, afin de fournir une meilleure sécurité pour le courrier électronique, d'aider à prévenir l'usurpation d'identité, l'hameçonnage, etc. C'est pourquoi Google et Yahoo ont déclaré qu'ils exigeaient SPF, DKIM et DMARC.
Si la seule chose qui vous préoccupe est de répondre aux exigences actuelles de Google/Yahoo, p=none fonctionnera, pour l'instant. Toutefois, si Google et Yahoo prennent au sérieux les raisons pour lesquelles ils exigent l'authentification du courrier électronique, je ne pense pas que cela fonctionnera éternellement. La politique p=none est destinée à vous permettre de contrôler votre installation avant de passer à une politique plus restrictive. Si vous vous contentez de p=none, vous indiquez aux fournisseurs de messagerie que vous ne vous souciez pas de savoir si quelqu'un usurpe votre adresse électronique. Et n'oubliez pas que le fournisseur d'accès n'est pas OBLIGÉ d'accepter votre politique. Je ne serais pas surpris que, dans un an environ, p=none vous envoie dans les spams de Google.

Si vous avez une configuration de messagerie très simple, vous n'avez peut-être pas besoin de payer quelqu'un tous les mois pour déchiffrer et surveiller les rapports, une fois que tout est configuré correctement. Mais si quelque chose change, si vous suivez les meilleures pratiques et faites pivoter vos clés DKIM, si vous êtes dans le collimateur de quelqu'un et que vous commencez à subir d'importantes attaques par usurpation d'identité, vous avez besoin de ces rapports.
DMARC n'est pas un processus que l'on met en place et que l'on oublie. Une grande partie de la raison pour laquelle la norme DMARC a été proposée était de fournir des capacités de rapport afin d'identifier et de résoudre les problèmes.

Cloudflare est très bien pour savoir qui envoie en tant que vous, mais la façon dont ils présentent les informations n'est pas optimale. Ils ne vous disent pas ce qui n'est pas aligné correctement et ce genre de choses. La version gratuite de Postmark serait meilleure pour ça.

Mais il faut créer un compte gratuit par domaine.

postmark free one fonctionne très bien par domaine. Le seul point négatif est qu'ils veulent que vous créiez un compte pour chaque domaine. Je préfère les rapports à ceux de Cloudflare. Ils vous informent au moins des problèmes d'alignement.

https://easydmarc.com/

https://www.dmarctester.com : apprendre et tester Dmarc