Comment configurer l’authentification DMARC dans un environnement d’entreprise

Vous investissez beaucoup dans la protection de votre réputation d’expéditeur dans le cadre du déploiement de vos campagnes email, mais qu’en est-il de votre environnement d’entreprise ? Ne mérite-t-il pas une protection contre la fraude similaire à celle que vous avez mise en œuvre pour vos emails transactionnels et/ou à teneur marketing ? Pour devenir un porte-drapeau de la lutte contre la fraude, vous pouvez commencer par sensibiliser votre société aux normes d’authentification SPF, DKIM et DMARC.

La configuration d’un enregistrement DMARC pour un environnement de routage doit respecter les mêmes principes d’implémentation de base. Configurez-le dans un premier temps en mode de surveillance (monitor) avant de passer successivement au mode de quarantaine (quarantine) et au mode de rejet (reject), lequel empêchera les emails frauduleux d’atteindre les boîtes de réception et le dossier Courriers indésirables.

Sachez par ailleurs qu’un environnement d’entreprise demande parfois une période de surveillance plus longue, surtout s’il implique plusieurs expéditeurs tiers dont vous n’avez peut-être pas connaissance. Ainsi, il se peut que les emails liés aux régimes de prestations des salariés et de retraite et/ou au système de gestion de temps soient envoyés par plusieurs MTA (Message Transfer Agent) tierces qui utilisent votre domaine d’envoi. Dès lors, consacrez un temps suffisant à l’examen de vos rapports DMARC pour être certain d’avoir identifié l’ensemble des adresses IP et des domaines autorisés.

Bien que chaque enregistrement DMARC varie selon l’environnement d’entreprise, l’exemple suivant devrait vous être utile pour configurer le vôtre.

  1. Imaginons que vous soyez le propriétaire du domaine exemple.com.
  2. WageWorks est un expéditeur tiers autorisé à envoyer des emails pour votre compte, mais à partir de ses propres MTA.
  3. Vous l’avez autorisé à envoyer des emails à partir du domaine wage.exemple.com, qui apparaîtra dans ses en-têtes d’email From: et Return-Path:
  4. WageWorks crée et publie un enregistrement SPF pour le domaine wage.exemple.com sur son serveur DNS.
  5. Mettez ensuite à jour l’enregistrement SPF du domaine exemple.com afin qu’il répertorie les adresses IP de WageWorks.
  6. Puis, créez une paire de clés privée/publique DKIM. Vous communiquez la clé privée à WageWorks et vous publiez la clé publique dans le fichier de la zone wage.exemple.com.
  7. C’est à vous, et non à WageWorks, qu’il revient de créer l’enregistrement DMARC car ce dernier couvrira à la fois exemple.com et wage.exemple.com lorsque vous configurerez l’enregistrement DMARC ci-dessous. Assurez-vous que WageWorks ne crée pas d’enregistrement DMARC de son côté, surtout si vous implémentez des règles différentes.
  8. Créez ensuite une entrée DNS pour le fichier de zone :
    _dmarc.exemple.com
  9. L’enregistrement DMARC se présentera comme suit :
    v=DMARC1; p=none; rua=mailto:[email protected]
  • L’enregistrement DMARC doit toujours commencer par la balise « v » (version) puisqu’elle est obligatoire.
  • Attribuez la valeur « none » (mode de surveillance) à la balise « p » (règles).
  • Demandez à recevoir dans un premier temps les rapports cumulés (balise « rua ») étant donné que les rapports d’investigation numérique (balise « ruf ») sont généralement difficiles à interpréter en raison du volume considérable de données qu’ils contiennent.
  • Si vous souhaitez que WageWorks reçoive également les rapports, ajoutez son adresse email à l’enregistrement de sorte qu’il se présente comme suit :
    v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:[email protected],mailto:[email protected]

A ce stade, vous vous demandez peut-être s’il sera possible d’aligner vos identifiants de domaine dans la mesure où exemple.com et wage.exemple.com ne sont pas exactement identiques. En fait, ils sont considérés comme étant « alignés » par défaut. Cela peut paraître confus au premier abord mais laissez-moi vous expliquer : les balises DMARC facultatives « aspf » et « adkim » peuvent être modifiées pour « forcer » le désalignement de domaines lors de l’exécution des contrôles SPF et DKIM. Si ces balises avaient la valeur « s » (mode strict), les emails de WageWorks échoueraient au contrôle DMARC car les domaines exemple.com et wage.exemple.com ne seraient pas considérés comme étant alignés. En revanche, si vous utilisez le paramètre par défaut « r » (mode souple), les domaines sont jugés « alignés ». Comme, de toute façon, les balises « aspf » et « adkim » sont facultatives et que nous souhaitons conserver leurs valeurs par défaut, il n’est pas nécessaire de les inclure dans l’enregistrement DMARC.

N’hésitez pas à nous faire part de cas concrets auxquels vous auriez été confronté dans votre environnement d’entreprise.

minute read

Popular stories

Products

BriteVerify

La vérification des emails par BriteVerify garantit l'existence d'une adresse email en temps réel

DemandTools

L'outil n° 1 mondial de la qualité des données utilisé par des milliers d'administrateurs Salesforce satisfaits

GridBuddy Cloud

L'expérience utilisateur la plus efficace de l'écosystème Salesforce

Return Path

Solution de délivrabilité d'échelle internationale pour gérer l'optimisation des programmes d'email marketing

Trust Assessments

Une nouvelle solution révolutionnaire pour évaluer la qualité des données Salesforce

Solutions

Validity for Email

Optimisez votre placement en boîte de réception et assurez-vous d'atteindre plus d'abonnés grâce à des données propres et directement exploitables.

Validity for Data Management

Avec des outils conçus pour augmenter la productivité et contrôler les risques liés à la gestion du pipeline en temps réel, offrez à vos commerciaux l'opportunité de gagner quotidiennement de précieuses heures de travail

Validity for Sales Productivity

Simplifiez la gestion de vos données, améliorez leur qualité et l’utilisation du CRM