Depuis les annonces et les exigences de Google & Yahoo, avoir un enregistrement DMARC est devenu la base et peut vite amener des problématiques de délivrabilité s’il est mal géré ! Je vous propose dans cet article 5 conseils pour bien gérer votre enregistrement DMARC sur vos domaines afin d’éviter qu’il impacte négativement la bonne livraison de vos emails.
Conseil #01 : Déployer son enregistrement DMARC !
Pour bien gérer DMARC, la première chose à faire est d’avoir un enregistrement DMARC présent directement ou indirectement sur tous vos domaines et ce pour trois bonnes raisons !
- La première bonne raison : Google et Yahoo exigent que chaque domaine expéditeur possède un enregistrement DMARC (pour le moment, uniquement pour les expéditeurs de masse › + 5000 emails/jour sur le domaine racine incluant aussi tous ses sous-domaines) ;
- La seconde bonne raison : DMARC offre la possibilité aux annonceurs d’avoir des rapports d’activité de leur nom de domaine (un domaine racine et ses sous-domaines) ;
- La troisième bonne raison : DMARC donne la possibilité de lutter contre le phishing en indiquant quoi faire avec un email qui ne serait pas conforme avec DMARC (cf. enregistrements SPF et DKIM non valide ou non alignés), c’est à dire soit le mettre en courrier indésirable, soit le rejeter !
› Exemple d’un enregistrement DMARC identifié sur le domaine avec le validateur de Dmarcian :
Great Job! You have a valid DMARC record that provides visibility into the entirety of your email program(s) and helps ensure you meet email sending best practices.
› Exemple d’un enregistrement DMARC non identifié sur le domaine avec le validateur de Dmarcian :
We were unable to find a DMARC record. As a result, this domain is not protected against abuse and likely does not meet the new Google and Yahoo sender requirements.
Conseil #02 : Déclarer correctement son enregistrement DMARC !
Il n’y a pas 50 façons pour déclarer un enregistrement DMARC sur son nom de domaine ! Par contre, quelques règles sont toutefois à respecter pour que l’enregistrement soit bien valide :
- DMARC se déclare dans un enregistrement DNS de type TXT ;
- DMARC se déclare sur le nom d’hôte (ou zone ou sous-domaine) _dmarc du domaine (ou sous-domaine);
- Il ne doit y avoir qu’un seul enregistrement DMARC par domaine ;
- La politique de sécurité doit être écrite en minuscule pour éviter toute ambiguïté ;
- Les tags v (pour version) et p (pour la politique de sécurité) sont obligatoires et doivent se trouver dans cet ordre ;
- …
C’est une liste non-exhaustive des problèmes que j’ai pu rencontrer lors de mes audits. Le site officiel de DMARC liste beaucoup plus d’erreurs quant à la déclaration de DMARC.
› Exemple de déclaration valide pour un enregistrement DMARC :
_dmarc.badsender.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@badsender.com;"
› Exemple de déclaration non valide pour un enregistrement DMARC :
badsender.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@badsender.com;"
Conseil #03 : Définir sa politique de sécurité DMARC !
La politique de sécurité DMARC consiste à dire aux serveurs distants (qui sont capables d’interpréter ces politiques) quoi faire en cas de non-conformité d’un email. À ce jour, il n’existe que TROIS valeurs possibles qui s’appliqueront au domaine où DMARC sera implémenté (p=) ou à tous ses sous-domaines (sp=) :
- La policy none (ou p=none) : Aucun traitement de l’email non-conforme ne sera fait, l’email pourra être délivré en boite de réception ou en spam.
- La policy quarantine (ou p=quarantine) : L’email non-conforme sera délivré en courrier indésirable.
- La policy reject (p=reject) : L’email non-conforme ne sera pas délivré et un bounce sera envoyé à l’expéditeur.
Toute autre déclaration de policy amènera chez les FAI / Webmails des comportements différents :
- Gmail : Transforme la valeur existante par none (dmarc=pass p=NONE sp=NONE) ;
- Microsoft : Produit comme résultat une erreur permanente (dmarc=permerror) ;
- Yahoo : Produit un résultat inconnu (dmarc=unknown) ;
- La Poste : Ignore l’enregistrement (dmarc=none reason= »No policy found »).
› Exemple de politique de sécurité valide pour un enregistrement DMARC :
v=DMARC1; p=reject; rua=mailto:dmarc@badsender.com;
› Exemple de politique de sécurité non valide pour un enregistrement DMARC :
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
v=DMARC1; p=policy; rua=mailto:dmarc@badsender.com;
Petit warning sur les domaines BtoB, j’ai déjà pu remarquer que sur certains domaines étaient beaucoup sévères et refusaient tout email (avec un bounce bien définit) ayant un enregistrement DMARC non valide !
554 5.7.5 Permanent error evaluating DMARC policy
Conseil #04 : Définir son attribut RUA !
Avoir DMARC c’est bien… Avec une politique de sécurité restrictive c’est mieux ! Mais la cerise sur le gâteau serait de monitorer les rapports d’authentification envoyés par tout organisme supportant DMARC. Et pour cela, il faudra déclarer dans son enregistrement DMARC un attribut RUA (Reporting URI for Aggregate data) accompagné d’une adresse email (sans oublier le mailto) qui permettra de recevoir tous les rapports agrégés de votre domaine expéditeur.
› Exemple de déclaration RUA valide appartenant au domaine badsender.com :
v=DMARC1; p=reject; rua=mailto:dmarc@badsender.com;
› Exemple de déclaration RUA non valide appartenant au domaine badsender.com :
v=DMARC1; p=reject; rua=dmarc@badsender.com;
Je fais tout de même un petit warning sur l’utilisation de l’adresse email qui recevra les rapports DMARC. Si vous utilisez un domaine externe au domaine expéditeur, celui-ci doit paramétrer un enregistrement DMARC spécial (cf. de confiance) qui lui permettra de recevoir tous les rapports d’authentification pour un domaine expéditeur. Sans ce paramétrage, le nombre de rapports reçus sera très limité, voir nul.
Dans l’exemple ci-dessous, Google n’autorise pas (et n’aime pas d’ailleurs) pleinement la réception des rapports DMARC avec une adresse gmail.com, ce qui aura pour effet de limiter très fortement la réception des rapports dans votre boite mail Gmail…
v=DMARC1; p=reject; rua=mailto:dmarc@gmail.com;
Conseil #05 : Utiliser un outil pour monitorer ses rapports !
Si vous avez l’intention de monitorer vos rapports DMARC (c’est trop cool), il vous faudra vous équiper ! Les rapports DMARC sont au format XML et donc peuvent vite être très compliqué à lire / déchiffrer puisqu’ils vont contenir des milliers de lignes. L’utilisation d’une plateforme vous permettra de lire vos rapports simplement et de voir si vous avez des problèmes d’authentification ou d’utilisation frauduleuse ou malveillante !
Voici une liste (non-exhaustive que je remplirai au fur et à mesure) d’outils disponibles actuellement sur le marché :
| Redsfit Ondmarc | Dmarcian | Dmarc Advisor | Power Dmarc | Everest |
| Easy Dmarc | Dmarc Analyser | Dmarc.fr | Uri Ports | Dmarc Eye |
| Merox | Dmarc Digests | Dmarcly | Postmark Dmarc | EmailConsul |
| Valimail | Glock Apps | Mailer Check |
Par contre, ils ont tous des prix et des options très variables. À voir suivant les besoins de l’annonceur.
Conclusion
Avec ses 5 Conseils, vous pourrez aisément mettre en place DMARC sans effet indésirable sur la bonne livraison de vos emails.
Si toutefois vous n’avez pas la capacité de suivre ses flux, n’hésitez pas à faire appel à nos services 🙂
Lors d’un prochain article sur DMARC, je vous parlerai des différentes stratégies de déploiement à mettre en place en fonction de vos domaines (et sous-domaines) mais également la gestion des politiques de sécurité à appliquer. Bref, tout un programme 🙂
Vous pouvez retrouver ci-dessous nos différents articles dédiés aux authentifications emails :
- Articles dédiés à l’authentification SPF :
- Articles dédiés à l’authentification DKIM :
- Articles dédiés à l’authentification DMARC :
- Articles dédiés à l’authentification BIMI :
