Comment déployer DMARC pour le traitement des e-mails entrants
Avec l'adoption croissante de DMARC, de plus en plus d'utilisateurs envisagent de l'utiliser pour filtrer leurs propres e-mails. Nous avons rédigé cet article pour expliquer comment implémenter le « DMARC entrant ».
Le volume d'e-mails est considérable et DMARC est encore en cours d'adoption. Lorsque vous commencerez à filtrer les e-mails entrants à l'aide de DMARC, vous découvrirez deux points importants :
- Les e-mails proviennent de toutes sortes d'endroits différents.
- Des e-mails légitimes utilisant votre domaine peuvent provenir de l'extérieur.
L'application des politiques DMARC (y compris la politique de votre propre domaine !) à vos e-mails entrants sans tenir compte des points ci-dessus entraînera le blocage d'e-mails légitimes. Cela garantira le mécontentement des utilisateurs.
E-mails provenant de différents endroits
Lorsque les e-mails circulent de « A » vers « B », le filtrage est simple et tout fonctionne sans problème.

Lorsque les e-mails circulent de « A » vers « F » en route vers « B », c'est là que le traitement entrant devient délicat.

Lors du traitement des e-mails entrants, vous recevrez des e-mails prétendant provenir de « A », et « A » aura une politique DMARC de rejet en place. Malheureusement, cet e-mail arrivera de « F » avant de vous parvenir (« B »). Le problème est que « F » pourrait compromettre votre capacité à utiliser DMARC pour déterminer la légitimité de l'e-mail.
SPF ne fonctionnera pas
Lorsque les e-mails passent par une étape intermédiaire, la liste des serveurs autorisés que SPF vérifie n'inclura pas cette étape intermédiaire. Dommage.
DKIM sera rompu
Si « F » modifie le contenu de l'e-mail, DKIM sera rompu. Cela se produit lorsque les listes de diffusion ajoutent des pieds de page, ou lorsqu'une machine ajoute quelque chose comme « Analysé par Blahsoft pour les virus ! » Double dommage.
« F » se produit sur Internet. Le transfert, les listes de diffusion (alias listservs), les alias de groupe d'e-mails, les services d'analyse… ces éléments sont susceptibles d'affecter aujourd'hui les e-mails qui transitent par votre infrastructure.
Pour gérer « F »
- Identifiez les « F » qui affectent votre capacité à vérifier DMARC.
- Créez des exceptions à votre traitement afin que DMARC ne soit pas appliqué aux flux d'e-mails légitimes qui seraient autrement altérés par un « F ».
- Si possible, informez « F » qu'il existe une meilleure façon de transférer les e-mails.
E-mails externes légitimes sur votre domaine
Lorsque vous avez la possibilité de créer des exceptions, la gestion du deuxième point est similaire à celle du premier. Identifiez les sources d'e-mails légitimes mais non conformes qui utilisent votre domaine et créez des exceptions pour ces sources.
Si la source d'e-mails utilise votre domaine et communique uniquement avec vos propres utilisateurs, vous pouvez la mettre sur liste blanche dans votre propre traitement entrant et le problème est résolu. Si la source envoie des e-mails à d'autres organisations, vous devrez la rendre conforme à DMARC. Même si vous l'ajoutez à votre propre liste blanche, il n'est pas judicieux de compter sur d'autres personnes pour identifier cette source comme une exception dans leur propre traitement entrant.
Plan d'implémentation entrant
Cela étant dit, voici un plan d'implémentation pour le traitement entrant.
Tout d'abord, configurez le traitement entrant pour vérifier les résultats DMARC. Ne faites rien avec ces résultats, activez simplement la vérification afin de disposer de données utiles pour commencer.
Ensuite, configurez le traitement entrant pour générer à la fois des rapports agrégés basés sur XML et des rapports d'échec/d'investigation individuels. Cependant, ne les envoyez pas aux propriétaires de domaines. À ce stade, vous collectez toujours vos propres données.
Analysez les rapports que vous avez générés. Les rapports couvriront tous les domaines trouvés dans les e-mails entrants que vous avez traités, y compris vos propres domaines. Pour vos domaines, identifiez les services et partenaires qui utilisent votre domaine pour envoyer des e-mails à vos propres utilisateurs. Pour les autres domaines, identifiez les sources légitimes d'e-mails qui ne respectent pas la signature DKIM.
Sur la base de l'analyse ci-dessus, créez des exceptions si nécessaire et mettez vos propres sources d'e-mails en conformité avec DMARC. Si possible, incluez dans les rapports agrégés basés sur XML si des exceptions sont appliquées. Cela aide les autres propriétaires de domaines à comprendre comment vous traitez leurs e-mails, y compris les e-mails qui passent par un « F ».
Lorsque vous êtes certain que toutes les exceptions nécessaires sont en place et que toutes les sources d'e-mails de votre domaine envoient des e-mails conformes à DMARC :
- Configurez le traitement entrant pour agir sur les résultats DMARC, et
- configurez le traitement entrant pour envoyer des rapports agrégés basés sur XML aux propriétaires de domaines. L'envoi ou non de rapports d'échec/d'investigation individuels aux propriétaires de domaines est une décision politique qui doit être prise par votre propre organisation.
Le support des fonctionnalités permettant de suivre le plan de mise en œuvre ci-dessus varie considérablement selon les fournisseurs de messagerie.
Les informations et l'article ci-dessus ont été inspirés par Franck Martin et son travail chez LinkedIn pour mettre en place le traitement DMARC entrant. Merci Franck !