Un formulaire de contact ouvert sur un site vitrine, un champ commentaire sous un article, une adresse email publiée en clair : chacun de ces points d’entrée peut servir de cible pour tester la résilience d’une infrastructure face aux messages indésirables. Avant de lancer une campagne de sensibilisation interne ou un test de filtrage, on doit poser un cadre technique précis pour éviter que le domaine principal ne soit pénalisé par les fournisseurs de messagerie.
Domaine d’envoi dédié et authentification : le socle technique avant tout test
Envoyer un message de test depuis le domaine principal du site revient à jouer la réputation d’expéditeur de toute l’organisation. Les volumes transitant par une newsletter, un CRM ou une boutique sont agrégés au niveau du domaine : un test mal isolé dégrade la délivrabilité des emails légitimes.
La première action concrète consiste à créer un sous-domaine réservé aux tests (par exemple test.monsite.fr). On y configure SPF, DKIM et DMARC avant le moindre envoi. Depuis 2024, Google et Yahoo imposent ces authentifications aux expéditeurs en volume, et Microsoft a suivi en 2025. Sans ce trio, le message atterrit directement en spam, ce qui fausse le test et salit la réputation du domaine.
Quand on cherche à créer un message indésirable en ligne dans un cadre de simulation, on travaille donc toujours sur un périmètre d’envoi cloisonné. Le sous-domaine dédié absorbe les éventuelles plaintes sans contaminer le flux principal.
Points de configuration à vérifier avant le premier envoi
- L’enregistrement SPF du sous-domaine autorise uniquement le serveur ou l’outil utilisé pour le test, pas l’ensemble de l’infrastructure.
- La clé DKIM est générée spécifiquement pour le sous-domaine, avec une longueur de clé conforme aux recommandations actuelles.
- La politique DMARC du sous-domaine est positionnée sur « quarantine » ou « reject » pour observer le comportement des filtres destinataires sans ambiguïté.
Simulation de phishing interne : cibler des destinataires volontaires
Un test de phishing envoyé à l’ensemble des collaborateurs sans prévenir personne pose un problème opérationnel direct. Les signalements « spam » remontent aux fournisseurs de messagerie sous forme de plaintes. Dépasser un certain seuil de plaintes déclenche des restrictions sur le domaine d’envoi, même si le message est un exercice interne.
Travailler sur un panel réduit de destinataires volontaires permet de contrôler ce risque. On sélectionne un groupe test, on informe le service informatique, et on limite le volume à quelques dizaines de messages par vague.
Construire un scénario réaliste sans déclencher les filtres
Les filtres anti-phishing analysent plusieurs signaux : liens raccourcis, pièces jointes exécutables, usurpation d’identité dans le champ expéditeur. Pour qu’un test mesure réellement la vigilance humaine, le message doit ressembler à une tentative crédible sans utiliser de techniques qui seraient bloquées avant d’atteindre la boîte de réception.
On privilégie un objet d’email plausible (confirmation de commande, mise à jour de mot de passe), un lien pointant vers une page contrôlée en interne, et un expéditeur affiché cohérent avec le sous-domaine de test. Le lien de destination ne doit jamais collecter de données réelles : il redirige vers une page de sensibilisation qui explique l’exercice.
Le format du message compte aussi. Les emails de phishing réels contiennent souvent des fautes calibrées ou un sentiment d’urgence. Reproduire ces éléments dans la simulation permet de mesurer si les collaborateurs repèrent ces indices, à condition que le scénario reste proportionné au niveau de maturité de l’équipe testée.
Règles de désinscription et conformité légale des tests par email
Les exigences récentes des fournisseurs de messagerie incluent un mécanisme de désinscription en un clic pour les messages marketing. Cette obligation s’applique aussi aux emails de test si ceux-ci sont envoyés à des destinataires externes ou à des listes comportant des adresses personnelles.
En France, la prospection par email auprès de particuliers nécessite un consentement préalable. Pour un test interne, le cadre est différent : l’employeur peut organiser des exercices de sécurité dans le périmètre de sa politique informatique. La nuance se situe au niveau du consentement éclairé post-exercice. Informer les participants après le test, leur expliquer ce qui a été mesuré et comment leurs données ont été traitées reste une bonne pratique conforme au RGPD.
Ce que le cadre légal change pour les simulations
- Un exercice de phishing interne ne requiert pas de consentement préalable de chaque salarié, mais la politique de sécurité informatique de l’entreprise doit le prévoir explicitement.
- Les données collectées pendant le test (taux de clic, identification des utilisateurs ayant cliqué) sont des données personnelles soumises au RGPD : durée de conservation limitée, accès restreint, finalité documentée.
- Si le test implique des adresses externes (partenaires, prestataires), le consentement préalable redevient obligatoire.
- Le lien de désinscription doit figurer dans le message si celui-ci emprunte un canal marketing, même à des fins de test.
Surveillance post-envoi et indicateurs de réputation du domaine
Une fois le test lancé, on surveille trois indicateurs en priorité : le taux de plaintes spam remontées par les fournisseurs, le taux de rebond (hard bounce) et le score de réputation du sous-domaine via des outils comme Google Postmaster Tools.
Un taux de plaintes qui grimpe au-delà du seuil toléré par les fournisseurs signale que le test a débordé du cadre prévu. Dans ce cas, on stoppe immédiatement les envois restants et on analyse les causes : volume trop élevé, destinataires non informés, contenu trop agressif.
Le délai entre l’envoi et la mesure varie selon le fournisseur de messagerie du destinataire et le volume traité. Sur de petits volumes de test, les données consolidées apparaissent en général sous quelques heures. On compare ensuite les résultats entre les vagues pour affiner le scénario suivant.
La réputation d’un sous-domaine se construit progressivement. Lancer un premier test massif depuis un sous-domaine neuf déclenche quasi systématiquement un blocage. On commence par de très faibles volumes, puis on monte en charge sur plusieurs jours. Ce rodage protège la capacité d’envoi du domaine principal, qui reste intacte tout au long de la campagne de test.
