Hornetsecurity Secure Email Gateway (ex-Vade) : architecture, configuration DNS et alternatives

⚡TL;DR

• 🛡️ Hornetsecurity 365 Total Protection est un Secure Email Gateway cloud orienté PME et MSP, avec environ 125 000 clients et plus de 12 000 partenaires. Il s'intercale devant Microsoft 365 via redirection MX et filtre le trafic entrant.
• 🔁 La marque Vade a disparu. L'éditeur français Vade (anti-phishing IA) a été racheté par Hornetsecurity en mars 2024, puis sa marque a été éteinte en février 2025 lors du rebranding « One Team, one Brand ». On traite donc Vade comme une entité absorbée.
• 🔧 Impact DNS spécifique : MX vers mx01.hornetsecurity.com à mx04 (priorités 10/20/30/40), include spf.hornetsecurity.com, et surtout un DKIM par CNAME (hse1._domainkey / hse2._domainkey). Pas de clé TXT à publier dans votre zone, contrairement à Barracuda ou Mimecast.
• 📊 Nouveau propriétaire depuis décembre 2025 : Proofpoint a finalisé le rachat de Hornetsecurity pour 1,8 milliard de dollars, qui devient sa business unit dédiée aux MSP. En Amérique du Nord, l'offre est désormais commercialisée sous Proofpoint Total Protection (pp-tp.com).

Si vous gérez la messagerie d'une PME, d'un cabinet ou d'un parc de clients en tant que MSP, vous avez probablement croisé Hornetsecurity, ou son ancien concurrent devenu filiale, Vade. L'éditeur allemand revendique environ 125 000 clients et plus de 12 000 partenaires sur un créneau qu'il a patiemment occupé : la sécurité Microsoft 365 vendue par et pour les prestataires informatiques. Là où Proofpoint dominait historiquement le grand compte et Barracuda le SMB américain, Hornetsecurity s'est taillé une place de référence européenne sur le modèle MSP multi-tenant.

Mais analyser Hornetsecurity en 2026, c'est d'abord démêler une triple identité qui prête à confusion. Il y a Hornetsecurity, l'éditeur de Hanovre derrière la suite 365 Total Protection. Il y a Vade, l'éditeur français de Hem (près de Lille), absorbé en 2024 et dont la marque n'existe officiellement plus depuis février 2025. Et il y a Proofpoint, qui a racheté l'ensemble fin 2025. Trois noms, une seule réalité capitalistique aujourd'hui. Mais deux modèles techniques bien distincts continuent de cohabiter, et c'est là que tout se joue côté DNS.

L'enjeu n'a rien d'abstrait. Une passerelle de messagerie sécurisée (en anglais secure email gateway, ou SEG) ne sert à rien si votre domaine reste usurpable faute d'authentification correcte. Filtrer le flux entrant protège vos boîtes. Ça ne protège pas votre marque contre l'usurpation sortante. Avant même de déployer Hornetsecurity, vérifiez où vous en êtes avec le vérificateur de syntaxe DMARC CaptainDNS : c'est lui qui dira si un attaquant peut envoyer du mail en votre nom.

Chez CaptainDNS, nous regardons Hornetsecurity sous l'angle qui nous occupe : l'impact concret sur vos enregistrements DNS et votre authentification email. Déployer 365 Total Protection en mode gateway, c'est rediriger vos MX vers mx01.hornetsecurity.com, ajouter l'include spf.hornetsecurity.com, et déléguer votre DKIM par CNAME. Déployer Vade for M365 en mode API, à l'inverse, ne touche aucun enregistrement DNS. Ce guide couvre la saga des rachats, les deux architectures, la configuration DNS détaillée avec les valeurs réelles, la détection d'un domaine derrière Hornetsecurity, le comparatif et un plan d'action. Et il ne masque pas les incertitudes du post-rachat : on les signale là où elles existent.

📌 Qu'est-ce que la passerelle email de hornetsecurity ?

Hornetsecurity 365 Total Protection est une suite de sécurité email cloud bâtie autour d'un Secure Email Gateway : un filtre hébergé qui inspecte le trafic email entrant avant qu'il n'atteigne votre tenant Microsoft 365. En mode gateway, vous redirigez vos enregistrements MX vers l'infrastructure Hornetsecurity, qui analyse chaque message puis transfère uniquement le trafic propre vers Exchange Online.

Pour les fondamentaux d'un SEG (modèle gateway, redirection MX, distinction avec les solutions ICES API-native), nous renvoyons à notre guide complet sur Barracuda, qui pose ces bases en détail. L'essentiel tient en une phrase : un SEG s'intercale entre Internet et votre messagerie, voit l'intégralité du flux entrant, et bloque les menaces avant la livraison plutôt qu'après coup.

La particularité de Hornetsecurity tient à ce que la marque recouvre deux approches techniques sans grand-chose en commun, héritées de la fusion avec Vade. D'un côté, 365 Total Protection, le SEG classique fondé sur la redirection MX, sujet principal de cet article. De l'autre, Vade for M365, une protection API-native qui s'active par journalisation sans toucher aux MX. Confondre les deux mène droit à l'erreur de diagnostic : un domaine protégé par Vade for M365 ne montre aucune signature DNS, alors qu'un domaine en 365 Total Protection s'identifie au premier coup d'œil à ses MX. On détaille ce contraste plus loin.

La suite 365 Total Protection se décline en plusieurs plans, du filtrage de base (anti-spam, anti-malware) jusqu'aux plans supérieurs qui ajoutent la sandbox ATP, la protection anti-usurpation, la continuité de service, l'archivage légalement conforme et la sauvegarde Microsoft 365. Hornetsecurity y adjoint des modules transverses comme le Security Awareness Service (sensibilisation au phishing) et un DMARC Manager. Tout est piloté depuis un Control Panel multi-tenant, taillé pour les MSP.

🕰️ La saga des rachats : de vade à proofpoint

Trois opérations en moins de deux ans ont fusionné deux éditeurs concurrents, puis passé l'ensemble sous un géant américain. Voici la chronologie, dates à l'appui.

Vade : l'anti-phishing IA français, en api-native

Vade (anciennement Vade Secure) est un éditeur français fondé en 2009 et basé à Hem, dans la métropole lilloise. Sa réputation s'est bâtie sur un moteur d'anti-phishing par intelligence artificielle reconnu, et sur un modèle de distribution orienté fournisseurs d'accès et MSP. Au moment du rachat, l'entreprise revendiquait la protection d'environ 1,4 milliard de boîtes dans le monde et l'analyse de plusieurs milliards de messages par jour, en grande partie via des partenariats opérateurs.

Surtout, Vade portait une approche technique distincte de celle du SEG classique : son produit phare, Vade for M365, fonctionne en API-native sur Microsoft 365. Pas de redirection MX, pas de passerelle physique dans le flux : l'analyse se branche directement sur le tenant via l'API Microsoft. C'est ce savoir-faire que Hornetsecurity, historiquement positionné sur le modèle gateway, est venu chercher.

5 mars 2024 : hornetsecurity rachète vade

Le 5 mars 2024, Hornetsecurity, éditeur allemand basé à Hanovre, annonce le rachat de Vade. L'opération est présentée comme la création d'un champion européen de la sécurité Microsoft 365, combinant la base MSP et la suite 365 Total Protection de Hornetsecurity avec le moteur d'IA et l'empreinte opérateur de Vade. Sur le papier, les deux briques se complètent : un SEG cloud éprouvé d'un côté, une expertise API et anti-phishing de l'autre.

21 février 2025 : « one team, one brand », vade s'éteint

Moins d'un an plus tard, le 21 février 2025, Hornetsecurity acte la fusion des marques sous le mot d'ordre « One Team, one Brand ». La marque Vade disparaît : logo, couleurs, communication et processus sont unifiés sous l'identité Hornetsecurity. Les produits hérités de Vade survivent techniquement (Vade for M365 reste une option de déploiement), mais le nom commercial s'efface. C'est pourquoi cet article traite Vade comme une entité absorbée, dont il reste surtout un modèle technique et un trafic de recherche résiduel.

8 décembre 2025 : proofpoint finalise le rachat

Dernier acte, le 8 décembre 2025 : Proofpoint, acteur américain de référence de la sécurité email, finalise le rachat de Hornetsecurity pour environ 1,8 milliard de dollars. L'opération valorise un revenu récurrent annuel (ARR) d'environ 200 millions de dollars en forte croissance. Hornetsecurity devient une business unit dédiée aux MSP au sein de Proofpoint, comblant précisément le segment SMB et canal où Proofpoint, historiquement tourné vers l'enterprise, était le moins présent. En Amérique du Nord, l'offre est désormais commercialisée sous le nom Proofpoint Total Protection, avec une infrastructure dédiée sous le domaine pp-tp.com. La marque Hornetsecurity reste en revanche en place en Europe, au moins le temps de l'intégration.

🏢 Hornetsecurity en bref

Hornetsecurity est un éditeur allemand de sécurité du cloud, fondé en 2007 et basé à Hanovre, qui revendique environ 125 000 clients et plus de 12 000 partenaires, avec une forte concentration sur le segment PME et le modèle MSP. Sa croissance a été tirée par des rachats successifs et un produit phare, 365 Total Protection, pensé pour le canal.

L'entreprise a longtemps opéré sous le nom Antispameurope avant de devenir Hornetsecurity. Son positionnement n'a guère varié : du filtrage email cloud, rapide à déployer, vendu en marque blanche ou en co-marque par des prestataires informatiques. Là où certains concurrents enterprise s'adressent au client final unique, Hornetsecurity vend au prestataire qui revend. Un MSP provisionne ses clients depuis un Control Panel central, hérite des politiques d'un modèle commun, les affine par tenant, et facture à l'usage. Cette mécanique multi-tenant est le cœur de l'attractivité de Hornetsecurity sur le canal.

La présence est nettement européenne, avec une force commerciale et des datacenters concentrés en Europe (Allemagne et France notamment, cette dernière renforcée par l'apport de Vade). Cette empreinte géographique répond à un argument récurrent du segment : la résidence des données en Europe, attendue par les organisations soumises au RGPD ou réticentes à confier leur flux email à une infrastructure hors UE. Le rachat de Vade a ajouté une R&D anti-phishing reconnue et une empreinte opérateur. Le passage sous Proofpoint apporte, lui, l'adossement à une threat intelligence de premier plan, dont les effets concrets sur le produit restent à observer.

⚙️ Architecture : deux modèles sous un même toit

Hornetsecurity protège Microsoft 365 de deux façons distinctes : le gateway (365 Total Protection) par redirection MX, et l'API-native (Vade for M365) par journalisation. Depuis l'absorption de Vade, ces deux modèles n'ont presque rien en commun côté déploiement et côté DNS. Savoir lequel vous déployez détermine toute la suite de votre configuration. C'est le point d'angle de cet article.

365 total protection : le modèle gateway, redirection mx

Le produit historique de Hornetsecurity, 365 Total Protection, est un SEG classique. Vos enregistrements MX pointent vers l'infrastructure cloud Hornetsecurity. Quand un expéditeur écrit à contact@captaindns.com, son serveur résout le MX, trouve un hôte Hornetsecurity (mx01.hornetsecurity.com et ses pairs), et y livre le message. Hornetsecurity applique sa chaîne d'inspection (réputation, anti-spam, anti-malware, sandbox ATP, anti-phishing), puis transfère le message validé vers Exchange Online.

L'avantage est le même que pour tout SEG : Hornetsecurity voit 100 % du trafic entrant et bloque les menaces avant qu'elles touchent votre tenant. Le revers, c'est un déploiement visible et intrusif. Il faut modifier les MX, ajuster le SPF, déléguer le DKIM, et gérer une bascule sans coupure. C'est précisément l'opération que ce guide détaille.

Vade for M365 : l'api-native, sans changement de mx

L'héritage Vade introduit un modèle radicalement différent. Vade for M365 ne s'intercale pas dans le flux SMTP. Il s'active par journalisation (journaling) Microsoft 365 : on configure une règle de journalisation qui envoie une copie de chaque message à Vade, on associe le tenant et un compte Microsoft 365, et l'analyse se fait après réception, sur la copie. Le moteur applique un apprentissage automatique comportemental pour détecter le spear phishing, les malwares polymorphes et les menaces zero-day, avec remédiation possible des messages déjà livrés.

Conséquence majeure pour qui nous lit : ce déploiement est invisible côté DNS. Aucun changement de MX, aucune signature SPF entrante, rien à publier dans la zone. La protection vit entièrement dans la relation API/journaling entre le tenant et Vade. C'est commode : déploiement « sans coupure », et aucun risque de perte de mail lié à une mauvaise bascule MX. Mais cela soulève une question d'audit, que nous reprenons plus bas : on ne peut pas détecter cette protection par un simple lookup DNS.

Api-native contre gateway/mx : ce qui change vraiment

Trois différences séparent vraiment les deux modèles.

Visibilité du flux. Un SEG en mode gateway voit le message avant sa livraison et peut le bloquer en pré-réception. Une protection API/journaling analyse une copie après réception, puis agit en remédiation (déplacement ou suppression a posteriori). La fenêtre d'exposition n'est donc pas la même. La gateway empêche, l'API rattrape.

Détectabilité DNS. La gateway laisse des traces nettes : MX, SPF, DKIM CNAME, autodiscover. L'API ne laisse aucune trace DNS entrante. Pour un auditeur externe, un domaine sous Vade for M365 ressemble à un domaine Microsoft 365 nu.

Intégration et risque opérationnel. La gateway impose une bascule MX, avec son risque classique de perte de mail si elle est mal menée, mais elle offre un contrôle total du flux. L'API, elle, se déploie en quelques clics sans toucher au DNS, au prix d'une dépendance à l'API Microsoft et d'une action menée après livraison. Beaucoup d'organisations déjà full M365 vont vers l'API pour sa simplicité. Celles qui veulent intercepter avant la boîte gardent le gateway.

🔧 Configuration DNS étape par étape

Cette section concerne le mode gateway (365 Total Protection). Le déploiement modifie quatre familles d'enregistrements : MX, SPF, DKIM et DMARC, plus un éventuel CNAME autodiscover. Une erreur sur l'un d'eux, et vos emails disparaissent ou contournent le filtrage. Voici chaque étape avec les valeurs réelles communiquées par Hornetsecurity à l'onboarding, et les pièges à éviter.

Les enregistrements MX

En région européenne, Hornetsecurity fait pointer les MX vers quatre hôtes, avec des priorités étagées pour la redondance :

10 mx01.hornetsecurity.com.
20 mx02.hornetsecurity.com.
30 mx03.hornetsecurity.com.
40 mx04.hornetsecurity.com.

Le serveur le plus prioritaire (priorité 10) reçoit le trafic ; les suivants assurent la bascule en cas d'indisponibilité. C'est une nomenclature régionale générique, à la différence de Barracuda dont le MX intègre un identifiant de compte unique. Cette généricité est commode pour la détection (voir plus loin), mais elle implique que le routage vers votre tenant se configure côté Control Panel, pas via le hostname MX.

Point crucial post-rachat : en Amérique du Nord, la même offre passe sous la marque Proofpoint Total Protection, dont l'infrastructure repose sur le domaine pp-tp.com (relais d'envoi du type relay01-hz14.pp-tp.com, include SPF spf.pp-tp.com). Les valeurs MX entrantes nord-américaines diffèrent donc des valeurs européennes et vous sont communiquées lors de l'activation, via le panneau d'administration. Ne reportez pas mécaniquement les valeurs mx01.hornetsecurity.com si votre tenant est provisionné en région nord-américaine : confirmez toujours les hôtes exacts dans votre Control Panel.

# Vérifier les MX actuels
dig MX captaindns.com +short

Le piège du MX résiduel. Après la bascule vers Hornetsecurity, ne laissez aucun MX résiduel pointant vers votre ancien serveur ou directement vers votre tenant *.mail.protection.outlook.com. Un MX résiduel est une porte dérobée : un attaquant qui connaît votre infrastructure Microsoft 365 peut livrer directement à vos boîtes en contournant Hornetsecurity. Après la bascule, vérifiez avec dig MX qu'il ne reste que les MX Hornetsecurity, et verrouillez votre connecteur Microsoft 365 pour n'accepter que le trafic provenant de Hornetsecurity.

Un déploiement propre prévoit aussi un CNAME autodiscover pointant vers autodiscover.hornetsecurity.com, qui facilite la configuration automatique des clients de messagerie. Il n'est pas indispensable au filtrage, mais il fait partie de la configuration type documentée par l'éditeur.

Le SPF avec l'include hornetsecurity

Pour le mail sortant relayé par Hornetsecurity, vous ajoutez l'include SPF de l'éditeur. La valeur communiquée à l'onboarding européen est simple et sans variante régionale apparente côté SPF entrant :

v=spf1 include:spf.hornetsecurity.com ~all

En Amérique du Nord (Proofpoint Total Protection), l'include devient include:spf.pp-tp.com. Dans les deux cas, si vous envoyez aussi depuis Microsoft 365 directement, vous combinez les includes :

v=spf1 include:spf.protection.outlook.com include:spf.hornetsecurity.com -all

Hornetsecurity documente le ~all (softfail) dans son exemple d'onboarding, mais vous pouvez durcir en -all (hardfail) une fois votre inventaire d'expéditeurs complet et votre DMARC stabilisé. Le -all ajoute une protection au niveau SPF lui-même, là où le ~all laisse passer en cas d'échec sans bloquer. Surveillez surtout le nombre total de lookups DNS : la spécification SPF (RFC 7208) impose une limite de 10 lookups récursifs. Cumulez Hornetsecurity, Microsoft 365 et deux ou trois ESP (Mailchimp, SendGrid, etc.), et vous approchez vite du plafond, avec un PermError à la clé qui casse toute la validation SPF. Le vérificateur de syntaxe SPF CaptainDNS décompte ces lookups et signale les dépassements.

Le DKIM par CNAME, le différenciateur

C'est ici que Hornetsecurity se distingue nettement de Barracuda ou Mimecast. Au lieu de vous faire publier une clé publique TXT générée en console, Hornetsecurity opère la signature DKIM de son côté et vous demande simplement de déléguer deux sélecteurs par enregistrements CNAME :

hse1._domainkey.captaindns.com.  CNAME  hse1._domainkey.hornetsecurity.com.
hse2._domainkey.captaindns.com.  CNAME  hse2._domainkey.hornetsecurity.com.

La conséquence pratique est commode : aucune clé TXT dans votre zone, donc aucune rotation de clé à gérer manuellement de votre côté. Hornetsecurity fait tourner ses clés derrière le CNAME, de façon transparente. Vous publiez les deux CNAME une fois pour toutes, puis vous activez la signature (et, si souhaité, la validation DKIM entrante) dans le Control Panel, sous Email Authentication. La présence de deux sélecteurs (hse1 et hse2) permet justement la rotation côté éditeur sans intervention sur votre DNS.

# Vérifier la délégation DKIM par CNAME
dig CNAME hse1._domainkey.captaindns.com +short
# Réponse attendue : hse1._domainkey.hornetsecurity.com.

Le revers de cette commodité, c'est une dépendance : votre DKIM repose entièrement sur la chaîne CNAME vers Hornetsecurity. Si la délégation casse (CNAME supprimé, zone mal éditée, ou problème côté résolution de la cible), votre signature DKIM tombe, et avec elle l'alignement DMARC. Nous y revenons dans les limites.

L'alignement DMARC

DMARC vérifie que le domaine visible dans le champ From est aligné avec le domaine authentifié par SPF ou DKIM, et définit la politique à appliquer en cas d'échec. Derrière une passerelle, un point mérite l'attention : le relais sortant via Hornetsecurity peut réécrire l'enveloppe SMTP, ce qui fait perdre l'alignement SPF côté destinataire. C'est alors DKIM qui devient le pilier de l'alignement DMARC. D'où l'importance de poser correctement les deux CNAME DKIM avant de durcir la politique : sans signature DKIM valide, des messages pourtant légitimes échoueront à DMARC une fois en p=reject.

La progression recommandée est la même que pour tout déploiement :

1. p=none (surveillance) : vous recevez les rapports agrégés sans affecter la livraison. Durée : 2 à 4 semaines.
2. p=quarantine : les messages non authentifiés partent en spam. Durée : 2 à 4 semaines.
3. p=reject : les messages non authentifiés sont rejetés. C'est la politique cible.

Exemple d'enregistrement DMARC de départ :

v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com; fo=1;

Hornetsecurity propose un module DMARC Manager qui agrège et visualise les rapports, identifie les sources d'envoi légitimes non encore authentifiées et accompagne la montée vers p=reject. Si vous pilotez DMARC avec un autre outil, validez chaque évolution de l'enregistrement avec le vérificateur de syntaxe DMARC CaptainDNS.

🔍 Détecter qu'un domaine est protégé par hornetsecurity

Pour savoir si un domaine utilise 365 Total Protection en mode gateway, examinez ses enregistrements DNS : un MX se terminant par .hornetsecurity.com, un include spf.hornetsecurity.com, ou des CNAME hse1._domainkey / hse2._domainkey pointant vers hornetsecurity.com sont des signatures non ambiguës. À une réserve de taille : cette détection ne marche que pour le modèle gateway, pas pour Vade for M365 en mode API.

À quoi ça sert ? Auditer un prospect avant un rendez-vous, qualifier la stack d'un partenaire, ou simplement comprendre par quoi transitent vos propres emails. La méthode repose sur quatre signatures DNS.

Signature MX. Tout MX dont le hostname se termine par .hornetsecurity.com (les hôtes mx01 à mx04) indique un domaine derrière 365 Total Protection en mode gateway.

# Détecter Hornetsecurity via le MX
dig MX captaindns.com +short
# Réponses du type "10 mx01.hornetsecurity.com." = 365 Total Protection (gateway)

Signature SPF. La présence d'un include:spf.hornetsecurity.com (ou include:spf.pp-tp.com en Amérique du Nord) dans l'enregistrement TXT du domaine confirme que Hornetsecurity relaie le mail sortant.

# Détecter Hornetsecurity via le SPF
dig TXT captaindns.com +short | grep spf
# Présence de "include:spf.hornetsecurity.com" = relais sortant Hornetsecurity

Signatures DKIM et autodiscover. Les CNAME hse1._domainkey / hse2._domainkey vers hornetsecurity.com, et un éventuel CNAME autodiscover vers autodiscover.hornetsecurity.com, complètent le faisceau d'indices et confirment la délégation de signature.

# Détecter la délégation DKIM Hornetsecurity
dig CNAME hse1._domainkey.captaindns.com +short
# Réponse "hse1._domainkey.hornetsecurity.com." = DKIM délégué à Hornetsecurity

Pour une analyse complète et lisible des enregistrements d'un domaine sans manipuler dig, utilisez l'outil DNS Lookup de CaptainDNS, qui affiche les MX, TXT et CNAME en un coup d'œil. Croiser MX, SPF et CNAME DKIM lève toute ambiguïté sur le mode gateway.

Le point clé à retenir : Vade for M365 est indétectable en DNS. Comme il se déploie par journalisation Microsoft 365 sans toucher aux MX ni au SPF entrant, un domaine protégé par Vade for M365 ne présente aucune signature DNS de Hornetsecurity. C'est une limite structurelle de tout audit externe : l'absence de signature DNS ne prouve pas l'absence de protection. Pour ces déploiements, seule une inspection de la configuration interne du tenant (règles de journalisation, applications connectées) permet de conclure.

🔄 Comparatif face à proofpoint, barracuda, mimecast et microsoft

Hornetsecurity se distingue par son positionnement PME et MSP européen, désormais adossé à Proofpoint. Le tableau ci-dessous compare les critères qui pèsent réellement dans un choix. La ligne « Proofpoint » est à lire avec la nuance qu'impose le rachat : Hornetsecurity fait maintenant partie de Proofpoint, mais les deux produits gardent leur positionnement distinct (SMB/MSP pour Hornetsecurity, enterprise pour Proofpoint historique).

Critère	Hornetsecurity	Proofpoint	Barracuda	Mimecast	Microsoft Defender
Type	SEG cloud (365 TP) + API (Vade for M365)	SEG enterprise + ICES	SEG cloud + Inbox Defense API	SEG + API	Natif M365
Cible	PME, MSP (Europe)	Fortune 100, grandes ETI	PME, mid-market, MSP	PME/ETI multi-besoins	Environnements M365
Détection IA	ML comportemental + moteur Vade anti-phishing	Nexus AI	Impersonation Protection	CyberGraph	Détection native
MSP multi-tenant	Oui (point fort historique)	Via la BU Hornetsecurity	Oui (point fort)	Partiel	Via partenaires CSP
Modèle DNS	API (sans MX) ou gateway (MX)	Gateway/MX	Gateway/MX	Gateway/MX	API/natif (sans MX)
DMARC	DMARC Manager intégré	EFD avec consultants	Domain Fraud (Premium Plus)	DMARC Analyzer intégré	Non
Format MX	mx01.hornetsecurity.com (EU)	mx0a-XXXX.pphosted.com	<id>.ess.barracudanetworks.com	eu-smtp-inbound-1.mimecast.com	*.mail.protection.outlook.com
Idéal pour	PME/MSP Europe, double modèle API+gateway	Threat intel d'élite	SMB et MSP, simplicité/prix	Centraliser sécurité + archivage	Full M365, budget serré

Proofpoint, le propriétaire et le concurrent enterprise

Le cas Proofpoint est particulier puisque, depuis décembre 2025, Hornetsecurity lui appartient. Mais les deux produits restent distincts : Proofpoint historique vise le très grand compte, avec sa threat intelligence d'élite et son approche people-centric, à un coût et une complexité qui dépassent largement les besoins d'une PME. Hornetsecurity comble le segment SMB/MSP que Proofpoint adressait mal. Pour un acheteur, le choix n'est donc pas « Hornetsecurity ou Proofpoint » dans l'absolu, mais « quel produit du portefeuille Proofpoint correspond à ma taille ». Notre guide complet sur Proofpoint détaille l'offre enterprise et sa configuration DNS.

Barracuda, le concurrent direct sur le même segment

Sur le segment PME et MSP, Barracuda Email Gateway Defense est le concurrent le plus frontal de Hornetsecurity. Même modèle gateway/MX, même cœur de cible, même argument multi-tenant pour les MSP. La différence se joue dans les détails : Barracuda fait publier une clé DKIM TXT là où Hornetsecurity délègue par CNAME, son MX intègre un identifiant de compte unique, et sa couverture régionale (six régions) diffère de l'empreinte plutôt européenne de Hornetsecurity. Notre guide complet sur Barracuda détaille son architecture et sa configuration DNS pour la comparaison fine.

Mimecast, abnormal et microsoft defender

Sur l'ETI multi-besoins, Mimecast propose une suite plus large en natif (archivage longue durée, continuité, DMARC Analyzer), au prix d'une console plus complexe. Côté détection comportementale pure et API-native, Abnormal Security excelle sur le BEC et le VEC et s'utilise souvent en complément d'un SEG plutôt qu'en remplacement (voir notre guide complet sur Abnormal Security) ; son approche API rappelle d'ailleurs celle de Vade for M365. Enfin, si vous êtes full Microsoft 365 avec des besoins standards, Defender for Office 365 reste imbattable en ratio prix/couverture (protection native sans changement de MX, souvent inclus en licence E5). Hornetsecurity garde l'avantage sur l'indépendance produit et sur le modèle MSP, mais la décision dépend de votre taille, de votre canal et de votre exigence de résidence des données.

🖥️ Migration et déploiement

Le déploiement en mode gateway se fait sans coupure si l'on suit l'ordre : inventaire DNS, choix du modèle, configuration de la console, bascule MX, puis authentification et surveillance. La séquence ci-dessous détaille les cinq étapes.

Guide de déploiement en 5 étapes, de l'inventaire DNS à la bascule MX ou l'activation du journaling

1. Documentez l'état actuel de vos enregistrements MX, SPF, DKIM et DMARC avec les outils CaptainDNS. Recensez surtout toutes les sources d'envoi légitimes de votre domaine : Microsoft 365, marketing (Mailchimp, HubSpot), transactionnel (SendGrid, Mailgun), CRM, ticketing. Chacune devra être authentifiée dans votre nouvelle configuration SPF et prise en compte dans la roadmap DMARC, en restant sous la limite de 10 lookups.

2. Tranchez entre les deux approches. Le mode gateway (365 Total Protection) intercepte avant la boîte, voit 100 % du flux entrant, mais impose une bascule MX et une configuration DNS complète. Le mode API (Vade for M365) se déploie par journalisation sans toucher au DNS, analyse une copie après réception et remédie a posteriori. Le choix dépend de votre tolérance au risque, de votre exigence d'interception pré-livraison et de votre confort avec une bascule MX.

3. Dans le Control Panel Hornetsecurity (ou Proofpoint Total Protection en Amérique du Nord), ajoutez votre domaine, vérifiez-en la propriété et synchronisez l'annuaire utilisateur. Récupérez les valeurs DNS exactes communiquées à l'onboarding pour votre région (MX, include SPF, CNAME DKIM, autodiscover) : elles diffèrent entre l'Europe (hornetsecurity.com) et l'Amérique du Nord (pp-tp.com). En mode API, configurez plutôt la règle de journalisation et l'association du tenant.

4. En mode gateway, publiez les MX mx01 à mx04.hornetsecurity.com (priorités 10/20/30/40) hors heures de pointe, supprimez tous les anciens MX, et verrouillez votre connecteur Microsoft 365 pour n'accepter que le trafic Hornetsecurity (fermeture de la porte dérobée du MX résiduel). En mode API, activez la règle de journalisation M365 et vérifiez que les copies remontent bien vers Vade. Vérifiez le résultat avec dig MX captaindns.com +short.

5. Ajoutez l'include SPF Hornetsecurity en restant sous les 10 lookups. Publiez les deux CNAME DKIM (hse1 et hse2._domainkey) et activez la signature dans le Control Panel. Déployez DMARC en p=none, surveillez les rapports 2 à 4 semaines, puis montez vers p=quarantine et p=reject. Validez chaque enregistrement avec les vérificateurs CaptainDNS.

⚠️ Limites et points de vigilance

Hornetsecurity est solide sur son segment, mais quelques points méritent une vigilance honnête, surtout dans le contexte post-rachat.

Incertitude post-rachat Proofpoint. Le rachat est récent (décembre 2025) et l'intégration reste à dérouler. Feuille de route produit, maintien des deux modèles (gateway et Vade for M365), convergence éventuelle avec les briques Proofpoint, évolution tarifaire, devenir de la marque Hornetsecurity en Europe : autant d'inconnues à ce stade. Personne ne peut garantir aujourd'hui la stabilité de l'ensemble, et il vaut mieux le savoir. Pour un engagement pluriannuel, posez ces questions explicitement à l'éditeur et faites inscrire les garanties au contrat.

Couverture régionale et bascule de marque. L'empreinte est nettement européenne. En Amérique du Nord, l'offre passe sous Proofpoint Total Protection avec une infrastructure distincte (pp-tp.com), ce qui change les valeurs DNS et peut compliquer un déploiement multi-régions sous une marque unique. Vérifiez que votre exigence de résidence des données correspond bien à une région disponible.

Faux positifs et quarantaine. Comme tout SEG, Hornetsecurity peut placer en quarantaine des expéditeurs légitimes, surtout dans les premières semaines. Prévoyez une phase de réglage : surveillance active de la quarantaine, listes d'autorisation, ajustement des politiques. C'est un travail d'exploitation classique, mais réel, qu'il ne faut pas sous-estimer au démarrage.

Dépendance à la chaîne CNAME DKIM. Le confort du DKIM par CNAME a un coût : votre signature dépend entièrement de la délégation vers hornetsecurity.com. Une suppression accidentelle d'un CNAME, une zone mal éditée ou un problème côté cible, et votre DKIM tombe, entraînant des échecs DMARC sur du mail pourtant légitime. Surveillez la résolution de ces CNAME comme vous surveilleriez une clé TXT, et documentez-les pour éviter qu'une « purge » de DNS ne les emporte.

📋 Plan d'action recommandé

De l'audit initial à la politique DMARC stricte, voici la séquence complète pour évaluer puis déployer Hornetsecurity.

1. Auditer votre posture email actuelle (MX, SPF, DKIM, DMARC) avec les outils CaptainDNS.
2. Clarifier l'identité produit : vous évaluez Hornetsecurity 365 Total Protection (et/ou Vade for M365), désormais propriété de Proofpoint, et non l'offre enterprise Proofpoint historique.
3. Choisir le modèle : gateway (365 Total Protection, MX) pour intercepter avant la boîte, ou API (Vade for M365, journaling) pour un déploiement sans changement de DNS.
4. Comparer avec Barracuda (concurrent direct PME/MSP), Mimecast, Abnormal et Microsoft Defender selon votre taille, votre canal et votre exigence de résidence des données.
5. Identifier votre région (Europe hornetsecurity.com vs Amérique du Nord pp-tp.com), qui conditionne les valeurs DNS exactes.
6. Configurer la console (Control Panel), ajouter le domaine, vérifier la propriété et synchroniser l'annuaire.
7. Basculer les MX (mx01 à mx04, priorités 10/20/30/40) hors heures de pointe et supprimer tous les anciens MX, ou activer le journaling en mode API.
8. Verrouiller le connecteur Microsoft 365 pour n'accepter que le trafic Hornetsecurity et fermer la porte dérobée du MX résiduel.
9. Mettre en place SPF (include, sous 10 lookups), DKIM (deux CNAME hse1/hse2) et DMARC (p=none puis durcissement), en surveillant la chaîne CNAME DKIM.
10. Surveiller la quarantaine et les rapports DMARC, puis monter vers p=reject après 4 à 8 semaines de surveillance propre.

📚 Guides passerelles email

Cette analyse fait partie de notre série sur les solutions de sécurité email enterprise :

• Mimecast Secure Email Gateway : fonctionnement, configuration DNS, comparatif et plan d'action
• Proofpoint Secure Email Gateway : Nexus AI, TAP, configuration DNS et le nouveau propriétaire de Hornetsecurity
• Cisco Secure Email Cloud Gateway (CES) : architecture SaaS, DNS iphmx.com et migration depuis l'ESA
• Abnormal Security : IA comportementale et déploiement API, comparable au modèle Vade for M365
• Cloudflare Email Service : Email Routing, Security et DMARC Management expliqués
• Barracuda Email Gateway Defense : concurrent direct sur le segment PME/MSP, architecture et configuration DNS
• Hornetsecurity Secure Email Gateway : 365 Total Protection, ex-Vade, désormais Proofpoint (cet article)

FAQ

Qu'est-ce que Hornetsecurity 365 Total Protection ?

Hornetsecurity 365 Total Protection est une suite de sécurité email cloud bâtie autour d'un Secure Email Gateway. En mode gateway, vous redirigez vos enregistrements MX vers l'infrastructure Hornetsecurity (mx01.hornetsecurity.com à mx04), qui inspecte chaque message entrant (réputation, anti-spam, anti-malware, sandbox ATP, anti-phishing) puis transfère le trafic propre vers Microsoft 365. La suite ajoute, selon les plans, la continuité, l'archivage, la sauvegarde M365, un DMARC Manager et un service de sensibilisation. Elle est historiquement orientée PME et MSP, avec environ 125 000 clients dans le monde.

Que devient Vade après le rachat par Hornetsecurity ?

Vade, éditeur français d'anti-phishing par IA (Hem, près de Lille), a été racheté par Hornetsecurity le 5 mars 2024. Sa marque a ensuite été éteinte le 21 février 2025 lors du rebranding « One Team, one Brand », au profit de l'identité Hornetsecurity. Techniquement, le produit Vade for M365 survit comme option de déploiement API-native, mais le nom commercial Vade n'existe plus. On traite donc Vade comme une entité absorbée, dont il reste surtout un modèle technique distinct (API/journaling) et un savoir-faire anti-phishing.

Hornetsecurity appartient-il à Proofpoint ?

Oui. Proofpoint a finalisé le rachat de Hornetsecurity le 8 décembre 2025, pour environ 1,8 milliard de dollars. Hornetsecurity devient la business unit dédiée aux MSP au sein de Proofpoint, comblant le segment SMB et canal où Proofpoint, tourné vers l'enterprise, était le moins présent. En Amérique du Nord, l'offre est désormais commercialisée sous le nom Proofpoint Total Protection, avec une infrastructure dédiée sous le domaine pp-tp.com. La marque Hornetsecurity reste en place en Europe, au moins le temps de l'intégration.

Quels sont les enregistrements MX de Hornetsecurity ?

En région européenne, Hornetsecurity fait pointer les MX vers quatre hôtes avec des priorités étagées : mx01.hornetsecurity.com (priorité 10), mx02.hornetsecurity.com (20), mx03.hornetsecurity.com (30) et mx04.hornetsecurity.com (40). En Amérique du Nord, sous la marque Proofpoint Total Protection, l'infrastructure passe par le domaine pp-tp.com et les valeurs exactes vous sont communiquées lors de l'activation, via le Control Panel. Confirmez toujours les hôtes exacts dans votre panneau d'administration selon votre région.

Quel include SPF utiliser avec Hornetsecurity ?

En Europe, l'include SPF est include:spf.hornetsecurity.com, à placer avant le mécanisme final (~all dans l'exemple d'onboarding, ou -all si vous durcissez après inventaire complet de vos expéditeurs). En Amérique du Nord (Proofpoint Total Protection), l'include devient include:spf.pp-tp.com. Surveillez le nombre total de lookups DNS pour rester sous la limite de 10 imposée par la RFC 7208, surtout si vous cumulez Microsoft 365 et plusieurs ESP.

Comment configurer DKIM avec Hornetsecurity (CNAME) ?

Hornetsecurity opère la signature DKIM de son côté et vous demande de déléguer deux sélecteurs par CNAME : hse1._domainkey.<votre-domaine> vers hse1._domainkey.hornetsecurity.com, et hse2._domainkey.<votre-domaine> vers hse2._domainkey.hornetsecurity.com. Contrairement à Barracuda ou Mimecast, vous ne publiez aucune clé TXT dans votre zone : la rotation des clés se fait côté Hornetsecurity, derrière le CNAME. Une fois les deux CNAME publiés, activez la signature (et éventuellement la validation entrante) dans le Control Panel, sous Email Authentication.

Quelle différence entre l'approche gateway (MX) et l'approche API de Vade ?

Le mode gateway (365 Total Protection) redirige vos MX vers Hornetsecurity, qui filtre 100 % du flux entrant avant livraison ; il est visible en DNS (MX, SPF, CNAME DKIM). Le mode API (Vade for M365) se déploie par journalisation Microsoft 365 sans changement de MX, analyse une copie après réception et remédie a posteriori ; il est invisible en DNS. La gateway empêche en pré-livraison mais impose une bascule MX ; l'API rattrape en post-livraison mais se déploie sans toucher au DNS. Le choix dépend de votre besoin d'interception et de votre tolérance à une bascule MX.

Comment détecter qu'un domaine est protégé par Hornetsecurity ?

Pour le mode gateway, quatre signatures DNS l'identifient : un MX se terminant par .hornetsecurity.com (mx01 à mx04), un include:spf.hornetsecurity.com dans le TXT, des CNAME hse1._domainkey / hse2._domainkey vers hornetsecurity.com, et un éventuel CNAME autodiscover. Croiser ces signatures lève toute ambiguïté. Attention toutefois : le mode API (Vade for M365) est indétectable en DNS, car il se déploie par journalisation sans toucher aux MX. L'absence de signature DNS ne prouve donc pas l'absence de protection. L'outil DNS Lookup de CaptainDNS affiche ces enregistrements de façon lisible.

Hornetsecurity fonctionne-t-il avec Microsoft 365 et Google Workspace ?

Hornetsecurity est conçu d'abord pour Microsoft 365, où les deux modèles s'appliquent : le gateway (redirection MX vers Hornetsecurity puis transfert vers Exchange Online) et l'API/journaling (Vade for M365), ce dernier étant nativement lié à M365. Le mode gateway, fondé sur la redirection MX, reste en théorie indépendant du serveur de destination et peut protéger d'autres environnements via redirection MX, mais l'écosystème, le DMARC Manager et Vade for M365 sont taillés pour M365. Pour Google Workspace ou un déploiement hybride, confirmez la compatibilité exacte et le mode supporté auprès de l'éditeur.

Hornetsecurity est-il adapté aux PME et MSP ?

Oui, c'est son positionnement de prédilection. La suite est conçue pour être simple à déployer et à opérer sans équipe SOC dédiée, et son Control Panel multi-tenant permet à un MSP de provisionner, configurer et superviser la sécurité email de dizaines de clients depuis une console centrale, avec facturation à l'usage. C'est l'un des programmes MSP les plus aboutis en Europe, ce qui explique d'ailleurs l'intérêt de Proofpoint, qui en a fait sa business unit MSP mondiale après le rachat de décembre 2025.

Télécharger les tableaux comparatifs

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.

• Télécharger le comparatif (CSV)
• Télécharger le comparatif (JSON)

Glossaire

• SEG (Secure Email Gateway) : passerelle de sécurité email qui filtre le trafic entrant (et parfois sortant) entre Internet et le serveur de messagerie, analysant chaque message (spam, malware, hameçonnage) avant de le transmettre au destinataire.

• 365 Total Protection : la suite de sécurité email cloud de Hornetsecurity, articulée autour d'un SEG en mode gateway (redirection MX) pour protéger Microsoft 365. Sujet principal de cet article.

• Vade for M365 : produit hérité de l'éditeur Vade, protection email API-native qui s'active par journalisation Microsoft 365, sans changement de MX. Analyse une copie des messages après réception, avec remédiation a posteriori.

• MX (Mail Exchanger) : enregistrement DNS qui indique les serveurs responsables de la réception des emails d'un domaine. Déployer 365 Total Protection en gateway implique de rediriger les MX vers mx01.hornetsecurity.com à mx04.

• SPF (Sender Policy Framework) : protocole d'authentification qui liste les serveurs autorisés à envoyer des emails pour un domaine. Enregistrement TXT limité à 10 lookups récursifs (RFC 7208). Hornetsecurity utilise include:spf.hornetsecurity.com (ou spf.pp-tp.com en Amérique du Nord).

• DKIM par CNAME : méthode où le client ne publie pas de clé publique TXT mais délègue la signature par enregistrements CNAME (hse1._domainkey, hse2._domainkey vers hornetsecurity.com). La rotation des clés se fait côté éditeur, de façon transparente. C'est le différenciateur de Hornetsecurity face à Barracuda ou Mimecast.

• DMARC (Domain-based Message Authentication, Reporting and Conformance) : protocole qui vérifie l'alignement entre le domaine From et les domaines authentifiés par SPF ou DKIM, et définit la politique à appliquer en cas d'échec (none, quarantine, reject).

• Journaling (journalisation) : fonctionnalité Microsoft 365 qui envoie une copie des messages à une destination tierce. C'est le mécanisme de déploiement de Vade for M365, qui rend la protection invisible côté DNS.

• MSP (Managed Service Provider) : prestataire qui gère l'infrastructure IT de plusieurs clients. Le Control Panel multi-tenant de Hornetsecurity est pensé pour ce modèle, qui est son cœur de marché.

• BEC (Business Email Compromise) : fraude par email où l'attaquant se fait passer pour un dirigeant ou un partenaire de confiance pour obtenir un virement ou des données sensibles. Souvent sans lien ni pièce jointe, donc invisible aux filtres par signature, d'où l'intérêt de la détection comportementale.

• API-native vs gateway : deux modèles de protection email. Le gateway s'intercale dans le flux SMTP par redirection MX et bloque avant livraison ; l'API-native se branche sur le tenant (journaling ou API), analyse après réception et remédie a posteriori, sans toucher au DNS.

Sources

• Proofpoint Newsroom : Proofpoint Completes Acquisition of Hornetsecurity (1,8 Md$, 8 décembre 2025)
• Hornetsecurity : Onboarding information (Europe), MX, include SPF, autodiscover
• Proofpoint Total Protection : Onboarding information North America (pp-tp.com)
• Hornetsecurity KnowledgeBase : How to set up DKIM (CNAME hse1/hse2._domainkey)
• Hornetsecurity Services : 365 Total Protection (suite et plans)
• Proofpoint : Launches Dedicated MSP Business Unit and Introduces 365 Total Protection for North America