Envoyer du GoPhish dans Microsoft 365 : guide 2026

Vous avez votre serveur GoPhish prêt, vos templates compilent sans erreur dans Outlook, votre domaine d’envoi est correctement chauffé avec SPF, DKIM et DMARC alignés. Vous lancez votre première campagne réelle vers un tenant Microsoft 365. Trois minutes plus tard, vous regardez votre dashboard : 4 % d’ouvertures, 0 % de clics, et un IT en interne qui vous remonte que personne n’a reçu d’email. Les messages sont en quarantaine, et la quarantaine est inaccessible aux utilisateurs.

Vous tentez la vieille méthode : une mail flow rule qui force SCL=-1 sur tous les emails venant de votre IP GoPhish. Vous relancez. Même résultat. Microsoft a explicitement retiré, en 2024-2025, la possibilité de bypasser la quarantaine via mail flow rule pour les emails classés « High Confidence Phish » (learn.microsoft.com/en-us/defender-office-365/advanced-delivery-policy-configure). La seule manière de faire passer un outil tiers de simulation est la Advanced Delivery Policy de Defender for Office 365.

Cet article décrit la chaîne complète à mettre en place en 2026 : Advanced Delivery Policy côté Defender, transport rule pour bypasser Safe Links, Connection Filter Policy pour l’IP allowlist, Inbound Connector quand le volume monte, vérification end-to-end via Threat Explorer. On traite aussi les pièges qui font perdre des campagnes — CIDR trop larges refusés silencieusement, URLs sans wildcard, et surtout le cas du destinataire qui a un Proofpoint ou un Mimecast devant son M365.

Pour la mise en place initiale de GoPhish sur un VPS, consultez le tutoriel complet d’installation GoPhish sur VPS ; pour le déploiement Docker, le guide GoPhish Docker Compose. Pour la configuration DNS du domaine d’envoi (SPF, DKIM, DMARC adaptés à un domaine de simulation), voir le guide délivrabilité GoPhish : SPF, DKIM, DMARC. Si vous comparez GoPhish à l’Attack Simulator natif de Microsoft, voir le guide Microsoft Defender Attack Simulator et le comparatif GoPhish vs Attack Simulator vs nophi.sh.

Pourquoi Microsoft 365 bloque GoPhish par défaut

GoPhish envoie des emails de phishing. C’est sa fonction. Du point de vue d’un moteur de détection, un email GoPhish a strictement la même structure qu’un vrai email d’attaque : domaine récent ou peu réputé, contenu mimétique d’un service connu (Microsoft, DocuSign, La Banque Postale, Ameli), URL pointant vers une page de capture d’identifiants ou une landing page externe au domaine de l’expéditeur, headers générés par un outil open source bien identifié par les empreintes Defender.

Defender for Office 365 combine plusieurs couches de détection : signatures de menaces connues, heuristiques de contenu, analyse comportementale de l’expéditeur (réputation IP, historique du domaine, alignement SPF/DKIM/DMARC), modèles de machine learning entraînés sur des milliards d’emails malveillants, et signaux de threat intelligence partagés entre tenants. Quand un email coche plusieurs cases simultanément — ce que fait quasi par construction tout email GoPhish — le verdict tombe : High Confidence Phish.

Ce verdict a une conséquence opérationnelle précise : la mise en quarantaine. Et depuis 2024, Microsoft a durci sa politique pour rendre cette quarantaine non bypassable par les mécanismes traditionnels. Concrètement :

Une mail flow rule (transport rule) qui définit SCL = -1 n’a plus d’effet sur les emails classés HC phish. La règle s’applique, le SCL est bien forcé à -1, mais le verdict phish reste prioritaire et l’email part en quarantaine.
Les utilisateurs finaux ne peuvent pas, par défaut, voir ni récupérer les emails en quarantaine classée comme phish. Seul un administrateur Defender peut les libérer manuellement.
Les notifications de quarantaine envoyées aux utilisateurs n’incluent pas ces emails, ce qui rend la situation totalement opaque : vos collaborateurs ne savent même pas que des messages leur sont destinés.

Conséquence pratique : taux de clic effondré (personne ne reçoit l’email), métriques fausses, conclusions erronées sur le niveau de vigilance de l’organisation. Pour une équipe RSSI ou DSI qui pilote un programme de sensibilisation, c’est un échec complet du dispositif. La doc Microsoft est explicite : les mail flow rules pour bypasser le filtrage spam ou phishing ne sont plus effectives pour les messages classés High Confidence Phish (Advanced delivery policy). C’est cette décision qui a rendu obligatoire le passage à l’Advanced Delivery Policy pour tous les outils tiers de simulation.

La bonne approche en 2026 : Advanced Delivery Policy

Microsoft a créé l’Advanced Delivery Policy précisément pour résoudre ce conflit entre la rigueur de Defender et le besoin légitime de faire transiter des outils tiers de simulation de phishing dans une organisation. La policy est conçue pour deux usages explicites : les third-party phishing simulation tools (GoPhish, KnowBe4, Cofense, Proofpoint Security Awareness Training en mode hybride) et les SecOps mailboxes (boîtes utilisées par les équipes de réponse à incident pour recevoir des emails malveillants à analyser).

Quand un email entrant correspond à une Advanced Delivery configurée pour la simulation, Defender modifie son comportement de manière documentée :

Pas de filtrage spam ni phishing. Defender ne classe pas le message comme HC phish ni comme spam, même s’il en a toutes les caractéristiques. Le verdict est explicitement neutralisé.
Pas de ZAP (Zero-hour Auto Purge) pour spam et phishing. Le message reste en boîte de réception même si Microsoft découvre rétroactivement que des emails similaires sont malveillants ailleurs sur la plateforme.
Safe Links wrap les URLs sans bloquer. Les liens sont réécrits via le wrapper Microsoft (safelinks.protection.outlook.com) mais ne sont pas bloqués au clic, même si la destination correspond à un domaine inhabituel. La vérification au clic reste active mais ne génère pas d’avertissement.
Safe Attachments ne détonate pas. Les pièces jointes ne passent pas par le sandbox d’analyse. Utile pour les simulations qui embarquent un document Office avec macro de tracking.
Pas d’alertes système générées sur ces messages. Vos admins ne sont pas spammés de notifications « tentative de phishing détectée » à chaque envoi.
AIR et clustering ignorent ces messages. L’investigation automatisée (Automated Investigation and Response) ne déclenche pas sur les emails de simulation, et le clustering de menaces ne les corrèle pas avec d’autres campagnes.

L’effet net : vos emails GoPhish arrivent en boîte de réception, sont cliquables, et n’apparaissent pas comme une fausse menace dans les outils SOC du tenant. La policy se configure via le portail Microsoft 365 Defender (security.microsoft.com), dans la section Email & Collaboration → Policies & rules → Threat policies → Advanced delivery. Elle demande trois informations : domaines d’envoi, IPs d’envoi, URLs des landing pages. Détails dans l’étape 2.

Étape 1 — Préparer l’infrastructure GoPhish

Avant même de toucher au tenant M365, votre infrastructure GoPhish doit cocher quatre cases. Sans ça, l’Advanced Delivery Policy ne fera que masquer des problèmes plus profonds qui referont surface tôt ou tard.

IP statique publique. Votre serveur GoPhish doit envoyer depuis une IP fixe, déclarée publiquement et réservée à cet usage. Si vous êtes derrière un NAT dynamique (typique de certaines petites infrastructures), l’IP source vue par M365 peut changer entre deux campagnes, et votre Advanced Delivery Policy ne matchera plus. Sur un VPS classique (OVH, Scaleway, Hetzner, AWS Lightsail), l’IP est statique par défaut. Vérifiez avec curl ifconfig.me depuis votre serveur GoPhish que l’IP retournée est bien celle attendue, et que c’est elle qui apparaît dans le header Received: des emails de test envoyés vers une boîte externe.

Domaine d’envoi séparé du domaine corporate. Ne mélangez jamais votre domaine d’entreprise (utilisé pour vos vrais emails métier) avec un domaine de simulation. Si vous envoyez des phishing tests depuis @votre-entreprise.fr, vous polluez sa réputation, vous risquez de la blacklister, et vous rendez la détection de vrais phishings ciblant votre domaine beaucoup plus difficile. Achetez un domaine séparé, idéalement neutre ou mimétique d’un service tiers (jamais d’imitation d’une vraie marque déposée). Détails opérationnels dans le guide délivrabilité GoPhish : SPF, DKIM, DMARC.

Liste des URLs de landing pages. Recensez précisément quelles URLs vos campagnes utilisent. Si vous avez une seule landing page https://simulation.votredomaine-phishing.fr/login, c’est simple. Si vous générez des sous-domaines par campagne (https://chronopost-2026-01.votredomaine-phishing.fr/) ou des URLs paramétrées (https://votredomaine-phishing.fr/c/{token}), notez le pattern. Vous en aurez besoin pour la configuration Advanced Delivery (qui accepte des wildcards).

SPF, DKIM, DMARC propres sur le domaine d’envoi. Même avec l’Advanced Delivery Policy, configurez correctement l’authentification email. Trois raisons : certains destinataires hors M365 (Gmail, autres) appliquent leur propre filtrage et rejetteront sans auth ; en cas de relais malveillant futur depuis votre domaine, DMARC limite la casse ; Microsoft peut étendre à tout moment ses exigences pour les domaines déclarés en Advanced Delivery. Configurez v=spf1 ip4:VOTRE_IP_GOPHISH -all, activez DKIM dans la console GoPhish, publiez v=DMARC1; p=none; rua=mailto:dmarc@votredomaine-phishing.fr. Pour le détail, voir le guide générique SPF/DKIM/DMARC.

À ce stade : une IP, un domaine, un pattern d’URL, une zone DNS alignée. On passe à la configuration du tenant destinataire.

Étape 2 — Configurer Advanced Delivery Policy

Toute la configuration se fait dans le portail Microsoft 365 Defender. Connectez-vous avec un compte ayant le rôle Security Administrator ou Global Administrator sur le tenant destinataire.

Ouvrez security.microsoft.com.
Dans la navigation gauche : Email & Collaboration → Policies & rules → Threat policies.
Faites défiler la section Rules et cliquez sur Advanced delivery.
Vous arrivez sur une page avec deux onglets : Phishing simulations et SecOps mailboxes. Sélectionnez Phishing simulations.
Cliquez sur Add (ou Edit si une entrée existe déjà — un seul enregistrement par tenant).

Le formulaire demande trois listes :

Sending domains. Le ou les domaines d’envoi de votre infrastructure GoPhish. Format : nom de domaine simple, un par ligne. Exemples valides :

simulation.votredomaine-phishing.fr
votredomaine-phishing.fr

Si vous utilisez des sous-domaines générés dynamiquement (par campagne ou par scénario), déclarez le domaine racine et les sous-domaines hériteront. Attention : Microsoft demande des domaines spécifiques, pas de wildcards à ce niveau (les wildcards sont autorisés sur les URLs, pas sur les domaines).

Sending IPs. L’IP ou les IPs publiques de votre serveur GoPhish, au format IPv4. Pour une IP unique, utilisez le format CIDR /32 :

203.0.113.42/32

Pour une plage (si vous avez plusieurs serveurs GoPhish dans le même bloc IP) :

203.0.113.40/29

Ne déclarez pas un /16 ou un bloc cloud entier. Microsoft refuse silencieusement les CIDR trop larges (et c’est l’un des pièges les plus fréquents — voir section plus bas). Si vous êtes sur un hébergeur cloud avec IPs allouées dynamiquement à partir d’un grand pool, achetez une IP réservée plutôt que d’élargir le bloc.

Simulation URLs. Les URLs des landing pages de simulation, avec wildcards autorisés. Format recommandé :

*.votredomaine-phishing.fr/*
votredomaine-phishing.fr/*
https://simulation.votredomaine-phishing.fr/*

Le wildcard * couvre les sous-domaines et les chemins. Si vous omettez les wildcards, seules les URLs strictement identiques seront reconnues comme appartenant à la simulation, et les clics ne seront pas correctement comptabilisés.

Cliquez sur Save. Microsoft confirme : « It can take up to 30 minutes for changes to take effect » (Advanced delivery policy). Dans la pratique, comptez 5 à 10 minutes, mais attendez 30 minutes avant de lancer la vraie campagne.

Étape 3 — Transport rule pour bypass Safe Links

L’Advanced Delivery Policy laisse Safe Links wrapper les URLs sans les bloquer. C’est suffisant pour la livraison, mais ça pose un problème de mesure : quand un utilisateur clique sur un lien wrappé, sa requête transite par safelinks.protection.outlook.com, qui vérifie l’URL puis redirige vers la destination réelle. Côté GoPhish, vous voyez le clic, mais l’IP source qui frappe votre serveur est celle du proxy Microsoft, pas celle de l’utilisateur. Cela complique le déduplication (un même utilisateur peut être enregistré plusieurs fois si Safe Links re-vérifie le lien) et fausse les analyses géographiques.

La solution : ajouter une transport rule qui désactive Safe Links sur les emails issus de votre infrastructure GoPhish, via le header documenté X-MS-Exchange-Organization-SkipSafeLinksProcessing = 1 (Safe Links policies).

Procédure dans Exchange Admin Center :

Ouvrez admin.exchange.microsoft.com.
Mail flow → Rules → Add a rule → Create a new rule.
Name : GoPhish - Bypass Safe Links.
Apply this rule if — deux options selon votre préférence :
- Option A (recommandée) : condition basée sur un header custom. Configurez GoPhish pour injecter un header X-GoPhish-Simulation: true dans tous les emails de campagne. La condition de la rule devient : A message header → includes any of these words → header name X-GoPhish-Simulation → header value true. Avantage : précis, stable, ne dépend pas d’une IP qui peut changer.
- Option B : condition basée sur l’IP source. The sender IP address is in the range → entrez l’IP publique de votre serveur GoPhish (ou la plage CIDR). Avantage : pas besoin de modifier les templates GoPhish.
Do the following : Modify the message properties → Set a message header.
- Header name : X-MS-Exchange-Organization-SkipSafeLinksProcessing
- Header value : 1
Properties of this rule : laissez Audit this rule with severity level → Not specified, ou activez Low si vous voulez tracer.
Mode : Enforce une fois testée. Démarrez en Test mode pendant 24 à 48 heures pour vérifier qu’aucun email légitime ne matche par erreur.
Save.

Vérifiez la création dans Mail flow → Rules : la règle doit apparaître activée. Lancez un email de test depuis GoPhish et inspectez les headers du message reçu : X-MS-Exchange-Organization-SkipSafeLinksProcessing: 1 doit y figurer, et les URLs ne doivent plus être wrappées (elles pointent directement vers https://votredomaine-phishing.fr/... sans transiter par safelinks).

Étape 4 — Connection Filter Policy (IP allowlist)

L’Advanced Delivery Policy gère la classification phishing. La Connection Filter Policy gère la classification spam au niveau réseau, en amont du moteur de contenu. Ajouter votre IP GoPhish à l’allowlist de connexion est une ceinture de sécurité supplémentaire : même si pour une raison X la policy Advanced Delivery ne match pas (typo dans le domaine, IP mal renseignée, propagation incomplète), la Connection Filter Policy garantit que vos emails ne sont jamais marqués spam à la réception.

Procédure :

Portail security.microsoft.com → Email & Collaboration → Policies & rules → Threat policies → Anti-spam.
Cliquez sur Connection filter policy (Default) — il n’y a qu’une seule policy de filtre de connexion, partagée par tout le tenant.
Edit connection filter policy.
Section Always allow messages from the following IP addresses or address range : ajoutez votre IP GoPhish (203.0.113.42 au format simple, sans CIDR pour une IP unique, ou bloc CIDR pour une plage).
Activez Turn on safe list uniquement si vous voulez bénéficier de la liste sûre de Microsoft pour des expéditeurs très réputés — sans rapport direct avec GoPhish, mais cocher cette case ne nuit pas.
Save.

Effet immédiat : les emails provenant des IPs allowlistées contournent le filtrage spam au niveau de la connexion. Combiné à l’Advanced Delivery Policy, ça vous donne une double protection contre les classifications indésirables.

À noter : la Connection Filter Policy ne bypass pas la classification phishing. Sans Advanced Delivery Policy active en parallèle, un email GoPhish classifié HC phish ira en quarantaine même si son IP est dans l’allowlist de connexion. Les deux mécanismes sont complémentaires, pas redondants.

Étape 5 — Inbound Connector (volume élevé)

Pour des campagnes ciblant un grand nombre de destinataires (au-delà de 500 emails par heure vers le même tenant), Exchange Online applique un throttling de protection qui peut générer des NDR (Non-Delivery Reports) ou ralentir significativement la livraison. La solution officielle : déclarer un Inbound Connector de type Partner organization qui référence votre infrastructure GoPhish.

Procédure dans Exchange Admin Center :

admin.exchange.microsoft.com → Mail flow → Connectors → Add a connector.
Connection from : Partner organization.
Connection to : Office 365.
Name : GoPhish Simulation - Inbound.
Description : Connector for third-party phishing simulation traffic.
Turn it on : coché.
How to identify your partner organization : Use the sender’s IP address — entrez l’IP publique de votre serveur GoPhish.
Security restrictions : laissez par défaut (TLS recommandé mais non requis si votre GoPhish ne supporte pas TLS sortant, ce qui est rare).
Save.

Effet : les emails identifiés comme provenant de cette IP bénéficient des quotas augmentés des partenaires reconnus et contournent le throttling appliqué aux expéditeurs inconnus. Pour des campagnes de moins de 500 destinataires, ce n’est pas utile. Au-delà, il devient nécessaire pour éviter que la moitié de votre campagne mette 6 heures à arriver. Pour un audit annuel ponctuel sur 50 personnes, sautez cette étape. Pour un programme continu sur 800 collaborateurs, c’est nécessaire.

Étape 6 — Vérification dans Threat Explorer

Une fois la configuration en place, ne lancez pas tout de suite votre campagne réelle : vérifiez d’abord que Microsoft applique bien les overrides. Threat Explorer (disponible avec Defender for Office 365 Plan 2, donc sur les licences E5 ou avec add-on) permet de filtrer les emails reçus par leur classification.

Portail security.microsoft.com → Email & Collaboration → Explorer.
Sélectionnez la vue All email.
Dans la barre de filtres en haut : System override source → Phishing simulation.
Lancez la recherche sur la fenêtre des dernières 24 heures (ou depuis que vous avez activé la policy).

Si l’Advanced Delivery Policy est correctement configurée et que vous avez envoyé au moins un email de test depuis GoPhish, vos messages doivent apparaître dans cette vue avec le tag Phishing simulation comme source d’override système. Vous pouvez cliquer sur chaque message pour voir le détail : expéditeur, destinataire, URL, verdict appliqué.

Si rien n’apparaît malgré des envois récents, votre policy ne match pas. Les causes habituelles : domaine d’envoi non aligné avec le From (vérifiez l’en-tête From: réel du message, pas le From affiché), IP source différente de celle déclarée (vérifiez Received: du dernier hop avant M365), ou simplement délai de propagation pas encore écoulé.

Pour les tenants sans Defender Plan 2, Threat Explorer n’est pas accessible. Vous pouvez tout de même vérifier les overrides via l’inspection des en-têtes du message reçu (méthode décrite en étape 7), c’est juste moins synthétique. Voir la doc Threat Explorer and real-time detections pour les capacités complètes.

Étape 7 — Test, mesurer, ajuster

La vérification finale se fait avec de vrais emails envoyés vers de vraies boîtes de test. Procédure recommandée :

1. Créer 5 boîtes de test couvrant différents profils. Idéalement : un compte standard non-admin, un compte avec MFA actif, un compte de direction (souvent ciblé par des règles spécifiques anti-spoofing), un compte ancien (avec historique d’inbox volumineux), un compte récent. Cela permet de couvrir les variations de filtrage personnalisé qui peuvent exister.

2. Envoyer 5 emails distincts depuis GoPhish vers ces boîtes. Espacez de 30 secondes entre chaque envoi (pour ne pas déclencher de throttling). Utilisez les templates réels que vous comptez déployer en campagne, pas un email de test générique.

3. Vérifier la livraison. Pour chaque boîte :

L’email est-il en boîte de réception ? (pas dossier spam, pas quarantaine)
Le rendu est-il correct ? (images chargées, liens cliquables, mise en forme conservée)
Les liens fonctionnent-ils ? (pas de wrap Safe Links si vous avez configuré la transport rule)

4. Inspecter les en-têtes du message reçu. Dans Outlook web, ouvrir le message → menu trois points → View → View message source. Cherchez :

Authentication-Results: doit montrer spf=pass, dkim=pass, dmarc=pass pour votre domaine d’envoi. Si l’un de ces résultats est fail, votre configuration DNS est incorrecte — même avec Advanced Delivery, des fails d’auth peuvent générer des comportements inattendus.
X-MS-Exchange-Organization-SCL: devrait être à -1 ou 1 (low). Une valeur de 5 ou plus indique que Defender considère encore le message comme spam, malgré la policy.
X-Forefront-Antispam-Report: cherchez le segment SFV:SKN (skip filter, signifie que le filtrage a été contourné) ou un code lié à la simulation. La présence de SFV:SPM (spam) ou SFV:PHSH (phishing) signale un échec de l’override.
X-MS-Exchange-Organization-AuthAs: doit être présent.
Si vous avez configuré la transport rule : X-MS-Exchange-Organization-SkipSafeLinksProcessing: 1 doit apparaître.

5. Ajuster en fonction des résultats. Si un email finit en spam malgré tout : (1) revérifiez la correspondance exacte IP / domaine entre votre infrastructure et la policy ; (2) attendez 30 minutes supplémentaires pour la propagation ; (3) regardez l’en-tête X-Forefront-Antispam-Report pour identifier le critère déclencheur.

6. Documenter la baseline. Notez les valeurs des en-têtes pour un envoi qui fonctionne correctement. C’est votre référence pour diagnostiquer rapidement les régressions futures (mise à jour Defender côté Microsoft, modification d’une rule par un admin, etc.).

Pièges et anti-patterns

Quelques erreurs récurrentes qui font perdre des heures de troubleshooting.

CIDR trop larges. Vouloir déclarer 203.0.113.0/16 parce que c’est plus simple que de tracker l’IP exacte. Microsoft refuse silencieusement les blocs jugés trop larges (typiquement au-delà de /24 ou /22 selon le contexte) sans message d’erreur explicite : la policy est sauvegardée, mais le filtrage Defender ne l’applique pas. Restez en /32 pour une IP unique ou en /29 à /28 pour un petit pool maîtrisé.

URLs sans wildcard. Déclarer votredomaine-phishing.fr/login au lieu de *.votredomaine-phishing.fr/* (ou au moins votredomaine-phishing.fr/*) bloque le tracking de toutes les variations d’URL utilisées par vos templates. Les clics ne sont pas comptabilisés comme appartenant à la simulation.

Négliger SPF, DKIM, DMARC sur le domaine d’envoi. L’Advanced Delivery Policy bypass le filtrage, mais une absence d’authentification expose votre domaine à des relais malveillants ultérieurs et complique le diagnostic. Configurez l’authentification email même quand techniquement Advanced Delivery « pourrait » s’en passer.

Activer la policy et lancer la campagne dans la foulée. La propagation prend jusqu’à 30 minutes. Lancer 800 emails 2 minutes après la configuration garantit qu’une fraction non négligeable arrive avant que la policy ne soit active. Ces emails partent en quarantaine et ne sont pas récupérables a posteriori (la policy s’applique à la réception, pas rétroactivement).

Croire que mail flow rule SCL=-1 suffit. Cette méthode fonctionnait jusqu’en 2023, elle ne fonctionne plus pour HC phish depuis 2024. Si un tuto recommande encore cette approche seule, il est obsolète. La mail flow rule reste utile en complément (bypass Safe Links étape 3), pas en remplacement.

Penser que la config s’applique hors M365. L’Advanced Delivery est interne au tenant M365 destinataire. Si une partie de vos cibles utilise Google Workspace, Zimbra ou OVH Pro, la policy M365 n’a aucun effet sur leurs filtres — il faut une whitelist équivalente sur chaque environnement.

Ne pas tester avant la campagne réelle. L’étape 7 prend 15 minutes. Sauter cette étape et lancer 1000 emails pour découvrir 4 heures plus tard que 70 % sont en quarantaine reste un classique. Investissez les 15 minutes.

Cas particulier : tenant M365 sous tiers (Proofpoint, Mimecast, Barracuda)

Beaucoup d’organisations, surtout grandes, placent un Secure Email Gateway (SEG) devant leur tenant M365. Le MX du domaine ne pointe plus vers votredomaine-mail.protection.outlook.com mais vers un endpoint du SEG (mx0a-00148b01.pphosted.com pour Proofpoint, eu-smtp-inbound-1.mimecast.com pour Mimecast, mx*.barracudanetworks.com pour Barracuda). Le SEG filtre, classe, met en quarantaine ses propres détections, puis relaie vers M365 ce qu’il considère légitime.

Conséquence pour les simulations : votre Advanced Delivery Policy côté M365 ne protège que la partie post-SEG. Tout ce qui se passe en amont, dans le SEG, applique les politiques de la passerelle. Si Proofpoint classe vos emails GoPhish comme phishing (ce qu’il fait par défaut), les messages ne sortent jamais du SEG et n’atteignent jamais M365. Votre policy Defender est correctement configurée et totalement inopérante.

La solution implique de whitelister GoPhish également côté SEG, avant que la policy M365 puisse jouer son rôle. Chaque éditeur a sa procédure :

Proofpoint. Configuration dans Email Protection → Policy Routes ou via la section Phishing Simulation Allow List. Détails sur la doc Proofpoint (proofpoint.com/us/resources). Voir aussi le comparatif Proofpoint pour le positionnement de l’éditeur.
Mimecast. Configuration via Administration → Gateway → Policies → Permitted Senders, en ciblant l’IP ou le domaine d’envoi GoPhish. Doc : community.mimecast.com. Le comparatif Mimecast couvre les enjeux côté plateforme.
Barracuda. Configuration dans Email Gateway Defense → Inbound Settings → Sender Policies, en ajoutant l’IP et le domaine. Voir la doc campus.barracuda.com. Le comparatif Barracuda pour le contexte.

C’est l’une des sources d’échec les plus fréquentes pour les campagnes GoPhish en environnement entreprise : tout est correctement configuré côté M365, mais le SEG bloque en amont. Vérifiez systématiquement le MX du destinataire avant de configurer (dig MX domaine-destinataire.fr +short). Si le MX pointe vers un SEG, prévoyez 30 à 60 minutes supplémentaires de configuration côté passerelle, et accepter que ça nécessite l’accès admin à la console du SEG (rarement délégué à un consultant externe).

Approche alternative : SaaS hébergé sur infra de réputation

Tout ce qui précède décrit la voie « GoPhish self-hosted vers M365 ». C’est faisable, mais avec une charge de configuration non négligeable, surtout multipliée par tenant destinataire (cas typique d’un MSP, d’un consultant, ou d’une équipe interne qui pilote des simulations sur les filiales d’un groupe).

Une alternative : utiliser une plateforme SaaS qui a déjà négocié sa réputation et son infrastructure auprès des grands filtres email. Les acteurs comme nophi.sh exploitent des pools d’IPs et de domaines avec un historique d’envoi stable et des configurations de délivrabilité maintenues en continu.

Le compromis est clair :

Avantage : pas de gestion d’Advanced Delivery côté tenant destinataire. L’infrastructure du fournisseur passe les filtres sans configuration spécifique côté client (ou avec une simple allowlist d’un domaine connu). Pour un programme continu sur 12 mois, l’économie de temps est significative.
Inconvénient : vous ne contrôlez ni l’IP, ni le domaine d’envoi. Vous dépendez de la réputation maintenue par le fournisseur, et si un autre client de la plateforme déclenche un incident, votre délivrabilité peut être affectée temporairement.

Pour les campagnes ponctuelles (audit annuel, test avant ou après formation), GoPhish self-hosted reste pertinent. Pour les programmes continus (simulations mensuelles avec micro-learning), le SaaS devient plus rationnel économiquement, comme détaillé dans GoPhish en entreprise : pourquoi ça ne suffit pas. Détails de l’offre SaaS sur la page tarifs.

Conclusion

Délivrer GoPhish dans Microsoft 365 en 2026 est faisable, et la doc Microsoft sur l’Advanced Delivery Policy est claire. Mais la procédure s’est sensiblement compliquée par rapport à la décennie précédente : l’époque où une simple mail flow rule SCL=-1 suffisait est révolue. Microsoft a structuré son écart entre « secure by default » et « usage légitime d’outils tiers de simulation » avec un mécanisme explicite, et c’est aujourd’hui le seul chemin officiel.

Comptez 1 à 2 heures de configuration la première fois (Advanced Delivery + transport rule + Connection Filter + tests), à multiplier par tenant si vous êtes consultant ou MSP. Une fois en place, la maintenance est faible : la policy reste active tant que vos IPs, domaines et URLs ne changent pas. Si vous changez de serveur GoPhish (nouvelle IP), il faut mettre à jour la policy sur chaque tenant cible — c’est le moment où la friction se voit.

Le scénario d’échec le plus coûteux n’est pas l’absence de configuration, c’est la configuration partielle : Advanced Delivery activée mais SEG en amont qui bloque, ou IP allowlistée mais URL sans wildcard donc tracking cassé. Testez systématiquement avec 5 emails avant chaque vraie campagne, et vérifiez les en-têtes des messages reçus. C’est 15 minutes qui sauvent des heures.

Si vous gérez plusieurs tenants ou si la maintenance de l’infrastructure GoPhish vous coûte plus que ce que la gratuité de l’outil vous fait économiser, considérez une plateforme SaaS spécialisée. C’est le calcul à poser de manière froide, sans dogme open source vs propriétaire : combien de jours-homme par an sur la délivrabilité, vs un abonnement mensuel qui externalise le problème ? Pour une PME qui vise un programme continu, la réponse penche souvent vers le SaaS. Pour un cabinet de pentest qui livre un audit annuel, GoPhish reste un excellent choix. Détails de comparaison dans GoPhish vs Attack Simulator vs nophi.sh.

Pour aller plus loin sur la configuration de M365 elle-même (MFA, Defender, Conditional Access, SPF/DKIM/DMARC côté tenant), voir le guide sécuriser Microsoft 365.