Configurer SPF, DKIM et DMARC contre l’usurpation, sans bloquer les vrais e-mails

## Décider qui valide les changements DNS de l’e-mail et comment les annuler Traitez l’authentification des e-mails comme une infrastructure partagée. La modification d’un enregistrement peut affecter les e-mails transactionnels, les systèmes d’assistance, le marketing, les outils internes et les tiers qui utilisent le même domaine. - Identifiez les domaines et sous-domaines d’envoi, les domaines visibles du champ From et les flux de messagerie essentiels inclus dans le périmètre. - Désignez un responsable du domaine et un opérateur DNS autorisé. - Séparez les personnes qui proposent, examinent, approuvent, publient, valident et surveillent chaque changement. - Consignez les valeurs DNS actuelles, leur durée de vie, les dépendances et une valeur de retour en arrière testée. - Planifiez les changements lorsque les responsables des flux critiques peuvent observer les résultats. - Ne modifiez pas le DNS de production sans autorisation explicite et sans plan de récupération. - Suspendez le renforcement lorsque l’inventaire des expéditeurs ou les preuves de responsabilité sont incomplets. ## Recenser chaque service qui envoie des e-mails avec votre domaine Établissez l’inventaire des expéditeurs avant d’écrire les enregistrements d’authentification. Oublier un seul service légitime peut conduire l’application de la politique à bloquer des e-mails souhaités, tandis qu’une autorisation obsolète agrandit la surface d’usurpation. - Répertoriez chaque plateforme, application, serveur de relais, appareil et fournisseur qui envoie avec le domaine. - Consignez l’expéditeur de l’enveloppe, le domaine visible du champ From, le domaine de signature, le détenteur de l’adresse IP et l’équipe responsable. - Distinguez les expéditeurs directs des chemins de transfert, de listes de diffusion et de passerelles. - Indiquez les sources qui peuvent signer avec DKIM et celles qui dépendent de l’alignement SPF. - Retirez les sources désaffectées seulement après avoir confirmé qu’elles n’envoient plus de trafic légitime. - Envisagez d’isoler sur des sous-domaines dédiés les groupes présentant des risques ou des responsabilités distincts. - Maintenez l’inventaire lié aux enregistrements de changements et aux rapports d’authentification. ## Écrire un seul enregistrement SPF correct qui couvre tous les expéditeurs SPF autorise les systèmes qui peuvent utiliser un domaine comme expéditeur de l’enveloppe. Il évalue la source qui établit la connexion ; il ne signe pas le contenu et, à lui seul, n’authentifie pas l’adresse visible du champ From. - Publiez exactement une politique SPF pour chaque nom d’hôte qui en a besoin. - Regroupez tous les expéditeurs légitimes dans cette politique au lieu de créer des enregistrements SPF en double. - Utilisez uniquement les mécanismes et inclusions pris en charge par les services d’envoi responsables. - Maintenez les mécanismes qui interrogent le DNS dans la limite SPF de 10 pendant l’évaluation. - Retirez les inclusions redondantes et les expéditeurs inutilisés avant d’approcher la limite. - Choisissez délibérément le mécanisme all final et ne le rendez plus strict qu’après avoir prouvé la couverture. - Validez la syntaxe, les chemins d’expansion, le nombre de requêtes et les résultats d’expéditeurs représentatifs. ## Activer la signature DKIM pour chaque service d’envoi DKIM permet à un expéditeur de signer certaines parties du message avec une clé privée, tandis que les destinataires récupèrent dans le DNS la clé publique correspondante. Une signature réussie montre que le contenu signé est resté intact pendant le transit et identifie le domaine de signature. - Générez un sélecteur et une paire de clés distincts selon la méthode prise en charge par chaque expéditeur. - Préférez des clés robustes, telles que des clés de 2048 bits, lorsque l’expéditeur et le service DNS les prennent en charge. - Publiez l’enregistrement exact de la clé publique à l’emplacement du sélecteur indiqué par l’expéditeur. - Protégez les clés privées et ne les placez jamais dans le DNS, les demandes d’assistance, les documents partagés ou les journaux. - N’activez la signature qu’après la résolution correcte de l’enregistrement public. - Envoyez un véritable message de test et vérifiez le sélecteur, le domaine de signature, le résultat de la signature et la couverture des en-têtes. - Planifiez une rotation des clés fondée sur les sélecteurs afin de valider une nouvelle clé avant de retirer l’ancienne. ## Démarrer DMARC en simple observation et lire ses rapports DMARC vérifie si le domaine visible du champ From est aligné avec une identité SPF ou DKIM validée, puis applique la politique publiée du responsable du domaine. Une authentification réussie sans alignement peut tout de même échouer à DMARC. - Confirmez que chaque flux légitime est aligné par SPF, DKIM ou les deux. - Déterminez si un alignement assoupli ou strict convient à la structure et au risque du domaine. - Publiez un enregistrement DMARC sur le nom d’hôte requis par la politique, avec une destination de rapport autorisée. - Commencez par une politique de surveillance pendant que vous découvrez les sources légitimes et non autorisées. - Protégez les boîtes de réception des rapports et limitez leur accès, car les rapports peuvent révéler des détails sur l’infrastructure. - Classez les échecs par source, résultat d’authentification, alignement, volume et responsable opérationnel. - Ne passez pas à l’application de la politique tant que les flux légitimes importants ne sont pas tous recensés. ## Durcir DMARC par étapes sans bloquer les vrais e-mails Ne passez de l’observation à la mise en quarantaine et au rejet que lorsque les preuves montrent que les e-mails légitimes restent alignés. L’application de la politique est une décision de maîtrise des risques, et non une tâche ponctuelle de formatage du DNS. - Définissez pour chaque étape des critères de taux de réussite, de source inconnue et d’incidence sur l’activité. - Corrigez les échecs légitimes avant de renforcer la politique. - Utilisez un pourcentage limité d’application lorsque cette fonction est prise en charge et utile à la réduction des risques. - Après chaque changement, surveillez les rapports agrégés, les erreurs de livraison, les incidents d’assistance et l’état des flux critiques. - Gardez une politique documentée de retour en arrière prête pendant toute la transition. - Obtenez l’approbation d’un responsable avant de renforcer l’application ou de modifier le mode d’alignement. - Arrêtez-vous et enquêtez si des e-mails légitimes sont rejetés, mis en quarantaine ou deviennent inopinément non authentifiés. ## Vérifier les enregistrements DNS et de vrais e-mails de test après chaque changement Confirmez à la fois la publication des enregistrements et le comportement réel des e-mails. Un enregistrement DNS syntaxiquement valide ne prouve pas que chaque expéditeur l’utilise ni que l’alignement DMARC réussit. - Interrogez le DNS faisant autorité sur SPF, les sélecteurs DKIM et DMARC après la propagation. - Recherchez les enregistrements en double, les valeurs tronquées, les noms d’hôte erronés et les politiques héritées involontaires. - Envoyez des tests par chaque chemin représentatif de production vers plusieurs environnements de réception. - Examinez dans les en-têtes des messages SPF, DKIM, DMARC, les domaines, les sélecteurs et les résultats d’alignement. - Testez les messages ordinaires et les variantes importantes, notamment les e-mails transférés ou relayés. - Consignez le chemin du test, l’horodatage, le résultat, les preuves et l’examinateur. - Répétez la validation après tout changement d’expéditeur, de DNS, de routage ou de signature. ## Trouver la cause des échecs SPF, DKIM ou DMARC à partir de preuves Établissez le diagnostic à partir des résultats d’authentification, des réponses DNS, des en-têtes de messages et de l’historique des changements. Ne continuez pas à modifier les enregistrements jusqu’à ce qu’un test réussisse par hasard. - Pour les erreurs permanentes de SPF, examinez les politiques en double, la syntaxe, les inclusions récursives et la limite de 10 requêtes. - Pour les échecs de DKIM, examinez les noms de sélecteur, les données de clé copiées, l’état de la signature, la canonisation et les modifications du message. - Pour les échecs de DMARC, comparez le domaine visible du champ From aux identités SPF et DKIM. - Pour un e-mail légitime bloqué, identifiez la source exacte avant d’assouplir la politique. - Annulez le plus petit changement responsable lorsqu’un flux de production est affecté. - Après chaque correction, testez de nouveau le chemin défaillant et un chemin témoin non affecté. - Conservez les preuves de la cause et de la correction pour les changements futurs. ## Surveiller les rebonds et l’arrivée en spam, pas seulement l’authentification SPF, DKIM et DMARC réduisent l’usurpation d’identité et satisfont des contrôles importants des destinataires, mais ne garantissent pas l’arrivée en boîte de réception. La réputation et la réaction des destinataires restent des signaux distincts. - Surveillez les taux de réussite de l’authentification ainsi que les rejets, les reports, le classement en courrier indésirable, les plaintes et les retours en erreur. - Tenez des listes de destinataires exactes et retirez les adresses invalides ou qui échouent durablement. - Maintenez le volume et les habitudes d’envoi en cohérence avec la réputation établie du domaine. - Utilisez une identité d’expéditeur honnête, un contenu pertinent et un moyen clair d’arrêter les e-mails non essentiels. - Étudiez les changements soudains par domaine, flux, destinataire, contenu et événement de déploiement. - Ne considérez ni l’augmentation progressive du volume d’envoi ni la réussite d’un contrôle d’authentification comme la preuve d’une bonne réputation. - Suspendez les flux risqués lorsque les preuves montrent des dommages persistants. ## Revoir les expéditeurs et changer les clés DKIM à intervalle fixe L’authentification se dégrade lorsque les services changent, les clés vieillissent, les responsables partent ou de nouveaux expéditeurs contournent l’examen. Entretenez-la comme un contrôle récurrent plutôt que comme un projet de configuration achevé. - Examinez l’inventaire des expéditeurs, les enregistrements DNS, les rapports DMARC et les responsabilités selon une fréquence définie. - Faites tourner les sélecteurs et les clés DKIM avec une période de chevauchement qui préserve les signatures valides. - Vérifiez de nouveau le nombre de requêtes SPF chaque fois qu’une inclusion ou un service d’envoi change. - Suivez les changements de politique, les approbations, les valeurs publiées, les preuves de validation et les résultats des retours en arrière. - Déclenchez des alertes en cas de nouvelles sources, de baisse des taux de réussite, de rapports manquants et d’échecs soudains d’alignement. - Retirez les autorisations obsolètes après avoir confirmé que le flux concerné est inactif. - Réévaluez les limites des sous-domaines et l’application de la politique lorsque le risque, le volume ou l’usage professionnel change.