Pourquoi les e-mails de simulation de phishing atterrissent-ils dans les spams (et comment y remédier sans affaiblir la sécurité)

Si vos e-mails de simulation de phishing finissent dans les spams ou en quarantaine, vos résultats deviennent difficiles à croire.

Un taux de clics de 2 % peut vouloir dire que vos utilisateurs se sont améliorés. Ou bien que, dans une grande partie de l’entreprise, le message n’a jamais vraiment été vu. Ce n’est pas seulement un problème de reporting. C’est un problème de conception du programme. Ce guide s’adresse aux ingénieurs sécurité, aux administrateurs IT, aux RSSI et aux responsables conformité qui ont besoin d’une délivrabilité fiable pour leurs simulations sans faire de brèches dangereuses dans la sécurité mail.

Note de sécurité : cet article porte sur des simulations défensives et la mesure de la sensibilisation. Il ne contient pas d’instructions pour du phishing réel, du vol d’identifiants ou le contournement de contrôles de sécurité à des fins malveillantes.

La version courte

Si les e-mails de simulation de phishing vont dans les spams, la solution n’est généralement pas de « relâcher les filtres jusqu’à ce que tout arrive en boîte de réception ».

L’approche la plus sûre consiste à :

• utiliser un domaine ou sous-domaine dédié aux simulations
• faire en sorte que l’alignement SPF, DKIM et DMARC soit intentionnel
• garder des contenus et des chaînes de redirection propres
• distinguer la télémétrie de livraison de la télémétrie comportementale
• et, lorsque c’est nécessaire, utiliser un allowlisting chirurgical plutôt que des contournements larges

Ce dernier point est important. Un allowlisting trop large est risqué. Mais des règles étroites, bien documentées, liées à une IP d’envoi dédiée et à des identités d’expéditeur connues peuvent tout à fait constituer un contrôle pérenne raisonnable.

Pourquoi la délivrabilité des simulations de phishing se casse

Les échecs de délivrabilité sont rarement aléatoires. Ils sont généralement le résultat prévisible de la manière dont le programme a été monté.

1) SPF, DKIM ou DMARC ne sont pas alignés avec l’expéditeur visible

C’est la cause la plus fréquente.

Si le domaine que les utilisateurs voient dans le champ From ne correspond pas au domaine autorisé par SPF ou signé par DKIM, les systèmes de messagerie ont de bonnes raisons de se méfier. Microsoft et Google considèrent tous deux SPF, DKIM et DMARC comme des signaux centraux de confiance envers l’expéditeur, et tous deux insistent sur l’alignement avec le domaine de l’expéditeur visible.

Schémas d’échec courants :

• le domaine visible dans From n’est pas celui que vous avez réellement authentifié
• la signature DKIM est absente ou rattachée au mauvais domaine
• DMARC existe, mais l’alignement avec l’expéditeur visible n’a jamais été correctement testé
• des changements DNS ont été effectués, mais pas encore entièrement propagés ou validés avant le lancement de la campagne

2) La simulation utilise le domaine corporate principal

Utiliser le domaine principal de l’entreprise peut sembler plus réaliste, mais cela crée souvent des collisions inutiles.

Vous vous retrouvez à être testé contre les mêmes contrôles anti-spoofing, anti-usurpation et anti-abus qui sont là pour protéger ce domaine en production. Cela peut être pertinent dans certains programmes mûrs, mais ce n’est presque jamais le point de départ le plus propre.

Pour la plupart des équipes, un sous-domaine dédié aux simulations est le choix par défaut le plus sûr.

3) Le mauvais type d’allowlisting a été utilisé

L’allowlisting peut devenir un problème de sécurité, surtout quand les équipes font par exemple :

• un contournement global de la protection anti-phishing
• un allowlisting de vastes plages d’adresses IP de fournisseurs cloud
• l’exemption d’infrastructures d’envoi entières qu’elles ne contrôlent pas
• la suppression de l’analyse pour de larges catégories de mails

Mais ce n’est pas le seul modèle.

Il y a une grande différence entre des contournements larges et des règles de livraison chirurgicales. Si votre fournisseur envoie depuis une IP dédiée et un petit ensemble connu d’adresses ou de domaines d’expédition, un allowlisting étroitement borné peut être acceptable et même rester en place dans le cadre du paramétrage standard. La propre documentation de configuration d’AutoPhish décrit exactement ce modèle : les campagnes sont envoyées depuis un serveur SMTP/IP dédié et un ensemble défini d’adresses d’expéditeur, ce qui rend possibles des exceptions de filtrage précises sans recourir aux contournements massifs qui créent une vraie surface d’exposition.

4) Le contenu et les liens déclenchent les mêmes contrôles que ceux auxquels vous vous attendez pour protéger les utilisateurs

Les e-mails de simulation contiennent souvent :

• des liens de suivi
• des redirections
• un langage d’urgence
• des formulations proches des marques
• des appels à l’action de type connexion

Ce n’est pas automatiquement un problème. Mais cela veut dire que le message sera inspecté comme un courrier suspect. Si la simulation dépend du fait d’avoir l’air suffisamment douteuse pour battre vos propres contrôles, alors vous ne testez plus vraiment les utilisateurs. Vous testez si votre pile de sécurité attrape un contenu manifestement risqué.

5) Les données de livraison et les données comportementales sont mélangées

Si vous ne pouvez pas séparer clairement :

• envoyé
• délivré
• ouvert
• cliqué
• signalé

alors vos rapports vous induiront en erreur. Une faible métrique de campagne peut refléter un problème utilisateur. Ou un problème de routage. Ou une politique de quarantaine. Ou un filtrage spécifique au fournisseur de boîte mail. Ce sont des pistes de remédiation très différentes.

Une manière plus sûre d’améliorer la délivrabilité des simulations de phishing

Étape 1 : séparer l’envoi des simulations des e-mails métier habituels

Pour la plupart des organisations, le meilleur point de départ est :

• un domaine ou sous-domaine dédié aux simulations
• des enregistrements d’authentification dédiés
• un chemin d’envoi propre, facile à expliquer et à auditer
• aucune usurpation de véritables individus internes, sauf raison forte et revue

Cela réduit le rayon d’impact, limite la confusion et rend le dépannage beaucoup plus simple.

Étape 2 : valider l’authentification avant la première campagne

Avant de conclure que « Microsoft nous bloque » ou que « Google est trop agressif », vérifiez les bases :

• SPF n’inclut que l’infrastructure qui doit envoyer les mails de simulation
• DKIM est activé et signe de manière fiable
• DMARC est publié et aligné avec le domaine de l’expéditeur visible
• les messages de test montrent bien les résultats d’authentification attendus

Pour une remise à niveau neutre vis-à-vis des fournisseurs, la vue d’ensemble de Microsoft sur l’authentification des e-mails est une bonne base, et les recommandations d’envoi de Google disent la même chose : une délivrabilité fiable commence par une authentification propre et un bon alignement de domaine.

Si vous utilisez AutoPhish, l’article d’aide sur la délivrabilité des e-mails de campagne et le contrôle DNS sont de bons points de départ pendant la mise en place.

Étape 3 : utiliser un allowlisting chirurgical quand c’est nécessaire, pas des contournements de grande ampleur

C’est la partie dont beaucoup d’équipes ont réellement besoin.

Une bonne exception est :

• spécifique
• documentée
• révisable
• facile à expliquer aux auditeurs
• liée à une identité d’expéditeur connue ou à une IP d’envoi dédiée
• suffisamment étroite pour ne pas accorder par erreur une confiance à du trafic sans rapport

Une mauvaise exception, c’est « tout ce qui vient de ce fournisseur est bon ». Une meilleure exception, c’est « les e-mails de simulation envoyés depuis cette IP dédiée et cet ensemble d’expéditeurs défini doivent être livrés de manière cohérente pour ce programme de sensibilisation ». Cette distinction compte.

En pratique, la posture la plus défendable est souvent :

• conserver l’analyse normale là où c’est possible
• éviter les règles globales de type « ne plus filtrer »
• préférer des règles étroites basées sur l’expéditeur ou l’IP plutôt qu’une confiance à l’échelle de l’infrastructure
• documenter précisément pourquoi la règle existe et ce qu’elle couvre
• la revoir périodiquement, sans supposer qu’elle doive être temporaire si elle reste étroitement circonscrite et conforme à votre modèle de contrôle

Avec AutoPhish, ce modèle est atteignable parce que les campagnes sont envoyées depuis une IP dédiée et une empreinte d’expéditeur connue, plutôt que depuis un énorme pool de mails partagé.

Étape 4 : concevoir des simulations qui enseignent la reconnaissance, pas la bataille avec la passerelle

Les meilleures simulations de phishing n’ont pas besoin de « gagner » contre tous les contrôles de sécurité.

Elles doivent vous aider à mesurer si les personnes :

• repèrent les indices suspects
• évitent les actions risquées
• signalent rapidement les messages suspects
• progressent avec le temps

C’est un objectif de conception bien plus sain que d’essayer de faire ressembler chaque e-mail à une attaque réelle jusque dans la couche de filtrage.

Étape 5 : construire un reporting capable de distinguer les problèmes de messagerie des problèmes humains

Un programme mature devrait pouvoir répondre à ces questions :

• Combien de messages ont réellement été délivrés ?
• Quel fournisseur ou quelle politique les a filtrés ?
• Quels services ont eu une visibilité plus faible ?
• Les utilisateurs ont-ils signalé le message ?
• Les mêmes utilisateurs se sont-ils améliorés au fil du temps ?

C’est ce qui transforme les simulations de « simples faux e-mails » en quelque chose d’utile opérationnellement.

Si vous voulez ce type de structure, le reporting compte autant que le contenu. Voir : Reporting de simulation de phishing : 12 fonctionnalités que les équipes sécurité devraient comparer.

À quoi ressemble un bon allowlisting

Une bonne règle doit être assez étroite pour que votre équipe sécurité puisse la tolérer et que vos auditeurs puissent la comprendre.

Cela signifie généralement :

• qu’elle est limitée à l’infrastructure d’envoi des simulations
• qu’elle est liée à des domaines connus, à des identités d’expéditeur ou à une IP dédiée
• qu’elle ne fait pas confiance à des mails sans rapport provenant du même fournisseur plus large
• qu’elle ne crée pas une condition générale de type « toujours livrer, jamais analyser », sauf raison très solide
• qu’elle est suivie dans le cadre du programme de sensibilisation, pas comme un contournement caché

C’est aussi là que l’architecture du fournisseur compte. Si une plateforme envoie depuis un pool partagé utilisé par de nombreux clients, l’allowlisting à long terme est plus difficile à justifier. Si elle envoie depuis une IP dédiée avec une surface d’expéditeur petite et documentée, un allowlisting étroit devient beaucoup plus facile à défendre.

Checklist rapide quand les e-mails de simulation de phishing vont dans les spams

Utilisez cette checklist quand vos résultats semblent suspects.

Authentification et identité d’expéditeur

• Le domaine visible dans From est-il bien celui que vous vouliez utiliser ?
• SPF, DKIM et DMARC sont-ils alignés avec ce domaine ?
• Quelque chose a-t-il changé récemment dans le DNS ou la configuration d’envoi ?
• Les en-têtes de test montrent-ils les résultats attendus ?

Architecture d’envoi

• Utilisez-vous un sous-domaine dédié aux simulations ?
• L’infrastructure d’envoi est-elle isolée du mail de production ?
• L’historique de réputation de l’expéditeur est-il stable ?
• Dépendez-vous d’un pool d’expéditeurs partagé ou d’une IP dédiée ?

Règles et exceptions

• Quelqu’un a-t-il créé un contournement large pour « faire fonctionner le tout » ?
• La règle pourrait-elle être réduite à des identités d’expéditeur exactes ou à une IP dédiée ?
• L’exception est-elle documentée et révisable ?
• Continuez-vous à analyser partout où c’est possible ?

Contenu et mesure

• Les URL sont-elles propres et prévisibles ?
• Y a-t-il des chaînes de redirection inutiles ?
• Mesurez-vous la livraison séparément de l’engagement ?
• Suivez-vous le taux de signalement et le délai de signalement, pas seulement les clics ?

FAQ

Devons-nous mettre les e-mails de simulation de phishing en liste blanche ?

Parfois, oui.

Ce que vous voulez éviter, c’est une confiance large. Ce qui est souvent acceptable, c’est une confiance étroite : une IP d’envoi dédiée, des identités d’expéditeur connues, un objectif clairement documenté, et aucun contournement démesuré qui affaiblit le reste de votre sécurité mail.

Ces règles doivent-elles être temporaires ?

Pas nécessairement.

Les exceptions d’urgence larges doivent être temporaires. Mais des règles chirurgicales, bien bornées peuvent rester en place si elles font partie du modèle opérationnel approuvé, restent suffisamment étroites et sont révisées périodiquement.

Peut-on lancer des simulations depuis notre domaine corporate principal ?

Oui, mais c’est généralement plus contraignant et plus risqué.

Un sous-domaine dédié aux simulations est plus simple à authentifier, plus simple à expliquer et moins susceptible d’entrer en collision avec vos contrôles anti-usurpation et anti-impersonation en production.

Une meilleure délivrabilité réduit-elle le réalisme ?

Non.

Les bonnes simulations mesurent la reconnaissance et le comportement de signalement. Elles n’ont pas besoin d’une infrastructure brouillonne ni de contournements dangereux pour être utiles.

Comment prouver que les résultats sont fiables ?

Documentez les deux côtés du système :

1. ce qui était censé être livré
2. ce que les utilisateurs ont réellement fait après la livraison

C’est bien plus défendable que de montrer un graphique de taux de clics sans contexte de livraison.

Prêt à lancer des simulations qui mesurent la résilience plutôt que les accidents de flux mail ?

AutoPhish est conçu pour les équipes qui veulent des simulations sûres, un reporting respectueux de la vie privée et des preuves adaptées à l’audit sans lourdeur opérationnelle.

Si vous avez besoin d’indications précises de configuration, consultez notre article d’aide sur comment faire en sorte que les e-mails de campagne soient bien reçus.

Sign Up

Crédit photo : photo de Krsto Jevtic sur Unsplash.