Barracuda Email Gateway Defense : architecture, configuration DNS et alternatives

⚡TL;DR

• 🛡️ Barracuda Email Gateway Defense (EGD) est le SEG cloud historiquement orienté PME et MSP, avec plus de 200 000 clients dans le monde. Il s'intercale devant Microsoft 365, Google Workspace ou Exchange via redirection MX et filtre 100 % du trafic entrant.
• 🔧 Impact DNS spécifique : MX au format <identifiant-client>.ess.barracudanetworks.com (priorité 99 pour la phase de test, puis bascule), SPF include régional (spf.ess.barracudanetworks.com aux US, variantes DE/UK/CA/AU/IN), DKIM signé en console et DMARC à piloter vers p=reject.
• ⚠️ Distinction produit cruciale : la CVE-2023-2868 (CVSS 9.8, exploitée par UNC4841) visait l'appliance ESG legacy, pas le service cloud EGD. Ne confondez pas les deux gammes : Barracuda recommande la migration ESG vers EGD.
• 📊 Positionnement : Visionnaire au Magic Quadrant Gartner Email Security pour la 2ᵉ année consécutive (1er décembre 2025), à distinguer des acteurs positionnés en Leaders sur le quadrant 2025. Racheté par KKR en 2022 (~4 Md$) après Thoma Bravo. Cible : SMB, mid-market et MSP multi-tenant.

Si vous êtes une PME, une collectivité, un cabinet ou un MSP qui gère plusieurs dizaines de clients, il y a de fortes chances que vous ayez déjà croisé Barracuda. L'éditeur californien revendique plus de 200 000 clients et s'est imposé comme l'un des fournisseurs de sécurité email les plus déployés sur le segment hors grand compte. Là où Proofpoint domine le Fortune 100 et Mimecast les ETI multi-besoins, Barracuda joue une partition différente : du cloud simple à déployer, un programme MSP solide, une grille tarifaire pensée pour des organisations sans équipe SOC dédiée.

Mais le nom « Barracuda » recouvre en réalité deux produits très différents qu'on confond constamment. D'un côté, Email Gateway Defense (EGD), le SEG cloud dont parle cet article, hébergé sous *.ess.barracudanetworks.com. De l'autre, Email Security Gateway (ESG), l'appliance physique ou virtuelle legacy, celle qui a fait l'actualité en 2023 avec une vulnérabilité critique exploitée par un acteur étatique. Cette confusion n'est pas anodine : elle conduit régulièrement des décideurs à écarter Barracuda sur la foi d'un incident qui ne concernait pas le produit cloud qu'ils envisageaient.

L'enjeu n'a rien de théorique. Le 2025 Email Threats Report de Barracuda, bâti sur près de 670 millions d'emails analysés, chiffre à 24 % la part des messages malveillants ou indésirables, relève qu'un QR code de phishing se cache dans 68 % des PDF piégés et 83 % des documents Office vérolés, et constate que 47 % des domaines email n'ont toujours pas configuré DMARC. Filtrer le flux entrant ne sert à rien si votre domaine reste usurpable faute d'authentification : vérifiez d'abord où vous en êtes avec le vérificateur de syntaxe DMARC CaptainDNS.

Chez CaptainDNS, nous analysons Barracuda sous l'angle qui nous occupe : l'impact sur vos enregistrements DNS et votre authentification email. Déployer EGD, ce n'est pas cocher une case de sécurité. C'est rediriger vos MX vers ess.barracudanetworks.com, ajuster votre SPF avec le bon include régional, publier votre clé DKIM et piloter votre DMARC. Ce guide couvre tout : architecture, configuration DNS détaillée avec les valeurs réelles, méthode de détection d'un domaine derrière Barracuda, distinction EGD/ESG, traitement factuel de la CVE-2023-2868, comparatif et plan d'action.

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

Barracuda Email Gateway Defense est un Secure Email Gateway cloud qui filtre 100 % du trafic email entrant avant qu'il n'atteigne votre serveur de messagerie. Vous redirigez vos enregistrements MX vers l'infrastructure Barracuda, qui inspecte chaque message puis transfère uniquement le trafic propre vers Microsoft 365, Google Workspace ou Exchange.

Pour les bases d'un SEG (modèle gateway, redirection MX, distinction avec les solutions ICES API-native), nous renvoyons à notre article complet sur Mimecast, qui pose ces fondamentaux en détail. Ce qu'il faut retenir : un SEG s'intercale entre Internet et votre messagerie, voit l'intégralité du flux entrant, et bloque les menaces en pré-livraison plutôt qu'après coup.

Là où Barracuda demande de la vigilance, c'est sur la nomenclature produit. Trois noms reviennent en permanence dans la documentation, et les mélanger conduit à des erreurs de configuration coûteuses.

Email Gateway Defense (EGD) est le service SEG cloud, anciennement commercialisé sous les noms Barracuda Email Security Service (BESS) ou « Email Security Essentials ». C'est le sujet de cet article. Tout est hébergé chez Barracuda, sous le domaine ess.barracudanetworks.com. Aucune appliance à gérer, aucun patch à appliquer côté client. Le service vit dans des datacenters régionaux opérés par Barracuda.

Email Security Gateway (ESG) est une tout autre gamme : une appliance physique (matériel rackable) ou virtuelle, déployée on-premise ou dans le cloud du client, que l'organisation administre elle-même. C'est un produit legacy, en fin de cycle commercial, et c'est cette gamme qui a subi la CVE-2023-2868. Barracuda pousse activement la migration des clients ESG vers EGD via son programme « ESG Elevate ».

Barracuda Email Protection est la suite englobante. Elle se décline en trois plans : Advanced, Premium et Premium Plus. EGD constitue la brique de base. Les plans supérieurs ajoutent des modules comme la protection contre la fraude au domaine (DMARC avancé), Impersonation Protection, la sensibilisation utilisateur (Security Awareness Training), le Zero Trust Access et la sauvegarde Cloud-to-Cloud Backup.

🏢 Barracuda : l'entreprise en bref

Barracuda Networks, fondée en 2003 en Californie, est passée d'un fabricant d'appliances anti-spam à un acteur cloud de plus de 200 000 clients, racheté par KKR en 2022. Le chemin tient en vingt ans de pivots et deux rachats par des fonds de private equity.

Barracuda Networks a été fondée en 2003 à Campbell, en Californie. L'entreprise s'est d'abord fait connaître par son Spam Firewall, une appliance matérielle qui démocratisait le filtrage anti-spam pour les PME à une époque où les solutions concurrentes étaient chères et complexes. Ce modèle « appliance simple, prix accessible » a structuré l'ADN de l'éditeur pendant une décennie : du matériel facile à déployer pour des organisations sans grande équipe IT.

Le tournant cloud arrive progressivement dans les années 2010 avec le lancement du Barracuda Email Security Service, ancêtre direct de l'actuel Email Gateway Defense. Au lieu de vendre une boîte à brancher dans le rack, Barracuda héberge le filtrage dans ses propres datacenters. Le client redirige simplement ses MX. Ce pivot accompagne la bascule générale du marché vers Microsoft 365 et Google Workspace, où l'appliance on-premise n'a plus de sens.

Côté capitalistique, Barracuda a connu deux opérations majeures. Thoma Bravo rachète l'entreprise en 2017 pour environ 1,6 milliard de dollars, la retirant de la cotation. Puis, en 2022, KKR acquiert Barracuda auprès de Thoma Bravo pour une valorisation d'environ 4 milliards de dollars, soit plus du double en cinq ans. Ce passage sous KKR a accompagné le repositionnement de Barracuda en plateforme de cybersécurité orientée mid-market et MSP, au-delà du seul email.

Aujourd'hui, Barracuda revendique plus de 200 000 clients dans le monde, avec une concentration forte sur les PME, les ETI et un écosystème MSP particulièrement développé. Le programme partenaire MSP permet à un prestataire de gérer la sécurité email de dizaines de clients depuis une console multi-tenant, avec de la remédiation en masse et une facturation à l'usage. C'est l'un des arguments les plus différenciants de Barracuda face à des concurrents historiquement pensés pour le client final unique.

Côté analystes, Barracuda figure comme Visionnaire au Magic Quadrant Gartner Email Security pour la 2ᵉ année consécutive (édition du 1er décembre 2025). La nuance compte : un Visionnaire a une vision produit reconnue, mais une capacité d'exécution jugée en deçà des Leaders du même quadrant (Proofpoint, Mimecast et Microsoft). Sur la threat intelligence d'élite, Barracuda ne joue donc pas dans la cour de Proofpoint. Les retours clients restent solides : 4,6/5 sur 439 avis Gartner Peer Insights pour le marché Email Security Platforms. Sur le rapport simplicité/prix/couverture, il tient une position solide pour le segment qu'il vise.

⚙️ Architecture technique : comment Barracuda filtre vos emails

Avant d'atteindre votre serveur, chaque message passe par une chaîne de pré-filtrage hébergée dans les datacenters régionaux de Barracuda. S'y ajoutent des modules d'analyse avancée et, sur les plans supérieurs, une couche de détection comportementale par API. On déroule le tout.

Modèle gateway : la redirection MX vers ess.barracudanetworks.com

Comme tout SEG traditionnel, EGD repose sur la redirection MX. Vos enregistrements MX pointent vers l'infrastructure cloud Barracuda, hébergée sous ess.barracudanetworks.com. Quand un expéditeur envoie un email à contact@captaindns.com, son serveur résout le MX, trouve un hôte Barracuda, et y livre le message. Barracuda applique sa chaîne de détection, puis transfère le message validé vers votre serveur réel.

Le flux se déroule en cinq temps :

1. Un expéditeur envoie un email à contact@captaindns.com
2. Son serveur effectue une requête DNS MX pour captaindns.com
3. Le DNS retourne le MX Barracuda (par exemple d9307303a.ess.barracudanetworks.com)
4. Le message arrive chez Barracuda, qui le soumet à sa chaîne d'inspection (réputation, anti-spam, anti-malware, ATP, anti-phishing)
5. Si le message est approuvé, Barracuda le transfère vers votre serveur email réel (Microsoft 365, Google Workspace, Exchange on-premise)

L'avantage est direct : Barracuda voit 100 % du trafic entrant et bloque les menaces avant qu'elles touchent votre infrastructure. Votre serveur ne reçoit que du trafic déjà filtré.

Le pré-filtrage cloud : réputation, anti-spam, anti-malware

La première ligne de défense de Barracuda est un étage de pré-filtrage qui élimine le bruit de fond avant toute analyse coûteuse. Le service score la réputation de l'IP source au moment de la connexion SMTP, en s'appuyant sur les flux de réputation maintenus par Barracuda (l'éditeur opère par ailleurs sa propre Barracuda Reputation Block List, une blacklist historique utilisée bien au-delà de ses propres produits). Les connexions issues de botnets connus ou d'IP massivement signalées sont rejetées dès la poignée de main, sans même analyser le contenu.

Vient ensuite l'analyse anti-spam et anti-malware classique : signatures, heuristiques, scan antivirus multi-moteurs. Cette couche traite le volume rapidement et élimine les menaces connues. C'est efficace sur le spam massif et les malwares répertoriés, mais insuffisant pour les menaces ciblées et les pièces jointes inconnues, d'où les étages suivants.

La sandbox ATP contre les menaces zero-day

L'Advanced Threat Protection (ATP) de Barracuda traite les pièces jointes et les charges utiles que les signatures ne reconnaissent pas. Les fichiers suspects sont redirigés vers un environnement de sandbox où ils sont exécutés et observés : tentatives de connexion sortante, modification de fichiers système, comportement de chiffrement, injection de code. C'est la réponse aux menaces zero-day, pour lesquelles aucune signature n'existe encore.

L'ATP combine analyse statique (inspection de la structure du fichier, des macros, des scripts intégrés) et analyse dynamique (détonation dans la sandbox). Le verdict alimente ensuite les décisions de blocage. Sur les plans supérieurs, il déclenche aussi des actions de remédiation automatisées.

La protection anti-usurpation par IA comportementale

La protection contre l'usurpation est l'un des arguments forts de Barracuda sur le segment PME. Ces organisations sont particulièrement exposées aux attaques de Business Email Compromise (BEC), faute de moyens de détection internes. Le module Impersonation Protection (historiquement issu de la brique « Sentinel ») applique une analyse comportementale par apprentissage automatique pour détecter la fraude.

Le moteur apprend les schémas de communication normaux de l'organisation : qui écrit à qui, depuis quelles adresses, avec quel ton, à quels horaires. Il signale ensuite les anomalies typiques d'une attaque BEC : un email prétendument envoyé par le dirigeant depuis une adresse externe, une demande de virement inhabituelle, un nom affiché qui imite un collaborateur, un domaine ressemblant (typosquatting). Le problème, c'est que ces attaques ne contiennent souvent ni lien ni pièce jointe. Aucune signature ne mord dessus. La détection comportementale reste le seul moyen de les attraper.

La défense par API et la remédiation après livraison

Au-delà de la gateway, les plans supérieurs ajoutent une couche de défense de la boîte de réception par API sur Microsoft 365. Cette approche complète le filtrage en pré-livraison par une analyse post-livraison des messages déjà arrivés, à la manière des solutions ICES. Elle exploite l'accès aux métadonnées internes du tenant (relations entre utilisateurs, historique de communication) pour affiner la détection comportementale.

Le module Incident Response ferme la boucle : quand une menace est identifiée après livraison, l'administrateur (ou le MSP) peut retirer automatiquement le message des boîtes de réception concernées, à l'échelle de tous les utilisateurs touchés. Pour un MSP qui gère des dizaines de tenants, la remédiation en masse est un gain opérationnel décisif : neutraliser une campagne sur l'ensemble du parc en quelques clics, plutôt que tenant par tenant.

Datacenters régionaux et architecture multi-tenant pour MSP

Barracuda opère EGD depuis plusieurs régions géographiques, chacune avec sa propre console et son propre include SPF. Deux enjeux justifient ce découpage : la latence (traiter le mail au plus près de l'organisation) et la résidence des données (un client européen veut ses données traitées en Europe, conformité RGPD oblige). Les régions disponibles aujourd'hui couvrent les États-Unis, l'Allemagne (pour l'Europe), le Royaume-Uni, le Canada, l'Australie et l'Inde.

L'architecture est nativement multi-tenant, taillée pour le modèle MSP. Un prestataire dispose d'une console centrale d'où il provisionne, configure et supervise la sécurité email de tous ses clients. Les politiques s'héritent d'un modèle commun puis s'affinent par tenant, et la facturation suit l'usage. C'est l'une des raisons de la forte présence de Barracuda chez les MSP, là où des solutions enterprise restent lourdes à opérer en mode multi-clients.

🔧 La configuration DNS, étape par étape

Déployer EGD modifie quatre enregistrements DNS : MX, SPF, DKIM et DMARC. Une erreur sur l'un d'eux, et vos emails disparaissent ou contournent le filtrage. Voici chaque étape avec les valeurs réelles et les pièges à éviter.

L'enregistrement MX au format ess.barracudanetworks.com

L'enregistrement MX de Barracuda EGD suit le format <identifiant-client>.ess.barracudanetworks.com. L'identifiant est un code unique généré par Barracuda pour votre compte, visible sur la page de vérification de domaine de la console (section Domains). Par exemple, un compte peut recevoir un MX du type d9307303a.ess.barracudanetworks.com.

C'est une différence notable avec Mimecast ou Proofpoint, dont les MX suivent une nomenclature régionale générique (eu-smtp-inbound-1.mimecast.com, mx0a-XXXXXXXX.pphosted.com). Chez Barracuda, le hostname MX est propre à votre compte, ce qui constitue d'ailleurs une signature de détection commode (voir plus bas).

Barracuda recommande une approche de bascule en deux temps via la priorité MX. Pendant la phase de test, vous ajoutez le MX Barracuda avec une priorité élevée (99), c'est-à-dire la moins prioritaire. Vos MX existants conservent leur priorité basse et continuent de recevoir le mail légitime. Cela vous permet de valider que le compte Barracuda accepte bien le trafic de votre domaine sans risquer de perdre des messages. Une fois la configuration validée, vous inversez : le MX Barracuda passe en priorité basse (10) et vous supprimez les anciens MX.

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

Résultat attendu une fois la bascule terminée :

10 d9307303a.ess.barracudanetworks.com.

Piège classique. Ne laissez aucun MX résiduel pointant vers votre ancien serveur (Exchange on-premise, ou directement 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 Barracuda. Après la bascule, vérifiez avec dig MX qu'il ne reste que le MX Barracuda, et verrouillez votre connecteur M365 pour n'accepter que les IP Barracuda.

Le SPF avec l'include régional

C'est ici que la géographie compte. Pour le mail sortant relayé par Barracuda, vous devez ajouter l'include SPF correspondant à votre région. Utiliser l'include d'une autre région ne fonctionnera pas, car les IP d'envoi diffèrent.

Région	Include SPF	Console régionale
États-Unis (US)	include:spf.ess.barracudanetworks.com	us.ess.barracudanetworks.com
Allemagne / Europe (DE)	include:spf.ess.de.barracudanetworks.com	de.ess.barracudanetworks.com
Royaume-Uni (UK)	include:spf.ess.uk.barracudanetworks.com	uk.ess.barracudanetworks.com
Canada (CA)	include:spf.ess.ca.barracudanetworks.com	ca.ess.barracudanetworks.com
Australie (AU)	include:spf.ess.au.barracudanetworks.com	au.ess.barracudanetworks.com
Inde (IN)	include:spf.ess.in.barracudanetworks.com	in.ess.barracudanetworks.com

Exemple d'enregistrement SPF pour un client US qui envoie aussi via Google Workspace :

v=spf1 include:spf.ess.barracudanetworks.com include:_spf.google.com -all

Barracuda recommande le mécanisme -all (hardfail), plus strict que le ~all (softfail). Avec une politique DMARC en p=reject, le ~all suffit puisque DMARC dicte le rejet, mais le -all ajoute une protection au niveau SPF lui-même, ce qui est cohérent avec la posture par défaut conseillée par l'éditeur. Surveillez tout de même le nombre total de lookups DNS : la spécification SPF (RFC 7208) impose une limite de 10 lookups récursifs. Cumulez Barracuda, Google Workspace et deux ou trois ESP, et vous approchez vite du plafond, avec un PermError à la clé.

Vérifiez votre enregistrement avec le vérificateur de syntaxe SPF CaptainDNS, qui décompte les lookups et signale les dépassements.

La signature DKIM

DKIM signe cryptographiquement vos emails sortants, permettant au destinataire de vérifier qu'ils proviennent bien de votre domaine et n'ont pas été altérés. Avec Barracuda EGD, la configuration se pilote dans la console :

1. Activer la signature DKIM pour votre domaine dans la console EGD (section Outbound / Sender Authentication), en choisissant un sélecteur
2. Récupérer la clé publique générée par Barracuda et la publier dans votre DNS sous forme d'enregistrement TXT à l'emplacement selecteur._domainkey.captaindns.com
3. Activer la signature une fois l'enregistrement DNS propagé et vérifié par la console

Vérification de la publication :

dig TXT barracuda._domainkey.captaindns.com +short

Le résultat doit contenir la clé publique au format v=DKIM1; k=rsa; p=MIGfMA0GCS.... Pensez à choisir une longueur de clé de 2048 bits plutôt que 1024 pour une sécurité conforme aux bonnes pratiques actuelles, et planifiez une rotation tous les six à douze mois.

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. C'est la pièce finale de l'authentification, et Barracuda s'appuie sur votre configuration SPF/DKIM pour produire l'alignement.

Un point souvent négligé en mode passerelle : le relais sortant via Barracuda réécrit l'enveloppe SMTP, ce qui fait perdre l'information SPF d'origine côté destinataire. SPF ne se présente alors plus aligné avec le domaine du From, et c'est DKIM qui devient le pilier de l'alignement DMARC derrière Barracuda. D'où l'importance d'activer correctement la signature DKIM en console EGD avant de durcir la politique : sans elle, des messages pourtant légitimes échoueront à DMARC.

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 recommandé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;

Sur les plans supérieurs (Premium Plus), Barracuda fournit un module de Domain Fraud Protection qui agrège et visualise les rapports DMARC, identifie les sources d'envoi légitimes non encore authentifiées et accompagne la montée vers p=reject. Si vous restez sur EGD seul, vous pilotez DMARC avec un outil tiers. Validez chaque évolution de votre enregistrement avec le vérificateur de syntaxe DMARC CaptainDNS.

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

Pour savoir si un domaine utilise Barracuda Email Gateway Defense, examinez ses enregistrements MX et SPF : un MX se terminant par .ess.barracudanetworks.com ou un SPF contenant include:spf.ess[.<region>].barracudanetworks.com est la signature non ambiguë du service cloud.

Cette détection est utile dans plusieurs cas : auditer un prospect avant un rendez-vous commercial, qualifier la stack d'un partenaire, ou simplement comprendre par quoi transitent vos propres emails. La méthode repose sur deux signatures DNS.

Signature MX. Tout enregistrement MX dont le hostname se termine par .ess.barracudanetworks.com indique un domaine derrière Barracuda EGD. Le préfixe (d9307303a dans nos exemples) est l'identifiant unique du compte client.

# Détecter Barracuda via le MX
dig MX captaindns.com +short
# Une réponse du type "10 d9307303a.ess.barracudanetworks.com." = Barracuda EGD

Signature SPF. La présence d'un include:spf.ess.barracudanetworks.com (ou de sa variante régionale spf.ess.de/uk/ca/au/in.barracudanetworks.com) dans l'enregistrement TXT du domaine confirme que Barracuda relaie le mail sortant.

# Détecter Barracuda via le SPF
dig TXT captaindns.com +short | grep spf
# Présence de "include:spf.ess.barracudanetworks.com" = Barracuda en sortie

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 autres enregistrements en un coup d'œil. Croiser MX et SPF lève toute ambiguïté : un MX en .ess.barracudanetworks.com couplé à l'include SPF correspondant identifie sans erreur un domaine intégralement protégé par Barracuda EGD, entrant et sortant.

🔄 Comparatif face à Mimecast, Proofpoint et Microsoft

Barracuda se distingue par son positionnement SMB et MSP, là où Proofpoint et Mimecast visent l'enterprise et l'ETI. Le tableau ci-dessous compare les critères qui pèsent réellement dans un choix.

Critère	Barracuda EGD	Mimecast	Proofpoint	Microsoft Defender
Type	SEG cloud + Inbox Defense API	SEG + API (2026)	SEG enterprise + ICES	Natif M365
Cible	PME, mid-market, MSP	PME/ETI multi-besoins	Fortune 100, grandes ETI	Environnements M365
Détection IA/ML	Impersonation Protection, ML comportemental	Multi-vector + CyberGraph	Nexus AI 6 composants	9,1/10 tests indépendants
Modèle MSP multi-tenant	Oui (point fort)	Partiel	Limité	Via partenaires CSP
DMARC	Domain Fraud (Premium Plus)	DMARC Analyzer intégré	EFD avec consultants	Non
Archivage	Via Cloud Archiving (add-on)	Oui (1 jour à 99 ans)	Via partenaires	Via rétention M365
Format MX	<id>.ess.barracudanetworks.com	eu-smtp-inbound-1.mimecast.com	mx0a-XXXX.pphosted.com	*.mail.protection.outlook.com
Gartner 2025	Visionnaire	Leader	Leader (#1 Execution)	Leader
Idéal pour	SMB et MSP cherchant simplicité/prix	Centraliser sécurité + archivage	Threat intel d'élite	Full M365, budget serré

Mimecast et Proofpoint : la référence ETI et enterprise

Sur le mid-market et l'ETI, Mimecast propose une suite plus large côté fonctionnalités natives : archivage longue durée intégré, continuité email, DMARC Analyzer sans coût additionnel. Si votre besoin est de centraliser sécurité, archivage et continuité dans une seule console, Mimecast offre souvent un meilleur rapport fonctionnel que Barracuda, au prix d'une console plus complexe. Notre guide complet sur Mimecast détaille son architecture et sa configuration DNS.

Sur le très grand compte, Proofpoint domine par sa threat intelligence et son approche people-centric (concept VAP). C'est la référence pour les SOC matures des secteurs les plus ciblés (finance, défense, santé), mais à un coût et une complexité qui dépassent largement les besoins d'une PME. Voir notre guide complet sur Proofpoint.

Microsoft Defender et Abnormal : le natif et le comportemental

Si votre organisation est full Microsoft 365, Defender for Office 365 reste le choix le plus évident en ratio prix/couverture : protection native sans changement de MX, souvent moins de 2 euros par utilisateur et par mois, voire inclus en licence E5. Les tests indépendants lui attribuent un score de détection élevé. Pour une PME M365 aux besoins standards, c'est un point d'entrée difficile à battre. Barracuda garde l'avantage sur l'indépendance vis-à-vis du fournisseur email (utile en environnement hybride ou Google Workspace) et sur le modèle MSP.

Côté détection comportementale pure, Abnormal Security fonctionne exclusivement par API et excelle sur le BEC et le VEC (voir notre guide complet sur Abnormal Security). Beaucoup d'organisations l'utilisent en complément d'un SEG plutôt qu'en remplacement.

Le verdict : pour qui Barracuda est-il le bon choix ?

La passerelle email Barracuda EGD est pertinente si vous êtes une PME ou une ETI qui cherche une protection email cloud simple à déployer et à opérer, sans équipe SOC dédiée, avec un bon rapport prix/couverture. C'est aussi le choix de prédilection des MSP grâce à sa console multi-tenant et à sa remédiation en masse. Barracuda n'est en revanche pas le candidat naturel si vous visez la threat intelligence d'élite d'un grand compte (Proofpoint), une suite archivage/continuité tout-en-un (Mimecast), ou si vous êtes full M365 avec des besoins basiques (Defender suffit).

🖥️ Migration et déploiement pas à pas

Le déploiement d'EGD se fait sans coupure grâce à la bascule par priorité MX : on teste en priorité 99, puis on bascule en priorité 10 et on supprime les anciens MX. La séquence ci-dessous détaille les cinq étapes.

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

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 : serveur principal, marketing (Mailchimp, HubSpot), transactionnel (SendGrid, Mailgun), CRM (Salesforce), ticketing (Zendesk), produits internes. Chacune devra être authentifiée dans votre nouvelle configuration SPF et prise en compte dans la roadmap DMARC.

2. Dans la console EGD de votre région (us., de., uk., ca., au. ou in.ess.barracudanetworks.com), ajoutez votre domaine et vérifiez-en la propriété. Récupérez votre identifiant de compte unique pour le MX (<id>.ess.barracudanetworks.com). Configurez la connexion vers votre serveur de destination (M365, Google Workspace, Exchange) et synchronisez l'annuaire utilisateur. Notez bien votre région : elle conditionne l'include SPF à utiliser.

3. Ajoutez le MX Barracuda avec une priorité 99 (la moins prioritaire). Vos MX existants conservent une priorité basse et continuent de recevoir le mail légitime. Envoyez des emails de test pour vérifier que le compte Barracuda accepte bien le trafic de votre domaine et que le routage vers votre serveur de destination fonctionne. Cette phase valide la configuration sans aucun risque de perte de message.

4. Une fois la configuration validée, passez le MX Barracuda en priorité basse (10) et supprimez tous les anciens MX. Effectuez la bascule en dehors des heures de pointe. Vérifiez avec dig MX captaindns.com +short qu'il ne subsiste que le MX Barracuda. Verrouillez ensuite votre connecteur Microsoft 365 ou Google Workspace pour n'accepter le trafic entrant que depuis les IP Barracuda, fermant la porte dérobée du MX résiduel.

5. Ajoutez l'include SPF régional Barracuda (pas une autre région), en restant sous les 10 lookups. Activez la signature DKIM 2048 bits en console et publiez la clé publique dans le DNS. 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.

Le cas particulier de la migration depuis l'appliance ESG

Si vous exploitez encore l'appliance Email Security Gateway (ESG), Barracuda pousse la migration vers le service cloud EGD via son programme « ESG Elevate ». La logique est claire : l'appliance legacy ne reçoit plus les mêmes investissements, impose de gérer le matériel et les correctifs vous-même, et l'incident de 2023 a rappelé le coût d'une vulnérabilité sur un produit que le client doit patcher lui-même.

La migration ESG vers EGD revient à passer d'un filtrage on-premise à un filtrage cloud. Concrètement : vous provisionnez EGD dans la console, vous reportez vos politiques de filtrage (Barracuda fournit des assistants pour cela), vous testez en priorité 99 comme décrit plus haut, puis vous basculez les MX de l'appliance vers <id>.ess.barracudanetworks.com. Pour limiter le travail manuel, le programme propose un outil de conversion qui migre automatiquement les paramètres, domaines et utilisateurs de l'ESG vers EGD via un compte Barracuda Cloud Control, Barracuda annonçant une bascule « en moins d'une heure ». Le bénéfice principal : vous n'avez plus d'appliance à maintenir ni de patch critique à appliquer en urgence. C'est précisément le scénario d'incident que la section suivante détaille.

⚠️ Limites, inconvénients et la vulnérabilité de 2023

Les principales limites d'EGD sont une threat intelligence en deçà des Leaders Gartner, une suite moins complète en natif et six régions seulement. La CVE-2023-2868 de 2023, elle, visait l'appliance ESG et non le service cloud. On passe d'abord en revue les limites factuelles d'EGD, puis la CVE.

Les limites du service cloud

• Threat intelligence en deçà des Leaders. Sur la détection des attaques BEC et APT les plus sophistiquées, Barracuda reste derrière Proofpoint et Mimecast selon les analystes. Son positionnement de Visionnaire au Gartner 2025 reflète une vision produit reconnue mais une exécution jugée inférieure aux Leaders. Pour un secteur ultra-ciblé (finance, défense), ce n'est pas le premier choix.

• Suite moins complète en natif. L'archivage (Cloud Archiving), la sensibilisation et certaines protections avancées sont des modules ou des plans supérieurs (Premium, Premium Plus). Le prix d'entrée d'EGD est attractif, mais une posture complète impose de cumuler les briques, et le coût total grimpe. Comparez le périmètre exact de chaque plan avant de signer.

• Couverture régionale plus restreinte. Six régions (US, DE, UK, CA, AU, IN), c'est moins fin que certains concurrents. Vérifiez que votre exigence de résidence des données correspond à une région disponible, en particulier pour des contraintes de souveraineté strictes.

• Réécriture d'URL et faux positifs. Comme tout SEG, Barracuda peut réécrire des liens via Link Protection : les URL pointent alors vers une adresse de redirection Barracuda. Bonne nouvelle pour les craintes habituelles sur les magic links, les URL réécrites n'expirent pas, et Barracuda ne réécrit pas les domaines courants (google.com, microsoft.com, teams.microsoft.com) justement pour limiter les faux positifs. Le risque sur les liens à usage unique (réinitialisation de mot de passe) est donc plus mesuré qu'on ne le craint. La vigilance porte plutôt sur la quarantaine, à surveiller les premières semaines : des expéditeurs pourtant placés en liste d'autorisation s'y retrouvent parfois bloqués, et les retours utilisateurs (G2) signalent un réglage manuel à prévoir au démarrage.

La CVE-2023-2868 visait l'appliance, pas le cloud

La CVE-2023-2868 est l'incident de sécurité le plus marquant de l'histoire de Barracuda. Une précision s'impose d'emblée : cette vulnérabilité visait l'appliance Email Security Gateway (ESG), pas le service cloud Email Gateway Defense (EGD) dont parle cet article. Si vous évaluez ou utilisez EGD, vous n'étiez pas exposé. Reprenons les faits dans l'ordre, sans dramatiser.

La vulnérabilité était une injection de commande via le module de parsing des fichiers .tar reçus en pièce jointe, dans le code Perl de l'appliance ESG. Son score CVSS était de 9,8 (critique), le quasi-maximum. Concrètement, un attaquant pouvait envoyer un email avec une pièce jointe .tar spécialement formée pour exécuter du code arbitraire sur l'appliance.

La chronologie est instructive. L'exploitation in-the-wild a commencé dès octobre 2022, soit plusieurs mois avant toute détection. Mandiant (Google Cloud Threat Intelligence) a attribué la campagne à UNC4841, un acteur suspecté d'être lié à la Chine (China-nexus). Barracuda a détecté un trafic anormal le 18 mai 2023, déployé un patch mondial le 20 mai 2023 et publié la divulgation le 23 mai 2023.

Le point qui a marqué les esprits est la recommandation de remplacement physique. Barracuda l'a formulée initialement le 31 mai 2023, puis réitérée le 6 juin 2023 : remplacement immédiat de toutes les appliances ESG compromises, quel que soit le niveau de patch appliqué. La raison : les attaquants avaient déployé des portes dérobées persistantes (les malwares SEASPY, SUBMARINE et SALTWATER, entre autres) qui survivaient aux correctifs. Le FBI a relayé cette recommandation de remplacement matériel. C'est un cas rare où un éditeur conseille de jeter le matériel plutôt que de le patcher, ce qui en dit long sur la profondeur de la compromission. Barracuda n'a d'ailleurs jamais publié de nombre exact d'organisations touchées, évoquant seulement un « nombre limité » parmi les centaines de milliers d'appliances déployées.

Pour une décision en 2026, l'incident dit surtout une chose : le risque structurel des appliances que le client doit patcher lui-même. Un cloud géré comme EGD transfère cette responsabilité à l'éditeur. Le reste suit. EGD n'était pas concerné par cette CVE, et écarter le produit cloud sur la foi de l'incident ESG reste une erreur d'analyse fréquente. C'est d'ailleurs l'argument que Barracuda met en avant pour pousser la migration ESG vers EGD : éliminer la surface d'attaque de l'appliance on-premise.

📋 Plan d'action recommandé

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

1. Auditer votre posture email actuelle (MX, SPF, DKIM, DMARC) avec les outils CaptainDNS
2. Clarifier le besoin produit : confirmez que vous évaluez EGD (cloud) et non l'appliance ESG, et choisissez le plan (Advanced, Premium, Premium Plus) selon vos besoins en DMARC, sensibilisation et sauvegarde
3. Comparer avec Mimecast, Proofpoint et Microsoft Defender selon votre taille, votre budget et votre modèle (interne ou MSP)
4. Demander un POC et identifier votre région EGD (US, DE, UK, CA, AU, IN) qui conditionne l'include SPF
5. Configurer la console régionale, ajouter le domaine, récupérer l'identifiant MX et synchroniser l'annuaire
6. Tester en priorité 99 : valider le routage sans risque de perte de message
7. Basculer les MX en priorité basse hors heures de pointe et supprimer tous les anciens MX
8. Verrouiller le connecteur M365/Google Workspace pour n'accepter que les IP Barracuda
9. Mettre en place SPF (include régional, -all), DKIM (2048 bits) et DMARC (p=none puis durcissement)
10. Surveiller la quarantaine, les rapports DMARC et 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 :

• Mimecast Secure Email Gateway : architecture, configuration DNS, comparatif et plan d'action
• Proofpoint Secure Email Gateway : Nexus AI, TAP, EchoSpoofing 2024 et configuration DNS
• Abnormal Security : IA comportementale, déploiement API, Attune 1.0

FAQ

Qu'est-ce que Barracuda Email Gateway Defense ?

Barracuda Email Gateway Defense (EGD) est un Secure Email Gateway cloud qui filtre 100 % du trafic email entrant avant qu'il n'atteigne votre serveur de messagerie. Vous redirigez vos enregistrements MX vers l'infrastructure Barracuda (<id>.ess.barracudanetworks.com), qui inspecte chaque message (réputation, anti-spam, anti-malware, Advanced Threat Protection, anti-phishing) puis transfère le trafic propre vers Microsoft 365, Google Workspace ou Exchange. C'est l'ancien Barracuda Email Security Service (BESS), historiquement orienté PME et MSP, avec plus de 200 000 clients dans le monde.

Quelle est la différence entre Email Gateway Defense et Email Security Gateway ?

Ce sont deux produits distincts. Email Gateway Defense (EGD) est le service SEG cloud, hébergé entièrement chez Barracuda sous ess.barracudanetworks.com, sans matériel à gérer. Email Security Gateway (ESG) est une appliance physique ou virtuelle legacy, déployée on-premise ou dans le cloud du client, que l'organisation administre et patche elle-même. C'est l'appliance ESG, et non le service cloud EGD, qui a été visée par la CVE-2023-2868 en 2023. Barracuda pousse activement la migration des clients ESG vers EGD via son programme ESG Elevate.

Quels sont les enregistrements MX de Barracuda ?

Les MX de Barracuda Email Gateway Defense suivent le format <identifiant-client>.ess.barracudanetworks.com, par exemple d9307303a.ess.barracudanetworks.com. L'identifiant est unique à votre compte et visible sur la page de vérification de domaine de la console EGD. Lors du déploiement, Barracuda recommande d'ajouter ce MX en priorité 99 pour la phase de test (le mail légitime reste sur l'ancien serveur), puis de le passer en priorité basse (10) et de supprimer les anciens MX une fois la configuration validée.

Quel SPF include utiliser avec Barracuda ?

L'include SPF dépend de votre région. Aux États-Unis : include:spf.ess.barracudanetworks.com. En Allemagne/Europe : include:spf.ess.de.barracudanetworks.com. Au Royaume-Uni : include:spf.ess.uk.barracudanetworks.com. Au Canada : include:spf.ess.ca.barracudanetworks.com. En Australie : include:spf.ess.au.barracudanetworks.com. En Inde : include:spf.ess.in.barracudanetworks.com. Barracuda recommande de terminer l'enregistrement par -all. Surveillez le nombre total de lookups DNS pour rester sous la limite de 10 imposée par la RFC 7208.

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

Deux signatures DNS l'identifient. Côté entrant : un enregistrement MX se terminant par .ess.barracudanetworks.com (dig MX domaine.com +short). Côté sortant : la présence d'un include:spf.ess[.<region>].barracudanetworks.com dans l'enregistrement TXT du domaine (dig TXT domaine.com +short). Croiser les deux lève toute ambiguïté. Vous pouvez aussi utiliser l'outil DNS Lookup de CaptainDNS pour afficher ces enregistrements de façon lisible sans manipuler dig.

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

Oui. Barracuda Email Gateway Defense est indépendant du fournisseur de messagerie. En mode gateway, vous redirigez les MX vers Barracuda quel que soit votre serveur de destination (Microsoft 365, Google Workspace, Exchange on-premise), puis vous configurez la connexion sortante dans la console EGD. Côté Microsoft 365, l'intégration repose concrètement sur trois connecteurs (deux entrants, un sortant) plus une politique « allow spoofing » pour le trafic provenant de Barracuda ; le verrouillage anti-contournement passe par un connecteur partner entrant qui n'accepte que les IP Barracuda. Pour Microsoft 365, les plans supérieurs ajoutent une couche de défense de la boîte de réception par API et un module Incident Response pour retirer les messages malveillants déjà livrés.

La CVE-2023-2868 affecte-t-elle Email Gateway Defense (cloud) ?

Non. La CVE-2023-2868 (injection de commande via parsing de fichiers .tar, CVSS 9.8) visait exclusivement l'appliance Email Security Gateway (ESG), pas le service cloud Email Gateway Defense (EGD). Si vous utilisez EGD, vous n'étiez pas exposé à cette faille. L'incident, exploité dès octobre 2022 par l'acteur UNC4841 (attribution Mandiant, China-nexus), a conduit Barracuda à recommander le remplacement physique des appliances ESG compromises le 6 juin 2023, en raison de portes dérobées persistantes survivant aux correctifs. C'est l'un des arguments avancés pour migrer de l'appliance ESG vers le cloud EGD.

Barracuda est-il adapté aux PME et MSP ?

Oui, c'est même son positionnement de prédilection. Barracuda EGD est conçu pour être simple à déployer et à opérer sans équipe SOC dédiée, avec un rapport prix/couverture attractif pour les PME et le mid-market. Pour les MSP, l'architecture multi-tenant permet de provisionner, configurer et superviser la sécurité email de dizaines de clients depuis une console centrale, avec de la remédiation en masse et une facturation à l'usage. C'est l'un des programmes MSP les plus aboutis du marché, là où des solutions enterprise restent lourdes à opérer en mode multi-clients.

Comment migrer de l'appliance ESG vers Email Gateway Defense ?

La migration consiste à passer d'un filtrage on-premise à un filtrage cloud, via le programme Barracuda « ESG Elevate ». Vous provisionnez EGD dans la console régionale, vous reportez vos politiques de filtrage (Barracuda fournit des assistants), vous testez en priorité 99 sans risque de perte de message, puis vous basculez les MX de l'appliance vers <id>.ess.barracudanetworks.com en priorité basse, en supprimant les anciens MX. Le bénéfice principal : plus d'appliance à maintenir ni de patch critique à appliquer en urgence, ce qui élimine la surface d'attaque qui avait été exploitée par la CVE-2023-2868.

Barracuda gère-t-il DMARC et DKIM ?

Oui. La signature DKIM se configure dans la console EGD : vous choisissez un sélecteur, Barracuda génère la paire de clés, et vous publiez la clé publique en TXT à selecteur._domainkey.captaindns.com (préférez 2048 bits). Pour DMARC, EGD s'appuie sur votre alignement SPF/DKIM, et vous pilotez la politique de p=none vers p=reject. Sur le plan Premium Plus, le module Domain Fraud Protection agrège et visualise les rapports DMARC et accompagne la montée en politique stricte. Sur EGD seul, vous pouvez piloter DMARC avec un outil tiers tout en validant la syntaxe avec le vérificateur DMARC CaptainDNS.

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 sortant entre Internet et le serveur de messagerie, analysant chaque message (spam, malware, hameçonnage) avant de le transmettre au destinataire.

• EGD (Email Gateway Defense) : le Secure Email Gateway cloud de Barracuda, hébergé sous ess.barracudanetworks.com. Anciennement Barracuda Email Security Service (BESS). Sujet de cet article.

• ESG (Email Security Gateway) : l'appliance Barracuda legacy (physique ou virtuelle), administrée et patchée par le client. À ne pas confondre avec EGD. C'est la gamme visée par la CVE-2023-2868.

• BESS (Barracuda Email Security Service) : ancien nom du service cloud aujourd'hui appelé Email Gateway Defense.

• MX (Mail Exchanger) : enregistrement DNS qui indique les serveurs responsables de la réception des emails d'un domaine. Déployer Barracuda EGD implique de rediriger les MX vers <id>.ess.barracudanetworks.com.

• 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). Barracuda utilise un include régional (spf.ess[.<region>].barracudanetworks.com).

• DKIM (DomainKeys Identified Mail) : protocole qui signe cryptographiquement les emails. La clé publique est publiée dans le DNS, permettant au destinataire de vérifier l'intégrité et l'origine du message.

• 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).

• ATP (Advanced Threat Protection) : module Barracuda qui analyse les pièces jointes et charges utiles inconnues dans une sandbox pour détecter les menaces zero-day par observation comportementale.

• Impersonation Protection : moteur Barracuda de détection des attaques par usurpation (BEC), basé sur l'apprentissage des schémas de communication normaux de l'organisation pour repérer les anomalies.

• Incident Response : module Barracuda permettant de retirer automatiquement les emails malveillants déjà livrés dans les boîtes de réception, avec remédiation en masse, particulièrement utile pour les MSP.

• 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.

• MSP (Managed Service Provider) : prestataire qui gère l'infrastructure IT de plusieurs clients. L'architecture multi-tenant de Barracuda est pensée pour ce modèle.

• CVE-2023-2868 : vulnérabilité critique (CVSS 9.8) d'injection de commande via le parsing de fichiers .tar dans l'appliance ESG, exploitée par UNC4841. N'affecte pas le service cloud EGD.

• UNC4841 : acteur de menace suspecté d'être lié à la Chine (China-nexus), à qui Mandiant attribue l'exploitation de la CVE-2023-2868 sur les appliances ESG dès octobre 2022.

Sources

• Barracuda Campus : Email Gateway Defense, vérification de domaine et MX
• Barracuda Campus : Sender Policy Framework pour le mail sortant (includes régionaux)
• Barracuda Campus : Understanding Link Protection
• Barracuda Campus : intégration Microsoft 365 (connecteurs)
• Barracuda : 2025 Email Threats Report
• Barracuda Trust Center : ESG Appliance Vulnerability (CVE-2023-2868)
• Gartner Peer Insights : Email Security Platforms, avis Barracuda
• Mandiant / Google Cloud : exploitation mondiale de l'ESG par UNC4841
• Gartner Magic Quadrant for Email Security 2025