Déployez DMARC sur votre nom de domaine !

Aujourd’hui, je vous propose de parler DMARC. L’objectif est de vous aider – si vous n’avez pas encore franchi le cap – à mieux protéger vos noms de domaine avec DMARC et cerise sur le gâteau un article ultime sur le déploiement de BIMI si et seulement si vous déployez une politique restrictive sur DMARC !

Sur ce premier article DMARC de 2021, je vais mettre à jour un vieil article que j’avais écrit en 2017 sur l’implémentation de DMARC en vous détaillant un peu plus son paramétrage avec toutes les options disponibles ! Avec ça, vous devriez vous en sortir… Si ce n’est pas le cas, faites appel à nous :p).

Hey Sébastien… C’est quoi DMARC et ça sert à quoi ?

Derrière l’acronyme « DMARC » (Domain-based Message Authentication, Reporting and Conformance) se cache une norme d’authentification qui va vous permettre de renforcer la sécurité de votre nom de domaine.

L’usage de DMARC est triple :

• Renforcer les limitations de SPF & DKIM en appliquant une règle de sécurité en cas d’échec.
• Limiter le spam et le phishing sur votre domaine expéditeur et tous ses sous-domaines grâce aux rapports fournis par certains organismes.
• Rendre conforme ses flux e-mails afin d’en améliorer la légitimité.

Même si DMARC n’est pas obligatoire pour le moment, il est quand même très fortement conseillé de l’implémenter… Votre réputation peut en dépendre !!!

Okay ! Tu peux me dire comment ça fonctionne et ce que je dois faire pour déployer DMARC ???

DMARC va permettre à tout organisme qui sait le vérifier et l’interpréter d’appliquer une politique de sécurité qui est au préalable définit dans un enregistrement TXT du domaine expéditeur (on parle ici du « From » domaine).

Cette politique de sécurité se décline de trois manières :

• La politique « none » : aucune action sera faite sur l’e-mail en cas d’échec.
• La politique « quarantine » : l’e-mail sera délivré en spam en cas d’échec.
• La politique « reject » : l’e-mail sera refusé en cas d’échec.

Pour être fonctionnel, DMARC s’appuie sur deux systèmes d’authentification qui sont SPF (Sender Policy Framework) et DKIM (DomainKey Identified Mail). Si les deux sont en échec lors de la réception d’un e-mail, la politique définie en amont sera alors appliquée.

Pour implémenter DMARC, il vous faut :

• Avoir un enregistrement SPF valide.
• Avoir un enregistrement DKIM valide.
• Avoir accès en écriture sur le domaine expéditeur (soit vous, soit votre DSI, soit via l’hébergeur qui gère votre domaine)

Si vous remplissez tous les critères, il vous suffira de créer un enregistrement TXT (notre fameux enregistrement fourre-tout où justement seront stockés SPF/DKIM) et d’y insérer un enregistrement DMARC ! Simple non ?

Coooool ! Mais tu peux nous fournir un exemple concret ???

Petite aparté sur la une logique d’implémentation DMARC. Il est important de le placer directement sur le domaine principal afin que toute l’infrastructure du domaine (et ses sous-domaines) soit protégée et conforme à DMARC. Ça serait une erreur de se dire que votre domaine principal n’a pas besoin de DMARC parce qu’il n’envoie d’e-mails… Un domaine vulnérable est une aubaine pour tout pirate et si ce dernier devait être listé sur des block listes majeures, vos sous-domaines en paieraient le prix fort !

Passons maintenant à nos trois exemples. Il faut savoir que DMARC dispose de tags obligatoires et de tags facultatifs… Si un tag n’est pas déclaré, il prendra automatiquement la valeur par défaut.

Pour vous montrer ces détails, nous allons utiliser quelques outils en ligne comme Dmarcian, Mxtoolbox, Dmarcanalyser. N’hésitez pas à faire cette petite vérification pour savoir si DMARC est déjà implémenté ou non :

Exemple n°1 :

Dmarcian nous indique que DMARC est valide ! On peut voir également que nous avons défini une politique de sécurité à « quarantine » (p=quarantine) et que nous utilisons le module de 250ok pour recevoir/monitorer les rapports DMARC.

Exemple n°2 :

Mxtoolbox nous indique que DMARC est valide ! Ici, on peut voir qu’Hermès applique une politique de sécurité « reject » (très restrictive) sur son domaine principal. Il utilise la solution Proofpoint pour recevoir/monitorer les rapports DMARC.

Exemple n°3 :

Dmarcanalyzer nous indique que DMARC comporte des erreurs (*), d’où l’utilité de vérifier son enregistrement une fois implémentée ! Ici, on peut voir que Voyage Privé n’applique pas de politique de sécurité mais monitore uniquement les données des rapports (s’ils le font vraiment…).

* 3 erreurs : la première, le tag « p » doit être placé en 2^ème (cf. lire le paragraphe suivant) et la deuxième se situe sur les adresses déclarées, elles comportent un espace… La troisième est l’utilisation d’un domaine externe dans l’adresse e-mail, pour pouvoir recevoir tous les rapports DMARC, il va falloir demander à Google d’effectuer une modification sur son domaine « gmail.com » … Pas sûr que ça aboutisse !

Vous pouvez voir que d’une configuration à l’autre, le contenu de DMARC est totalement différent !

Euh… C’est du chinois ton truc… Tu peux me détailler le contenu de chaque enregistrement DMARC ?

Si vous n’êtes pas familier avec DMARC, ça peut être vite difficile à comprendre. Plus que d’analyser les tags des trois enregistrements vus dans le paragraphe précédent, je vous propose de lister et de détailler toutes les options / valeurs disponibles pour DMARC sachant certaines sont obligatoires et d’autres facultatives…

Les éléments obligatoires

Deux tags sont obligatoires et doivent être déclarés en premier, il s’agit de :

• « v » : vous déclarez ici la version de DMARC… Pas de panique, il y en a qu’une !

v=dmarc1;

• « p » : vous déclarez ici la politique de sécurité qui sera appliquée au domaine où est implémenté DMARC. Trois valeurs possibles : « none », « quarantine », « reject ».

p=none; ou p=quarantine; ou p=reject;

Deux points importants : n’oubliez pas après chaque valeur d’ajouter le « ; » et surtout aucun espace ne doit être mis avant ou après la valeur.

Les éléments facultatifs

• « sp » : vous déclarez ici la politique de sécurité qui sera appliquée à tous les sous-domaines du domaine où est implémenté DMARC. Trois valeurs possibles : « none », « quarantine », « reject ». Si le tag n’est pas déclaré, tous les sous-domaines hériteront automatiquement de la valeur déclarée dans le tag « p ». Ce champ est pratique si vous souhaitez avoir une politique différente entre le domaine principal et les sous-domaines.

sp=none; ou sp=quarantine; ou sp=reject;

• « pct » : vous déclarez ici le pourcentage d’e-mails où la politique de sécurité sera appliquée (entre 0 et 100). Par défaut, la valeur est 100.

pct=50;

Sur cet exemple là, 5°% des e-mails seront filtrés si DMARC a une politique de sécurité restrictive.

• « rua » : vous déclarez ici l’adresse e-mail qui recevra les rapports agrégés envoyés par les organismes. Vous avez la possibilité de définir une taille de fichier maximum en l’ajoutant à la fin de votre adresse e-mail.

rua=mailto:votreadresseemail; ou rua=mailto:votreadresseemail!50m »

Deux points importants : utilisez plutôt une adresse e-mail de votre domaine principal ou d’une solution de monitoring car il faudra autoriser le domaine de l’adresse choisie à recevoir les rapports DMARC. Si ce n’est pas le cas, vous ne recevrez qu’une partie des rapports.

Les tailles se définissent en « k » (kilo-octet), « m » (méga-octet), « g » (giga-octet), « t » (tétra-octet).

• « ruf » : vous déclarez ici l’adresse e-mail qui recevra les rapports d’échec (comprenez ici des exemples d’e-mails) envoyés par certains organismes.

ruf=mailto:votreadresseemail;

Deux points importants aussi ici, les mêmes que pour l’adresse « rua » !

• « aspf » : vous déclarez ici le type d’alignement SPF que vous souhaitez. Deux valeurs possibles : « r » pour relâché (cf. configuration souple), « s » pour strict (configuration stricte). Si le tag n’est pas déclaré, la valeur par défaut sera « r ».

aspf=r; ou aspf=s;

Avec une configuration souple, le domaine de l’adresse Mailfrom ou Return-path peut être un sous-domaine du domaine From (cf. expéditeur). Exemple : Mailfrom = em.badsender.com & From = badsender.com

Avec une configuration stricte, le domaine (ou sous-domaine) de l’adresse Mailfrom (ou Return-path) doit être identique au domaine From (cf. expéditeur). Exemple : Mailfrom = badsender.com & From = badsender.com

• « adkim » : vous déclarez ici le type d’alignement DKIM que vous souhaitez. Deux valeurs possibles : « r » pour relâché (cf. configuration souple), « s » pour strict (configuration stricte). Si le tag n’est pas déclaré, la valeur par défaut sera « r ».

adkim=r; ou adkim=s;

Avec une configuration souple, le domaine déclaré dans la signature DKIM peut être un domaine ou sous-domaine du domaine From (cf. expéditeur).

Exemple : DKIM > d=em.badsender.com & From = badsender.com

Avec une configuration stricte, le domaine déclaré dans la signature DKIM doit être le même que le domaine From (cf. expéditeur).

Exemple : DKIM > d=badsender.com & From = badsender.com

• « rf » : vous déclarez ici le format des rapports d’échec que vous recevrez. Il n’y a qu’une seule valeur de disponible actuelle, le format « afrf » (cf. vous recevrez l’e-mail en PJ).

rf=afrf;

• « ri » : vous déclarez ici le nombre de secondes qui s’écoulera entre l’envoi des rapports agrégés. Si l’élément n’est pas déclaré, sa valeur par défaut est 86 400 secondes – soit un jour.

ri=86400;

• « fo » : vous déclarez ici quel type de rapports agrégés vous souhaitez recevoir. Quatre valeurs sont disponibles : « 0 » pour recevoir les rapports d’échec SPF et DKIM, « 1 » pour recevoir les rapports d’échec SPF et/ou DKIM, « d » pour recevoir les rapports d’échec DKIM, « s » pour recevoir les rapports d’échec SPF. Si l’élément n’est pas déclaré, la valeur par défaut est « 0 ».

fo=0; ou fo=1; ou fo=d; ou fo=s;

Ah top ! Et donc avec une telle configuration, fini le phishing ?

Et bien malheureusement non ! Même si DMARC a été créé pour limiter le spam et l’usurpation d’identité mais ne vous garantira pas une protection efficace à 100% et ce pour deux raisons :

• Tous les organismes (FAI/Webmails, Entreprises, …) ne savent pas interpréter DMARC, ce qui implique que la politique de sécurité ne sera pas appliquée.
• Pour être efficace, la politique de sécurité devra être la plus haute possible (cf. reject) avec des alignements SPF/DKIM stricts.

Finish… On digère maintenant !

Avec cet article « actualisé », vous n’aurez plus d’excuses pour passer à côté de DMARC !

Prochain numéro : on va analyser un rapport DMARC de Google ! Le kiff 🙂

– – – – –

Besoin d’aide pour déployer DMARC ? On est là pour vous aider 

– – – – –

N’hésitez pas à partager, liker, commenter… Bref, faites du bruit !!!!!

– – – – –

Badsender, agitateur d’expertise emailing ! Badsender, c’est une équipe d’artisans spécialistes des différentes disciplines qui entourent l’email marketing ! Notre agence emailing intervient sur des questions des stratégie, de conception, d’orchestration et de délivrabilité. Cette expertise, nous vous la proposons sous forme de coaching, d’audits, ou d’intervention en tant que force de production externalisée. 

– – – – –

Quelques articles ayant un intérêt commun avec celui-ci :

SPF :

• Qu’est-ce que SPF ? Configuration, vérification et monitoring.
• 10 conseils à mettre en place dans sa configuration SPF…
• Et si vous passiez votre enregistrement SPF au qualifieur “-all” ?!?

DKIM :

• Qu’est-ce que DKIM ? Configuration, vérification et monitoring.

DMARC :

• Badsender publie un livre blanc pour vous accompagner dans votre déploiement DMARC !
• Monitoring DMARC Badsender.com – Décembre 2020
• Monitoring DMARC Badsender.com – Octobre vs. Novembre 2020
• Délivrabilité email : Implémenter DMARC pour protéger vos domaines !

– – – – –

Photo by engin akyurt on Unsplash