GoPhish SMTP : le profil d'envoi pour M365, Google et OVH

Le profil d’envoi (« Sending Profile ») est l’endroit où la plupart des campagnes GoPhish échouent. Le serveur tourne, le modèle s’affiche bien, la campagne passe au statut « In progress », puis rien n’arrive, ou une erreur 535 s’affiche dans la chronologie. Ce guide reprend le profil champ par champ, donne les réglages qui fonctionnent avec Microsoft 365, Google Workspace et OVHcloud, et montre comment lire les erreurs que GoPhish remonte.

Le comportement décrit ici vient du code source de GoPhish 0.12.1, la dernière version publiée (14 septembre 2022). Les réglages des fournisseurs viennent de leur documentation, vérifiée en octobre 2026. On parle de campagnes internes : envoyées par l’organisation à ses propres salariés, avec un mandat écrit de la direction. Pour faire arriver les messages dans les boîtes Microsoft 365 une fois le profil en place, voyez notre guide sur la délivrabilité GoPhish vers Microsoft 365 ; pour l’installation du serveur, le tutoriel GoPhish sur VPS.

Ce que GoPhish fait de chaque champ

Plusieurs comportements ne se voient pas dans l’interface.

Il y a deux adresses d’expéditeur. Le SMTP From du profil sert d’adresse d’enveloppe. L’adresse affichée au destinataire se règle dans chaque modèle, avec le champ « Envelope Sender » (l’infobulle de GoPhish le confirme : « This sender is shown to the user by most email clients »). Le nom prête à confusion, mais la règle est simple : l’Envelope Sender du modèle devient l’en-tête From ; vide, GoPhish reprend le SMTP From du profil.

Le chiffrement dépend du port. Avec le port 465, GoPhish ouvre directement une connexion TLS. Sur tout autre port, il commence en clair et passe en STARTTLS si le serveur le propose, sans l’exiger. Si le serveur propose l’authentification PLAIN sans TLS, la bibliothèque d’envoi refuse d’envoyer le mot de passe et renvoie unencrypted connection.

Le nom annoncé au serveur (commande HELO) est le nom d’hôte de la machine. En Docker, c’est l’identifiant du conteneur, une suite de caractères hexadécimaux, alors que la norme SMTP (RFC 5321) attend un nom de domaine complet. Fixez hostname: dans votre docker-compose.yml avec un nom complet qui correspond au reverse DNS de l’adresse IP d’envoi.

GoPhish ajoute aussi ses propres en-têtes : X-Mailer: gophish sur chaque message, et X-Gophish-Contact si vous avez renseigné contact_address dans config.json. Renseignez cette adresse : l’administrateur d’une messagerie qui voit passer vos messages sait qui contacter.

Par où faire passer vos emails

Avant de remplir le profil, choisissez par où passent les messages.

1. Livrer directement au serveur de réception de votre organisation. Le champ Host pointe vers le serveur MX de votre propre domaine, sans authentification. C’est la route la plus simple pour une campagne interne, quand tous les destinataires sont sur la même messagerie. Elle demande le port 25 sortant : AWS, Google Cloud et la plupart des abonnements Azure le bloquent par défaut, d’après leur documentation. Les messages sont traités comme n’importe quel email venu d’Internet, et l’administrateur de la messagerie les autorise dans la liste blanche prévue pour les simulations.
2. Passer par une boîte de votre messagerie. Le serveur authentifié de Microsoft 365, de Google ou d’OVHcloud envoie au nom d’une boîte réelle. C’est rapide pour un premier test, mais les quotas sont bas et l’adresse d’expéditeur est celle de la boîte.
3. Passer par un relais transactionnel. Brevo, Amazon SES ou un autre service signe vos messages en DKIM sur votre domaine de simulation. C’est la route décrite dans l’étape SMTP du tutoriel VPS.

Microsoft 365

Livraison directe au tenant

Pour une campagne interne, faites pointer le profil vers le point d’entrée de votre tenant. Son nom figure dans votre enregistrement MX (dig +short MX votredomaine.fr) ou dans le centre d’administration, page Domaines, onglet des enregistrements DNS. Microsoft le documente sous la forme exemple-fr.mail.protection.outlook.com.

• Host : ce nom suivi de :25
• Username et Password : vides
• SMTP From : une adresse de votre domaine de simulation, distinct des domaines de votre tenant

Ce dernier point compte. Si le SMTP From appartient à l’un des domaines acceptés du tenant et que l’administrateur a activé le réglage « Reject Direct Send », Exchange Online refuse le message avec 550 5.7.68 TenantInboundAttribution; Direct Send not allowed for this organization from unauthorized sources. Microsoft précise que ce contrôle lit uniquement l’adresse d’enveloppe. Le réglage est désactivé par défaut sur les tenants existants, et Microsoft prévoit de l’activer d’office sur les nouveaux.

Une fois le message accepté, Defender l’analyse comme n’importe quel email entrant. La procédure pour autoriser votre adresse IP et votre domaine d’envoi dans la politique Advanced Delivery, onglet « Phishing simulation », est détaillée dans notre guide de délivrabilité GoPhish vers Microsoft 365 et dans notre guide Microsoft 365 et Advanced Delivery.

Envoi authentifié avec une boîte (SMTP AUTH)

Pour un test, vous pouvez aussi envoyer avec les identifiants d’une boîte :

• Host : smtp.office365.com:587. Microsoft recommande ce port et indique qu’un appareil qui propose le port 465 ne gère pas les versions de TLS demandées.
• Username : l’adresse complète de la boîte ; Password : son mot de passe.
• SMTP From : l’adresse de cette boîte, ou d’une boîte dont elle a le droit « Send As ». Sinon le message revient avec 5.7.60 SMTP; Client does not have permissions to send as this sender.

Côté tenant, d’après la documentation de Microsoft, SMTP AUTH doit être activé pour la boîte (il est désactivé par défaut pour les organisations créées après janvier 2020) et les paramètres de sécurité par défaut d’Entra ID doivent être désactivés, car ils bloquent cette authentification. Une stratégie d’accès conditionnel qui bloque l’authentification héritée produit le même échec. Les envois sont limités à 30 messages par minute et 10 000 destinataires par jour : réglez « Send Emails By » pour étaler la campagne.

Cette route a une date de péremption. GoPhish ne sait s’authentifier qu’avec un identifiant et un mot de passe, sans OAuth. Or Microsoft a annoncé le 27 janvier 2026 que l’authentification de base de SMTP AUTH serait désactivée par défaut fin décembre 2026 sur les tenants existants (un administrateur pourra la réactiver), indisponible par défaut sur les tenants créés après cette date, et que la date de retrait définitif serait annoncée au second semestre 2027 (blog de l’équipe Exchange). Une fois désactivée, chaque envoi échoue avec 550 5.7.30 Basic authentication is not supported for Client Submission.

Google Workspace

Google documente trois serveurs pour les applications qui envoient des emails (aide Google Workspace, mise à jour le 9 octobre 2026).

Pour une campagne interne, le serveur restreint aspmx.l.google.com joue le rôle de la livraison directe : laissez Username et Password vides, ajoutez l’adresse IP de votre serveur GoPhish à la liste d’autorisation Gmail dans la console d’administration, et publiez-la dans l’enregistrement SPF du domaine d’envoi. Google prévient que les messages suspects peuvent être filtrés ou rejetés, sur ce serveur comme sur les deux autres.

Le service de relais smtp-relay.gmail.com se configure dans la console (routage, service de relais SMTP). Si vous l’autorisez par adresse IP, laissez là aussi Username et Password vides dans GoPhish.

Avec smtp.gmail.com, l’authentification pose une condition. Depuis le 1er mai 2025, Google Workspace refuse que les applications tierces se connectent avec le seul identifiant et le mot de passe du compte. GoPhish ne gérant pas OAuth, il lui faut un mot de passe d’application, donc un compte avec la validation en deux étapes. Sans lui, Gmail répond 535 ... Username and Password not accepted ou 534 ... Application-specific password required. Vérifiez aussi l’en-tête From reçu lors du test : Gmail peut remplacer une adresse qui n’est ni celle du compte ni l’un de ses alias déclarés.

OVHcloud

Les réglages dépendent de l’offre.

Le point d’interrogation est le numéro du serveur de votre service, affiché dans l’espace client OVHcloud (pour Email Pro, cadre Connexion de l’onglet Informations générales).

Les quotas sont le vrai sujet. D’après la documentation OVHcloud mise à jour le 3 septembre 2026, une adresse MX Plan envoie environ 200 emails par heure, et le serveur SMTP accepte au maximum 300 emails par heure depuis une même adresse IP source. OVHcloud ajoute que ses messageries ne sont pas conçues pour l’envoi en masse, et qu’un envoi abusif depuis une adresse entraîne un blocage automatique. Une campagne de simulation ressemble précisément à ce que ces contrôles cherchent : utilisez une adresse dédiée, jamais la boîte d’un collaborateur, et étalez l’envoi sous le quota avec « Send Emails By ».

Si vos destinataires sont eux-mêmes sur une messagerie mutualisée OVHcloud, sachez qu’il n’y a pas de liste blanche côté serveur : le filtrage est fait en amont par Vade. Notre guide OVH sans liste blanche explique ce que deviennent les messages et ce qui améliore le résultat.

Lire les erreurs d’envoi

GoPhish affiche les erreurs à plusieurs endroits :

• la fenêtre « Send Test Email », qui affiche le message du serveur tel quel (même chose avec POST /api/util/send_test_email, voir notre guide de l’API GoPhish) ;
• la chronologie de chaque destinataire dans les résultats de campagne, avec l’événement « Error Sending Email » et son détail ;
• les journaux du service (journalctl -u gophish ou docker compose logs gophish), où chaque échec est consigné avec le code SMTP et l’adresse.

La réaction de GoPhish dépend du code. Sur une erreur temporaire (4xx), le destinataire passe au statut « Retrying » et GoPhish réessaie après 2 minutes, puis 4, 8, et ainsi de suite jusqu’à 256 minutes, soit 8 nouvelles tentatives au plus. Sur une erreur définitive (5xx), le destinataire passe directement en « Error », sans nouvelle tentative. Si la connexion au serveur échoue, GoPhish essaie 10 fois puis abandonne avec Max connection attempts exceeded, suivi de la cause.

SPF, DKIM et DMARC : ce que le profil change

Le profil décide quelles vérifications votre message peut réussir. SPF contrôle le domaine du SMTP From (l’enveloppe) et l’adresse IP qui a remis le message. DMARC exige ensuite que le domaine de l’en-tête From, donc l’Envelope Sender du modèle, soit aligné avec le domaine validé par SPF ou avec celui de la signature DKIM. Et GoPhish ne signe pas en DKIM : la version 0.12.1 ne contient aucun code pour le faire, la signature vient du serveur qui transmet le message.

En pratique :

• gardez l’Envelope Sender du modèle et le SMTP From du profil sur le même domaine (un sous-domaine suffit en alignement relâché) ;
• n’affichez jamais dans l’en-tête From un domaine que vous ne contrôlez pas : si ce domaine publie une politique DMARC quarantine ou reject, vos messages seront mis en quarantaine ou rejetés, et c’est le comportement attendu ;
• en livraison directe depuis votre serveur, il n’y a pas de DKIM du tout, donc SPF doit passer et s’aligner : publiez l’adresse IP du serveur dans l’enregistrement SPF du domaine de simulation.

Les enregistrements DNS eux-mêmes sont détaillés dans le guide configurer SPF, DKIM et DMARC. Commencez avec une politique DMARC en p=none et une adresse rua pour recevoir les rapports.

Tester avant la campagne

Envoyez un email de test vers une boîte de chaque messagerie que vos destinataires utilisent, puis ouvrez les en-têtes complets du message reçu. Vérifiez :

• Authentication-Results : spf=pass ou dkim=pass, et dmarc=pass ;
• l’en-tête From, qui doit afficher l’Envelope Sender du modèle ;
• le Return-Path, qui montre l’adresse d’enveloppe réellement utilisée (certains relais la remplacent par leur propre domaine de rebond) ;
• la première ligne Received, où apparaît le nom annoncé en HELO.

Ensuite seulement, lancez une campagne sur un petit groupe de boîtes que vous contrôlez, et regardez où arrivent les messages : boîte de réception, indésirables ou quarantaine.

Quand le profil prend plus de temps que la campagne

Le profil d’envoi est la partie de GoPhish qui demande le plus d’entretien : quotas des fournisseurs, authentification de base en fin de vie chez Microsoft, DKIM à obtenir d’un relais, liste blanche à tenir à jour. Avec nophi.sh, les simulations partent de notre infrastructure, depuis un domaine d’envoi authentifié (SPF, DKIM et DMARC alignés) mis en place avec vous. Il reste l’autorisation côté messagerie, par exemple la politique Advanced Delivery sur Microsoft 365, et la configuration prend environ 15 minutes hors liste blanche. Le comparatif GoPhish détaille le reste de l’écart, et l’essai de 14 jours ne demande pas de carte bancaire.

FAQ

Quel port choisir pour GoPhish, 465 ou 587 ?

GoPhish ouvre une connexion TLS dès le départ quand le port est 465. Sur tout autre port, il commence en clair puis passe en STARTTLS si le serveur le propose. Choisissez 465 quand le fournisseur le propose en SSL/TLS (OVH MX Plan, Gmail) et 587 pour un serveur en STARTTLS (Microsoft 365, OVH Email Pro et Exchange). Microsoft 365 n’accepte pas le port 465 pour l’envoi authentifié.

Peut-on utiliser un compte Microsoft 365 comme serveur SMTP pour GoPhish ?

Oui, avec smtp.office365.com sur le port 587, si SMTP AUTH est activé pour la boîte. L’adresse SMTP From doit être celle de la boîte ou d’une boîte dont elle a le droit Send As, et l’envoi est limité à 30 messages par minute et 10 000 destinataires par jour. GoPhish ne gère que l’authentification de base, que Microsoft désactivera par défaut fin décembre 2026 pour les tenants existants. Pour une campagne interne, la livraison directe au tenant est plus durable.

Peut-on utiliser Gmail comme serveur SMTP pour GoPhish ?

Oui, avec smtp.gmail.com (465 ou 587), l’adresse complète et un mot de passe d’application, ce qui suppose la validation en deux étapes sur le compte. Google limite cet envoi à 2 000 messages par jour. Pour une organisation sous Google Workspace, le service de relais smtp-relay.gmail.com (authentification par adresse IP, 10 000 destinataires par jour et par utilisateur) ou le serveur restreint aspmx.l.google.com conviennent mieux.

Combien d’emails peut-on envoyer par heure avec une adresse OVH ?

Environ 200 emails par heure pour une adresse MX Plan, et au maximum 300 emails par heure depuis une même adresse IP source sur le serveur SMTP d’OVHcloud, selon sa documentation mise à jour le 3 septembre 2026. OVHcloud précise que ses messageries ne sont pas conçues pour l’envoi en masse et qu’un envoi jugé abusif entraîne un blocage automatique de l’adresse.

Pourquoi l’email de test arrive mais pas la campagne ?

Le test part vers une seule adresse, souvent la vôtre, déjà habituée à l’expéditeur. La campagne part vers des dizaines de boîtes et déclenche les filtres de la messagerie : quarantaine, dossier indésirable ou réécriture des liens. Vérifiez le suivi des messages côté messagerie, puis déclarez l’adresse IP et le domaine d’envoi dans la liste blanche prévue pour les simulations (la politique Advanced Delivery sur Microsoft 365).

GoPhish signe-t-il les emails avec DKIM ?

Non. Le code de la version 0.12.1 ne contient aucune fonction DKIM. La signature vient du serveur par lequel passent les messages : Microsoft 365, Google, OVHcloud ou un relais transactionnel. En livraison directe depuis votre serveur, les messages partent sans DKIM, sauf si vous placez devant GoPhish un serveur de messagerie qui signe (Postfix avec OpenDKIM par exemple).