DMARC : le gardien de l'authentification e-mail
DMARC (Domain-based Message Authentication, Reporting & Conformance) est le protocole qui complète le trio de l'authentification e-mail. Tandis que SPF et DKIM sont des mécanismes d'authentification, DMARC est une politique : il indique aux serveurs récepteurs ce qu'il faut faire lorsqu'un e-mail échoue à l'authentification. Sans DMARC, un e-mail qui échoue au SPF ou au DKIM pourrait tout de même être livré — la décision est entièrement laissée au serveur destinataire. Avec DMARC, le propriétaire du domaine reprend le contrôle.
DMARC vérifie également l'alignement du domaine : il contrôle que le domaine dans l'en-tête From (celui que l'utilisateur voit) correspond au domaine authentifié par SPF ou DKIM. Ceci est fondamental car un attaquant pourrait configurer SPF et DKIM pour son propre domaine, mais envoyer des e-mails avec votre domaine dans le champ From. L'alignement DMARC empêche ce scénario, comblant la faille entre l'authentification technique et l'identité visible.
Les trois politiques DMARC
La mise en œuvre de DMARC doit toujours être progressive. Démarrer directement avec p=reject est risqué : vous pourriez bloquer des e-mails légitimes envoyés par des services que vous n'avez pas encore authentifiés avec SPF/DKIM. La stratégie recommandée est : commencer avec p=none pour collecter des données (généralement 2 à 4 semaines), analyser les rapports pour identifier toutes les sources d'e-mails légitimes, configurer SPF et DKIM pour chacune, puis passer à p=quarantine avec un pct faible (25-50 %), augmenter progressivement, et enfin activer p=reject.
Rapports DMARC : la visibilité qui vous manquait
L'un des avantages les plus sous-estimés de DMARC réside dans les rapports agrégés (rua). Chaque serveur qui reçoit des e-mails de votre domaine envoie des rapports quotidiens au format XML montrant : combien d'e-mails ont été reçus, depuis quelles IP, s'ils ont réussi ou échoué aux vérifications SPF/DKIM, et quelle action a été appliquée. Ces rapports sont une mine d'informations : ils révèlent des services qui envoient des e-mails en votre nom que vous avez peut-être oubliés, des tentatives d'usurpation de votre domaine, et des problèmes de configuration.
Pour analyser les rapports DMARC (qui sont en XML brut et difficiles à lire), il existe des services dédiés qui les agrègent dans des tableaux de bord lisibles. Vous pouvez aussi commencer par une lecture manuelle des rapports les plus significatifs. L'élément clé à surveiller est le ratio entre e-mails authentifiés et non authentifiés : si vous constatez que de nombreux e-mails légitimes échouent, vous devez mettre à jour SPF ou DKIM avant de durcir la politique.
Vérifier et générer votre enregistrement DMARC
Notre DMARC Lookup analyse l'enregistrement DMARC de votre domaine en affichant la politique, les paramètres d'alignement, les adresses pour les rapports et d'éventuelles erreurs de syntaxe. Si vous ne disposez pas encore d'un enregistrement DMARC, utilisez le Générateur DMARC pour en créer un personnalisé avec les bonnes options. L'outil génère l'enregistrement TXT prêt à être inséré dans le DNS.
N'oubliez pas que l'enregistrement DMARC doit être inséré en tant que TXT sur _dmarc.votredomaine.com. Une erreur courante est de l'insérer à la racine du domaine ou avec un nom d'hôte incorrect. Vérifiez également que SPF et DKIM sont correctement configurés avant d'activer DMARC : sans au moins l'un des deux protocoles d'authentification, DMARC n'a pas de base sur laquelle opérer. Utilisez SPF Lookup et DKIM Lookup pour une vérification complète.
Enfin, prêtez attention à la politique pour les sous-domaines (sp=). Si elle n'est pas spécifiée, les sous-domaines héritent de la politique du domaine parent. Mais si vos sous-domaines n'envoient pas d'e-mails, il est recommandé de définir sp=reject pour empêcher qu'ils soient utilisés pour du spoofing, même si la politique du domaine principal est encore en phase de surveillance avec p=none.