L’email reste le premier vecteur d’attaque cybercriminelle : selon l’ANSSI, 90 % des cyberattaques commencent par un email frauduleux, et près de la moitié des entreprises françaises ont subi une tentative de phishing usurpant leur propre nom de domaine au cours des douze derniers mois. Pour un dirigeant de PME qui découvre que des clients reçoivent des factures fausses signées de son adresse, le préjudice ne se limite pas à la fraude ponctuelle : c’est la confiance de tout le portefeuille qui vacille, et l’image de marque qui se trouve entachée pour longtemps. La parade technique existe pourtant depuis plus de quinze ans, sous la forme d’une triade d’enregistrements DNS appelés SPF, DKIM et DMARC. Leur configuration correcte rend l’usurpation de domaine techniquement très difficile, et leur surveillance continue alerte le marchand au premier signal d’attaque. Chez Propuls’Lead, nous aidons les PME à déployer cette protection et à la maintenir dans la durée, et nous intégrons un agent IA veilleur qui décode les rapports DMARC à la place des équipes techniques.
Comprendre SPF, DKIM et DMARC : les trois piliers de l’authentification email
SPF (Sender Policy Framework) est le premier enregistrement DNS à poser. Il déclare quels serveurs sont autorisés à envoyer des emails au nom de votre domaine. Quand un destinataire reçoit un email prétendant venir de contact@votre-entreprise.fr, son serveur de réception interroge le SPF de votre-entreprise.fr et vérifie que l’IP de l’expéditeur figure dans la liste autorisée. Un SPF bien configuré ressemble à : v=spf1 include:_spf.google.com include:sendgrid.net -all. Le tilde ou le tiret final indique au destinataire quoi faire des emails non autorisés (les marquer ou les rejeter).
DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque email sortant. Le serveur expéditeur signe l’email avec une clé privée, et le destinataire vérifie la signature avec la clé publique publiée dans le DNS. Si l’email a été modifié en chemin ou si l’expéditeur n’a pas accès à la clé privée, la signature échoue. DKIM ne se contente donc pas d’identifier l’expéditeur, il garantit aussi l’intégrité du message. DMARC (Domain-based Message Authentication, Reporting and Conformance) chapeaute les deux précédents. Il indique au destinataire quoi faire si SPF ou DKIM échoue (none, quarantine, reject), et il déclenche l’envoi de rapports quotidiens vers une adresse dédiée pour identifier toutes les tentatives d’usurpation. Notre article sur WordPress et emails transactionnels, configurer SMTP pour que vos emails arrivent en boîte revient sur la délivrabilité côté envoi.
Mettre en œuvre l’authentification email étape par étape
Le déploiement SPF, DKIM, DMARC se conduit en cinq étapes accessibles à toute PME équipée d’un panneau DNS et d’un fournisseur d’email principal. Étape un : inventaire des services qui envoient au nom du domaine. On liste Google Workspace ou Microsoft 365 pour la messagerie nominative, l’outil d’email marketing (Brevo, Mailchimp, Klaviyo), la solution de signature électronique (DocuSign, Yousign), le CRM (HubSpot, Salesforce), les notifications transactionnelles WordPress ou Shopify. Cet inventaire conditionne la suite : un service oublié fera échouer ses propres emails dès que DMARC sera en mode reject.
Étape deux : configuration SPF. On crée un enregistrement TXT à la racine du domaine reprenant tous les services inventoriés (limite : 10 includes maximum, sinon on consolide). Étape trois : configuration DKIM. Chaque fournisseur d’envoi génère ses propres clés DKIM et fournit l’enregistrement TXT à publier (souvent sous forme google._domainkey ou k1._domainkey selon le service). Étape quatre : configuration DMARC en mode test. On publie un enregistrement TXT _dmarc.votre-domaine.fr avec p=none et une adresse rua=mailto:dmarc@votre-entreprise.fr pour recevoir les rapports. On laisse tourner pendant deux à quatre semaines pour observer les rapports sans rien rejeter. Étape cinq : montée en sévérité progressive. Après analyse des rapports, on passe à p=quarantine pendant deux semaines, puis à p=reject quand on est certain qu’aucun service légitime n’est filtré. Notre article sur WordPress et RGPD, les réglages et plugins pour être en conformité sans avocat revient sur les obligations adjacentes en matière de gouvernance des emails marketing.
Et avec un agent IA ?
La maintenance SPF, DKIM, DMARC bute sur deux écueils que l’agentification résout : les rapports DMARC arrivent quotidiennement en XML brut peu lisible, et toute modification d’un service tiers (changement d’IP d’un envoi marketing, ajout d’un nouveau CRM) peut casser silencieusement la chaîne d’authentification. Un agent IA veilleur reprend trois activités. Activité une : parsing quotidien des rapports DMARC reçus dans la boîte rua. L’agent IA décode les XML, agrège les volumes par source d’envoi, identifie les services légitimes mal configurés et signale les tentatives d’usurpation suspectes. Activité deux : surveillance proactive du DNS. L’agent IA interroge chaque semaine les enregistrements SPF, DKIM, DMARC et alerte sur tout changement non documenté ou tout enregistrement cassé. Activité trois : recommandation de durcissement. Quand les rapports montrent une chaîne stable depuis plusieurs semaines, l’agent IA recommande le passage de p=none à p=quarantine puis à p=reject avec un argumentaire chiffré.
L’agent IA en pratique s’appuie sur un modèle Claude Sonnet pour la rédaction des synthèses hebdomadaires, branché sur un parser DMARC open source (Postmark DMARC ou DMARCian via API) pour la lecture des XML, et sur un outil de monitoring DNS (Mailhardener, EasyDMARC, Valimail) pour la surveillance continue. Le prompt système cadre l’agent IA : « Tu es un agent IA spécialisé en sécurité email. Tu lis les rapports DMARC quotidiens, tu identifies les sources légitimes, tu signales les usurpations, tu recommandes les durcissements. Tu n’autorises jamais un changement de politique sans validation humaine. » L’orchestration se fait via n8n avec stockage des synthèses dans Notion et notification Slack en cas d’alerte. Chez Propuls’Lead, nous concevons et déployons les agents IA qui surveillent l’authentification email à la place de nos clients, dans le cadre de la méthodologie PROPULSE. Le gain mesurable observé sur les PME accompagnées se situe entre 4 et 6 heures économisées par mois sur la lecture des rapports, et un délai moyen de détection des attaques passé de quatre semaines à moins de 48 heures. Notre article sur sécuriser son site WordPress, 10 actions qui bloquent les attaques revient sur la sécurité périmétrique du site web.
Quand l’humain reprend la main
L’agent IA veilleur surveille et synthétise, mais trois décisions exigent une intervention humaine claire. Décision une : passage en mode reject. Couper le robinet aux emails non authentifiés peut bloquer un envoi légitime d’un fournisseur oublié, avec impact direct sur le business. L’agent IA recommande, mais l’équipe IT ou le dirigeant tranche après vérification que tous les services internes sont bien couverts.
Décision deux : gestion d’une attaque active. Si les rapports DMARC montrent une vague d’usurpation visant les clients du marchand, la réponse coordonnée (alerte aux clients, dépôt de plainte, signalement à la plateforme Pharos, communication de crise) relève d’un comité humain qui combine direction, juridique et communication. L’agent IA fournit les données techniques, mais ne pilote pas la réponse. Décision trois : ajout d’un nouveau service d’envoi. Quand le marketing décide d’utiliser un nouvel outil d’emailing, la mise à jour SPF et la génération DKIM doivent être validées par un humain compétent qui en mesure l’impact sur la chaîne existante. L’agent IA documente et applique, mais n’arbitre pas le choix de l’outil. Notre article sur politique de confidentialité, rédiger une page conforme avec un copilot juridique revient sur la même articulation entre exécution agentique et décision humaine.
Stack recommandée par Propuls’Lead
Pour agentifier la surveillance SPF, DKIM, DMARC d’une PME, nous recommandons une stack accessible et auditable. Côté monitoring DNS : EasyDMARC ou Mailhardener pour les rapports DMARC consolidés et l’interface de visualisation. Côté parsing : un workflow n8n qui récupère les rapports XML sur la boîte rua, les passe au modèle Claude Sonnet pour synthèse, et publie le résultat dans Notion. Côté alerting : un canal Slack dédié sécurité avec notification immédiate sur tout signal d’usurpation. Côté gouvernance : une revue mensuelle humaine pilotée par le DSI ou le dirigeant, avec validation des recommandations de durcissement proposées par l’agent IA. Côté sauvegarde : conservation de douze mois des rapports DMARC bruts pour traçabilité réglementaire et investigation post-incident. Sur les PME accompagnées avec ce dispositif, aucune n’a subi de campagne d’usurpation persistante depuis le passage en p=reject.