GoPhish, c’est techniquement du phishing. Le serveur envoie des messages qui imitent une marque, depuis un domaine récent, avec des liens vers une page de login. Du point de vue d’un filtre Gmail ou Microsoft Defender, c’est précisément le profil qu’il est entraîné à bloquer. Et il le fait très bien.

Conséquence directe : une installation GoPhish lancée sans préparation envoie 60 à 80 % de ses messages en spam, quand elle ne se prend pas un rejet SMTP direct. À l’inverse, une infrastructure proprement authentifiée, warmée sur trois semaines, et envoyant vers un tenant M365 ou Google Workspace avec une politique de remise contrôlée atteint 95 % ou plus d’inbox rate.

L’écart entre les deux n’est pas une question de chance. C’est une question de stack technique : enregistrements DNS, MTA, reverse DNS, plan de warm-up, monitoring. Ce guide détaille chaque brique. Il s’adresse à quelqu’un qui a déjà un GoPhish opérationnel — si ce n’est pas le cas, commencez par installer GoPhish sur un VPS ou par le déploiement Docker Compose avant de revenir ici.

Pour la mécanique générale de SPF, DKIM et DMARC sur un domaine d’entreprise classique, le guide canonique sur la configuration SPF/DKIM/DMARC reste la référence. Le présent guide se concentre sur ce qui est spécifique à GoPhish : le profil émetteur défavorable, le warm-up forcé, et les contournements M365 et Workspace qui permettent d’atteindre les boîtes de réception sans tomber dans les zones grises légales.

Pourquoi GoPhish a un problème de délivrabilité par défaut

Ce n’est pas un bug de GoPhish. C’est la nature même de l’outil qui cumule, du point de vue d’un classificateur Bayésien, à peu près tous les signaux qui sortent un message d’une inbox.

Domaine fraîchement enregistré. Les filtres Gmail et Microsoft 365 attribuent un score de réputation initial faible aux domaines de moins de 30 jours. Un domaine de moins de 7 jours envoyant en volume est presque systématiquement filtré. Domain age est une feature explicite des classificateurs.

Contenu mimétique de marques connues. Les templates GoPhish copient l’identité visuelle de Microsoft, Google, banques, RH. Les filtres sont entraînés à détecter ces motifs : logo + login + urgence est la signature classique d’une page de phishing. Un message légitime de M365 part toujours de tenants connus avec un fingerprint d’envoi reconnu — ce que GoPhish ne peut pas reproduire.

Liens vers domaines récents avec landing de login. Le tracker GoPhish (par défaut /track) sert une page qui ressemble à un formulaire d’authentification. Couplé à un domaine récent, c’est le signal le plus discriminant après l’authentification email. Google Safe Browsing flagge ce type de page en moins de 24 heures s’il y a la moindre interaction utilisateur signalée.

Pas d’historique d’engagement. Aucun destinataire n’a jamais ouvert, répondu, ou marqué comme non-spam un message venant de ce domaine. Les filtres se calent sur l’engagement passé — quand il est nul, le bénéfice du doute n’existe pas.

Il n’y a pas de chiffre magique pour contourner ces points, juste une discipline d’infra. Le reste du guide explique laquelle.

Stack technique : les cinq briques de l’authentification email

L’authentification d’un message sortant repose sur un empilement, pas sur un protocole unique. Chaque couche couvre un angle différent. Manquer une seule des cinq dégrade le score d’arrivée.

SPF (Sender Policy Framework, RFC 7208) — qui peut envoyer pour ce domaine. Enregistrement TXT à la racine listant les IPs et includes autorisés.

DKIM (DomainKeys Identified Mail, RFC 6376) — signature cryptographique du message. Clé privée côté MTA, clé publique en TXT sous selector._domainkey.domaine.

DMARC (Domain-based Message Authentication, RFC 7489) — politique d’alignement entre le From visible et les domaines validés par SPF ou DKIM, plus reporting agrégé.

PTR / rDNS — l’IP qui envoie pointe-t-elle vers le FQDN annoncé ? Beaucoup de MTA destinataires (notamment Microsoft) rejettent les connexions dont la PTR est absente ou générique (ec2-1-2-3-4.compute-1.amazonaws.com).

HELO / EHLO — le nom annoncé par le serveur SMTP au début de la session doit être cohérent avec la PTR. Un HELO localhost.localdomain sur un VPS public est un rejet immédiat chez la plupart des opérateurs.

Les trois premiers protocoles vivent dans le DNS. Les deux derniers vivent au niveau IP et MTA. Tous les cinq doivent être alignés.

Étape 1 — Choisir le bon domaine d’envoi

Jamais le domaine corporate principal. Si une campagne tourne mal — plainte utilisateur, listing Spamhaus, blocage M365 — la réputation du domaine est cuite pour des mois. Brûler entreprise.fr pour une campagne de simulation est une décision qu’on ne prend qu’une fois.

Deux stratégies tiennent la route :

Le domaine sosie. Quelque chose comme entreprise-secure.com ou entreprise-rh.fr. Réaliste pour les utilisateurs, plus proche d’un scénario d’attaque réel. Le risque : typosquatting d’un domaine légitime tiers, ou litige si le sosie touche une marque déposée. À ne faire qu’avec validation juridique préalable et après vérification que le domaine cible n’est pas déjà pris par un attaquant.

Le domaine générique séparé. Quelque chose comme notification-team.com ou secure-hr.fr, sans rapport direct avec l’identité de l’entreprise cible. Moins réaliste, mais zéro risque légal et zéro effet sur la marque. C’est la stratégie recommandée pour 90 % des cas, surtout dans un cadre interne.

Acheter au minimum 30 jours avant la première campagne. Le domain age est une feature de classification. Un domaine de moins de 7 jours est filtré quasi-systématiquement par Gmail. Acheter J-30 minimum, idéalement J-60, et y publier les enregistrements DNS dès l’achat.

Choisir un registrar avec API DNS. Cloudflare, OVH, Gandi, AWS Route 53. L’API permet de scripter la publication des enregistrements (SPF, DKIM, DMARC, MX, A, BIMI), de versionner les changements, et de les remettre rapidement si une campagne précédente a polué les valeurs. Éviter les registrars sans API : passer 20 minutes à publier un TXT à chaque rotation de clé DKIM est une perte de temps.

Étape 2 — Configurer SPF pour GoPhish

Deux cas de figure selon l’architecture d’envoi.

Cas 1 — GoPhish envoie directement via son MTA intégré. Le serveur GoPhish ouvre lui-même les connexions SMTP sortantes. L’IP qui présente le message est celle du VPS.

v=spf1 ip4:203.0.113.42 -all

Cas 2 — GoPhish envoie via un relais SaaS. GoPhish ouvre une connexion SMTP authentifiée vers Amazon SES, Brevo, Sendgrid, Postmark, ou Mailgun. Le relais ré-émet le message depuis ses propres IPs.

v=spf1 include:amazonses.com -all

v=spf1 include:spf.brevo.com -all

v=spf1 include:sendgrid.net -all

Pourquoi -all et pas ~all. En production, le softfail (~all) signale aux destinataires qu’un message non listé est suspect mais qu’ils sont libres de le laisser passer. Le hardfail (-all) demande explicitement le rejet. Sur un domaine de simulation, on veut le contrôle strict : aucun chemin d’envoi non autorisé ne doit aboutir, sinon un attaquant qui devine le domaine peut l’utiliser et faire pourrir la réputation. Le hardfail est non-négociable ici.

Vérification.

dig +short TXT votre-domaine-phishing.fr

Le record doit apparaître en une seule ligne. Vérification croisée via MXToolbox SPF Check qui détaille les includes et compte les lookups DNS. Au-delà de 10 lookups le record passe en PermError et SPF est ignoré : avec un seul include de relais ce n’est pas un risque, mais le piège réapparaît dès qu’on chaîne deux relais.

Étape 3 — Configurer DKIM

DKIM se décline en deux setups selon que le MTA est externalisé ou self-hosted.

Avec un relais SaaS

Le relais signe les messages sortants avec sa propre clé privée. La clé publique est exposée via un CNAME ou un TXT dans le DNS du domaine d’envoi.

Amazon SES. Domaine vérifié dans la console SES, trois CNAME générés par AWS, à publier dans le DNS :

xxxx._domainkey.votre-domaine-phishing.fr  CNAME  xxxx.dkim.amazonses.com
yyyy._domainkey.votre-domaine-phishing.fr  CNAME  yyyy.dkim.amazonses.com
zzzz._domainkey.votre-domaine-phishing.fr  CNAME  zzzz.dkim.amazonses.com

Brevo, Sendgrid, Mailgun. Même principe, un TXT ou CNAME spécifique par fournisseur. La signature est gérée côté relais sans configuration MTA locale.

Avec un MTA self-hosted (Postfix + OpenDKIM)

Plus de travail, plus de contrôle. Installation sur Debian/Ubuntu :

apt install opendkim opendkim-tools
mkdir -p /etc/opendkim/keys/votre-domaine-phishing.fr
cd /etc/opendkim/keys/votre-domaine-phishing.fr
opendkim-genkey -s mail -d votre-domaine-phishing.fr -b 2048
chown opendkim:opendkim mail.private

La commande produit deux fichiers : mail.private (clé privée, à garder côté serveur) et mail.txt (clé publique formatée pour publication DNS).

Publier la clé publique en TXT sous mail._domainkey.votre-domaine-phishing.fr. Le contenu du mail.txt ressemble à :

mail._domainkey  IN  TXT  ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )

Configuration /etc/opendkim.conf minimale :

Syslog                  yes
UMask                   002
Domain                  votre-domaine-phishing.fr
KeyFile                 /etc/opendkim/keys/votre-domaine-phishing.fr/mail.private
Selector                mail
Socket                  inet:8891@localhost
KeyTable                /etc/opendkim/key.table
SigningTable            refile:/etc/opendkim/signing.table
ExternalIgnoreList      refile:/etc/opendkim/trusted.hosts
InternalHosts           refile:/etc/opendkim/trusted.hosts

/etc/opendkim/key.table :

mail._domainkey.votre-domaine-phishing.fr votre-domaine-phishing.fr:mail:/etc/opendkim/keys/votre-domaine-phishing.fr/mail.private

/etc/opendkim/signing.table :

*@votre-domaine-phishing.fr mail._domainkey.votre-domaine-phishing.fr

Côté Postfix, dans /etc/postfix/main.cf :

milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Redémarrer OpenDKIM puis Postfix. Vérifier que le port 8891 est bien à l’écoute :

ss -tlnp | grep 8891

Vérifier la signature

Envoyer un message depuis le MTA GoPhish vers check-auth@verifier.port25.com. La réponse arrive en moins d’une minute et liste, ligne par ligne, le résultat SPF, le résultat DKIM, le résultat DMARC, et les éventuelles erreurs d’alignement. C’est l’outil le plus rapide pour valider l’ensemble du stack avant warm-up.

Alternative en ligne de commande sur le serveur :

opendkim-testmsg < /path/to/un-message.eml

Étape 4 — DMARC

DMARC ne signe rien et ne vérifie rien par lui-même. Il dit aux destinataires quoi faire quand SPF ou DKIM échoue, et il agrège des rapports. Sur un domaine GoPhish, le record progresse en quatre temps.

Démarrage en observation. Premier enregistrement publié dès l’achat du domaine :

_dmarc.votre-domaine-phishing.fr  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@votre-boite-rapports.fr; fo=1"

p=none veut dire : les serveurs destinataires ne bloquent rien sur la base de DMARC, mais envoient les rapports XML quotidiens à l’adresse rua=. On laisse tourner une à deux semaines pour identifier les sources d’envoi parasites ou les sources de désalignement.

Décoder les rapports. Les rapports sont des fichiers XML compressés peu lisibles. Outils gratuits :

Dmarcian — interface web, version gratuite jusqu’à un seuil de volume mensuel.
Postmark DMARC Digest — résumé hebdomadaire par email, gratuit.
parsedmarc — outil open source en Python, parse les XML et exporte vers Elasticsearch ou Splunk. Le bon choix dès qu’on dépasse 10 000 messages par mois.

Le guide d’analyse des rapports DMARC entre dans le détail des champs XML et des cas litigieux.

Durcissement progressif. Une fois que SPF et DKIM passent en alignement sur 100 % des messages issus du MTA GoPhish, on monte :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@votre-boite-rapports.fr; fo=1

Puis 50, puis 100. Enfin :

v=DMARC1; p=reject; rua=mailto:dmarc@votre-boite-rapports.fr; fo=1

Le guide de migration DMARC reject couvre la progression pour un domaine d’entreprise classique. La logique est identique pour un domaine GoPhish, simplement plus rapide : pas de SaaS marketing à inventorier, pas de CRM à intégrer, juste l’IP GoPhish ou le relais.

Avertissement. La politique DMARC publiée ici concerne le domaine d’envoi GoPhish, pas les domaines spoofés par les templates. Un template qui spoofe microsoft.com ne sera évidemment pas accepté par les destinataires si Microsoft a p=reject — c’est l’inverse, c’est ce qui rend la simulation réaliste sans devenir une vraie attaque diffusable. Voir le guide migration DMARC reject.

Étape 5 — rDNS / PTR et HELO

C’est l’étape que beaucoup d’installations GoPhish ratent. Sans PTR correcte, Microsoft 365 rejette la connexion SMTP en bordure de réseau, avant même que le contenu soit évalué.

Configurer la PTR. Sur OVH, Hetzner, Scaleway, Online, la PTR de l’IP du VPS se configure dans le panneau client du fournisseur. Pour AWS EC2 il faut ouvrir un ticket de support. La valeur doit être mail.votre-domaine-phishing.fr — pas une chaîne générique fournie par le hosteur.

Vérification :

dig -x 203.0.113.42 +short

Doit retourner mail.votre-domaine-phishing.fr.. Si la réponse est vide ou pointe vers le hostname générique du fournisseur, ouvrir un ticket avant toute autre étape.

Aligner le HELO/EHLO. Dans Postfix /etc/postfix/main.cf :

myhostname = mail.votre-domaine-phishing.fr
smtp_helo_name = mail.votre-domaine-phishing.fr

Test de cohérence depuis une autre machine :

openssl s_client -connect mail.votre-domaine-phishing.fr:25 -starttls smtp

Le serveur doit répondre avec une bannière contenant mail.votre-domaine-phishing.fr. Si la bannière contient autre chose (par exemple localhost.localdomain ou le hostname par défaut Debian), corriger myhostname et redémarrer Postfix.

A record cohérent. Le FQDN annoncé doit aussi se résoudre vers l’IP en A record :

dig +short A mail.votre-domaine-phishing.fr

Doit retourner l’IP du serveur. Cohérence à trois étages : A → IP, PTR → FQDN, HELO → FQDN. Tous les trois doivent matcher. C’est le triplet de base que tous les MTA destinataires sérieux vérifient.

Étape 6 — Warm-up du domaine et de l’IP

Le warm-up consiste à monter le volume d’envoi progressivement pour bâtir une réputation positive avant le volume cible. Sauter cette étape annule tout le reste : un domaine bien authentifié mais sans historique est traité avec une méfiance maximale par Gmail et Microsoft.

Plan progressif sur 14 à 21 jours

Jour	Volume quotidien	Destinataires	Objectif
J1 – J3	10 messages	Comptes seed personnels	Établir le premier historique d’envoi propre
J4 – J7	50 messages	Seeds + premiers comptes test entreprise	Diversifier les destinataires sans déclencher de spike
J8 – J14	200 messages	Cible élargie, premiers utilisateurs réels	Confirmer la réputation et corriger les anomalies
J15+	Volume cible	Population complète	Régime de croisière

Les boîtes seed, ce sont des comptes test sur chacun des services destinataires majeurs : Gmail, Microsoft 365 (un tenant test), Outlook.com, Yahoo, ProtonMail. Idéalement un compte par service avec un historique d’activité minimal — un compte créé deux jours avant le warm-up n’apporte presque rien.

À chaque envoi, l’opérateur ouvre les seeds, vérifie où le message atterrit (inbox, promotions, spam), et marque comme « pas spam » les messages mal classés. Cette action humaine est captée par les filtres et compte dans le score.

Monitorer la réputation pendant le warm-up

Google Postmaster Tools — accessible après vérification du domaine par TXT. Affiche la réputation du domaine (Low / Medium / High / Very High), la réputation de l’IP, le taux de spam déclaré par les utilisateurs Gmail, et les erreurs d’authentification. Pendant un warm-up, viser une montée progressive vers High. Si le score reste à Low après 7 jours d’envois propres, il y a un problème en amont — généralement un défaut d’alignement DMARC ou un contenu trop signalant.

Microsoft SNDS (Smart Network Data Services) — équivalent pour Outlook.com, Hotmail, Live. Inscription par IP, validation manuelle par Microsoft sous 2 à 5 jours. Affiche le taux de plaintes (Complaint Rate), le statut de la réputation, et la classification (Green / Yellow / Red).

Cisco Talos Intelligence — lookup d’une IP ou d’un domaine pour voir comment Cisco Talos (utilisé par énormément de passerelles email d’entreprise) classe la réputation.

Tableau de bord minimum pendant le warm-up : un onglet Google Postmaster, un onglet Microsoft SNDS, un check Talos hebdomadaire, un test mail-tester avant chaque palier de volume.

Étape 7 — Monitoring continu

Le warm-up se termine. Le volume cible est atteint. Le monitoring ne s’arrête pas.

Boîtes seed permanentes. Chaque campagne démarre par un envoi sur les seeds. Si Gmail commence à placer en spam ce qui partait en inbox la semaine précédente, c’est un signal de dégradation. Mieux vaut détecter en seed que via les utilisateurs réels qui n’ont aucune raison d’ouvrir un ticket.

Logs MTA. Pour Postfix :

journalctl -u postfix -f

Surveiller les codes SMTP : 421, 450, 451 (temporisations), 550 (rejet hard), 554 (rejet par politique). Un taux de 550 supérieur à 1 % indique soit une liste de destinataires sale, soit une dégradation de réputation.

Pour Amazon SES :

aws ses get-send-statistics --query 'SendDataPoints[-5:]'

Pour Brevo et Sendgrid : les dashboards exposent les métriques bounce rate, block rate, spam complaint rate.

Blacklists. Check hebdomadaire de l’IP d’envoi :

MXToolbox Blacklist Check — couvre une centaine de listes simultanément
Spamhaus lookup — la liste qui compte le plus
Barracuda Reputation Lookup — utilisé par énormément de passerelles d’entreprise

Mail-tester. Avant chaque campagne d’envergure, un envoi vers une adresse mail-tester.com unique générée à la volée, suivi de la consultation du score. Viser 9,5/10 minimum. En dessous, le rapport détaille exactement quel signal manque ou pose problème.

Cas spécial : envoyer vers Microsoft 365

M365 est le destinataire le plus difficile pour GoPhish. Microsoft Defender for Office 365 (MDO) inspecte les liens, simule le rendu, et flagge agressivement tout ce qui ressemble à du phishing — y compris les simulations légitimes. Sans configuration spécifique côté tenant cible, même une infrastructure GoPhish parfaite arrive en quarantaine MDO.

La voie officielle, c’est l’Advanced Delivery Policy de Microsoft Defender. Microsoft documente explicitement la procédure pour les simulations de phishing non-Microsoft : Security & Compliance Center → Threat Management → Policy → Advanced Delivery → Phishing Simulation → ajouter les IPs sources, les domaines d’envoi, et les URLs de simulation. Une fois inscrites dans la liste, les IPs et domaines GoPhish sont exclus des contrôles MDO et atteignent l’inbox sans être réécrits par Safe Links.

Alternative pour les cas où Advanced Delivery n’est pas disponible : un mail flow rule (Exchange admin center → Rules) qui bypasse le filtrage et l’analyse Safe Links pour les messages provenant des IPs GoPhish. Moins propre, mais fonctionnel sur les SKUs Exchange qui n’exposent pas Advanced Delivery.

Le détail des deux méthodes, avec les écueils opérationnels et la procédure pas-à-pas, est traité dans stratégies de délivrabilité GoPhish vers Microsoft 365 — article publié en complément de ce guide.

Cas spécial : envoyer vers Google Workspace

Workspace est plus permissif que M365 mais demande quand même une whitelist explicite pour garantir l’inbox rate.

Procédure : Admin Console → Apps → Google Workspace → Gmail → Spam, Phishing and Malware. La section utile est « Bypass spam filters and hide warnings for messages from senders or domains in selected lists ». Ajouter le domaine d’envoi GoPhish (votre-domaine-phishing.fr) ou les IPs sources.

Cette option contourne le filtrage spam pour les expéditeurs listés, sans dégrader la posture de sécurité globale du tenant (les autres expéditeurs continuent d’être filtrés normalement). Documentation officielle : support.google.com — Customize Gmail message handling for spam.

Sans cette whitelist, même avec authentification parfaite et warm-up correct, les templates les plus mimétiques (M365 login, banque, opérateur télécom) tombent régulièrement en Spam ou en Promotions chez certains utilisateurs.

Les pièges à éviter

Réutiliser un domaine après une campagne ratée. Si une campagne a généré des plaintes utilisateurs, un listing Spamhaus, ou une dégradation visible dans Postmaster Tools, le domaine est cuit pour 4 à 6 mois minimum. Le réutiliser dès la campagne suivante revient à hériter de tous les signaux négatifs accumulés.

Envoyer depuis un range IP partagé sans warm-up. Les IPs partagées chez les VPS bas coût (certains Hetzner, OVH SoYouStart, Contabo) sont souvent déjà listées chez Spamhaus à cause d’autres clients du même range. Avant d’engager un warm-up, faire un check Spamhaus de l’IP attribuée. Demander une réattribution si nécessaire.

Liens raccourcis (bit.ly, tinyurl). Déclencheur quasi-systématique des classificateurs Gmail et M365. Une URL longue qui pointe vers le domaine d’envoi GoPhish passe mieux qu’un bit.ly qui redirige vers le même endroit.

Templates HTML image-only. Un message composé d’une seule image, sans texte exploitable, est un pattern classique de spam (les classificateurs ne peuvent pas analyser le contenu). Viser un ratio texte/image au moins équilibré, idéalement plus de texte que d’image.

Pièces jointes .exe, .zip, documents avec macros. Bloquées d’office en bordure par M365 et Gmail. Même si un message passe, la simple présence d’une PJ exécutable dans l’historique d’envoi du domaine dégrade la réputation pour toutes les campagnes suivantes.

Tags UTM Google Analytics dans les liens. Un email présenté comme venant de la DSI ou de l’ANSSI avec des paramètres ?utm_source=newsletter&utm_campaign=... est immédiatement identifié comme commercial par les classificateurs. À retirer systématiquement des liens dans les templates internes.

Réalité économique

Un setup propre — domaine, MTA, SPF, DKIM, DMARC, rDNS, warm-up, monitoring — demande 1 à 2 jours d’un ingénieur IT compétent en email et DNS pour la mise en route. Cette estimation ne couvre pas la phase d’apprentissage : une personne qui découvre OpenDKIM ou Postfix doublera facilement le temps.

Maintenance courante : 2 à 4 heures par mois. Surveillance des rapports DMARC, rotation occasionnelle de clés DKIM, monitoring des blacklists, ajustement du plan d’envoi, gestion des cas particuliers M365 ou Workspace pour les nouveaux clients ou tenants.

À chaque incident de réputation (listing, plainte utilisateur, baisse Postmaster Tools), c’est 1 à 2 jours supplémentaires pour diagnostiquer, sortir des blacklists, voire reconstruire un nouveau domaine si le précédent est définitivement cramé.

Pour une équipe IT qui fait de la simulation 4 fois par an sur 200 collaborateurs, l’addition est supportable. À partir d’un programme continu sur plusieurs entités, ou de besoins multi-domaines, ça devient un poste à temps partiel. Plus quelques licences relais, les outils Postmaster/SNDS, et l’inévitable apprentissage par erreurs sur les premières campagnes.

C’est précisément ce que nophi.sh prend en charge à la place de l’équipe interne : domaines préchauffés, authentification managée, intégration M365/Workspace, monitoring continu — sans avoir à entretenir l’infrastructure. Voir tarifs et fonctionnalités, et l’analyse comparative dans GoPhish en entreprise : les vraies limites.

Pour aller plus loin

Installer GoPhish sur un VPS — le guide d’installation initial
Déploiement GoPhish avec Docker Compose — alternative containerisée
Configurer SPF, DKIM, DMARC — référence canonique pour un domaine corporate
Délivrabilité email d’entreprise — guide général sur la délivrabilité hors simulation
Migration DMARC reject — protocole pour durcir DMARC sans casser les envois légitimes
Analyser les rapports DMARC — décodage des fichiers XML agrégés
GoPhish en entreprise : limites — analyse honnête des contraintes opérationnelles
GoPhish vers Microsoft 365 : stratégies — article complémentaire sur le contournement MDO

Références techniques

RFC 7208 — Sender Policy Framework (SPF)
RFC 6376 — DomainKeys Identified Mail (DKIM)
RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
RFC 8058 — Signaling One-Click Functionality for List Email Headers
M3AAWG Sender Best Common Practices — référence industrielle pour les bonnes pratiques d’envoi
Google Sender Guidelines — exigences depuis février 2024 pour les expéditeurs en volume
Microsoft Advanced Delivery Policy — documentation officielle pour les simulations de phishing tierces

Pour un guide d’autorité publique côté français, l’ANSSI publie un document de bonnes pratiques email reprenant les fondamentaux SPF/DKIM/DMARC, repris et synthétisé dans le guide configuration SPF DKIM DMARC.

Le passage par GoPhish vous coûte ce travail d’infrastructure. La simulation de phishing managée nophi.sh ne le facture pas séparément — elle l’inclut. Voir tarifs.