Barracuda Email Gateway Defense: arquitetura, configuração DNS e alternativas

⚡TL;DR

• 🛡️ Barracuda Email Gateway Defense (EGD) é o SEG cloud historicamente orientado a PMEs e MSPs, com mais de 200 mil clientes no mundo. Ele se posiciona à frente do Microsoft 365, do Google Workspace ou do Exchange via redirecionamento MX e filtra 100 % do tráfego entrante.
• 🔧 Impacto DNS específico: MX no formato <identificador-cliente>.ess.barracudanetworks.com (prioridade 99 para a fase de teste, depois a mudança), SPF include regional (spf.ess.barracudanetworks.com nos EUA, variantes DE/UK/CA/AU/IN), DKIM assinado no console e DMARC a ser gerenciado até p=reject.
• ⚠️ Distinção de produto crucial: a CVE-2023-2868 (CVSS 9.8, explorada pelo UNC4841) visava o appliance ESG legacy, não o serviço cloud EGD. Não confunda as duas linhas: o Barracuda recomenda a migração de ESG para EGD.
• 📊 Posicionamento: Visionário no Magic Quadrant Gartner Email Security pelo 2º ano consecutivo (1º de dezembro de 2025), a distinguir dos atores posicionados como Líderes no quadrante de 2025. Adquirido pela KKR em 2022 (~US$ 4 bilhões) após a Thoma Bravo. Alvo: SMB, mid-market e MSP multi-tenant.

Se você é uma PME, um órgão público, um escritório ou um MSP que gerencia várias dezenas de clientes, há grandes chances de já ter cruzado com o Barracuda. O fabricante californiano reivindica mais de 200 mil clientes e se firmou como um dos fornecedores de segurança de email mais implantados no segmento fora das grandes contas. Onde o Proofpoint domina a Fortune 100 e o Mimecast as empresas de médio porte multinecessidades, o Barracuda aposta em outra coisa: cloud simples de implantar, um programa MSP sólido e uma tabela de preços pensada para organizações que não têm uma equipe SOC dedicada.

Mas o nome "Barracuda" cobre na realidade dois produtos muito diferentes que são confundidos constantemente. De um lado, o Email Gateway Defense (EGD), o SEG cloud de que trata este artigo, hospedado em *.ess.barracudanetworks.com. Do outro, o Email Security Gateway (ESG), o appliance físico ou virtual legacy, aquele que ganhou as manchetes em 2023 com uma vulnerabilidade crítica explorada por um ator estatal. Essa confusão não é inofensiva: ela leva regularmente decisores a descartar o Barracuda com base em um incidente que não dizia respeito ao produto cloud que eles consideravam.

A questão não tem nada de teórico. O 2025 Email Threats Report do Barracuda, construído sobre quase 670 milhões de emails analisados, calcula em 24 % a parcela das mensagens maliciosas ou indesejadas, aponta que um QR code de phishing se esconde em 68 % dos PDFs armadilhados e em 83 % dos documentos Office infectados, e constata que 47 % dos domínios de email ainda não configuraram o DMARC. Filtrar o fluxo entrante não serve de nada se o seu domínio continuar usurpável por falta de autenticação: verifique primeiro onde você está com o verificador de sintaxe DMARC CaptainDNS.

Na CaptainDNS, analisamos o Barracuda sob o ângulo que nos interessa: o impacto nos seus registros DNS e na sua autenticação de email. Implantar o EGD não é apenas cumprir um item de checklist de segurança. É redirecionar seus MX para ess.barracudanetworks.com, ajustar seu SPF com o include regional correto, publicar sua chave DKIM e gerenciar seu DMARC. Este guia cobre tudo: arquitetura, configuração DNS detalhada com os valores reais, método de detecção de um domínio por trás do Barracuda, distinção EGD/ESG, tratamento factual da CVE-2023-2868, comparativo e plano de ação.

📌 O que é o gateway de email cloud do Barracuda?

Barracuda Email Gateway Defense é um Secure Email Gateway cloud que filtra 100 % do tráfego de email entrante antes que ele alcance seu servidor de mensagens. Você redireciona seus registros MX para a infraestrutura Barracuda, que inspeciona cada mensagem e depois transfere apenas o tráfego limpo para o Microsoft 365, o Google Workspace ou o Exchange.

Para os fundamentos de um SEG (modelo gateway, redirecionamento MX, distinção com as soluções ICES API-native), remetemos ao nosso artigo completo sobre o Mimecast, que apresenta esses fundamentos em detalhe. O que você precisa lembrar: um SEG se posiciona entre a Internet e seu servidor de mensagens, vê a totalidade do fluxo entrante e bloqueia as ameaças em pré-entrega, em vez de remediar depois que o estrago já foi feito.

Onde o Barracuda exige vigilância é na nomenclatura de produto. Três nomes voltam o tempo todo na documentação, e misturá-los leva a erros de configuração caros.

Email Gateway Defense (EGD) é o serviço SEG cloud, antigamente comercializado sob os nomes Barracuda Email Security Service (BESS) ou "Email Security Essentials". É o assunto deste artigo. Tudo é hospedado na Barracuda, sob o domínio ess.barracudanetworks.com. Nenhum appliance para gerenciar, nenhum patch para aplicar do lado do cliente. O serviço vive em datacenters regionais operados pela Barracuda.

Email Security Gateway (ESG) é uma linha totalmente diferente: um appliance físico (hardware rackável) ou virtual, implantado on-premise ou na cloud do cliente, que a organização administra ela mesma. É um produto legacy, em fim de ciclo comercial, e é essa linha que sofreu a CVE-2023-2868. O Barracuda promove ativamente a migração dos clientes ESG para EGD via seu programa "ESG Elevate".

Barracuda Email Protection é a suíte abrangente. Ela se divide em três planos: Advanced, Premium e Premium Plus. O EGD constitui o bloco de base. Os planos superiores adicionam módulos como a proteção contra a fraude ao domínio (DMARC avançado), Impersonation Protection, a conscientização de usuários (Security Awareness Training), o Zero Trust Access e o backup Cloud-to-Cloud Backup.

🏢 Barracuda: a empresa em resumo

Um fabricante de appliances anti-spam dos anos 2000 que virou ator cloud com 200 mil clientes sob a bandeira da KKR: o caminho cabe em vinte anos de pivôs e duas aquisições por fundos de private equity.

A Barracuda Networks foi fundada em 2003 em Campbell, na Califórnia. A empresa se tornou conhecida primeiro pelo seu Spam Firewall, um appliance de hardware que democratizava a filtragem anti-spam para as PMEs numa época em que as soluções concorrentes eram caras e complexas. Esse modelo "appliance simples, preço acessível" estruturou o DNA do fabricante durante uma década: hardware fácil de implantar para organizações sem uma grande equipe de TI.

A virada cloud chega progressivamente nos anos 2010 com o lançamento do Barracuda Email Security Service, ancestral direto do atual Email Gateway Defense. Em vez de vender uma caixa para conectar no rack, o Barracuda hospeda a filtragem em seus próprios datacenters. O cliente simplesmente redireciona seus MX. Esse pivô acompanha a virada geral do mercado em direção ao Microsoft 365 e ao Google Workspace, onde o appliance on-premise não faz mais sentido.

No plano societário, o Barracuda passou por duas operações maiores. A Thoma Bravo compra a empresa em 2017 por cerca de 1,6 bilhão de dólares, retirando-a da bolsa. Depois, em 2022, a KKR adquire o Barracuda da Thoma Bravo por uma avaliação de cerca de 4 bilhões de dólares, ou seja, mais do que o dobro em cinco anos. Essa passagem para a KKR acompanhou o reposicionamento do Barracuda como plataforma de cibersegurança orientada a mid-market e MSP, além do email puro.

Hoje, o Barracuda reivindica mais de 200 mil clientes no mundo, com uma concentração forte nas PMEs, nas empresas de médio porte e num ecossistema MSP particularmente desenvolvido. O programa de parceiros MSP permite a um prestador gerenciar a segurança de email de dezenas de clientes a partir de um console multi-tenant, com remediação em massa e cobrança por uso. É um dos argumentos mais diferenciadores do Barracuda frente a concorrentes historicamente pensados para o cliente final único.

Do lado dos analistas, o Barracuda figura como Visionário no Magic Quadrant Gartner Email Security pelo 2º ano consecutivo (edição de 1º de dezembro de 2025). A nuance importa: um Visionário tem uma visão de produto reconhecida, mas uma capacidade de execução julgada abaixo dos atores posicionados como Líderes nesse mesmo quadrante (Proofpoint, Mimecast e Microsoft notadamente). O Barracuda, portanto, não joga no mesmo campeonato que o Proofpoint na threat intelligence de elite. Do lado do feedback de clientes, ele ainda assim conquista 4,6/5 em 439 avaliações Gartner Peer Insights para o mercado Email Security Platforms. Na relação simplicidade/preço/cobertura, ele mantém uma posição sólida para o segmento que mira.

⚙️ Arquitetura técnica: como o Barracuda filtra seus emails

Antes de alcançar seu servidor, cada mensagem passa por uma cadeia de pré-filtragem hospedada nos datacenters regionais do Barracuda. A isso se somam módulos de análise avançada e, nos planos superiores, uma camada de detecção comportamental por API. Vamos detalhar tudo.

Modelo gateway: o redirecionamento MX para ess.barracudanetworks.com

Como todo SEG tradicional, o EGD se baseia no redirecionamento MX. Seus registros MX apontam para a infraestrutura cloud Barracuda, hospedada sob ess.barracudanetworks.com. Quando um remetente envia um email para contact@captaindns.com, o servidor dele resolve o MX, encontra um host Barracuda, e entrega a mensagem lá. O Barracuda aplica sua cadeia de detecção e depois transfere a mensagem validada para seu servidor real.

O fluxo se desenrola em cinco tempos:

1. Um remetente envia um email para contact@captaindns.com
2. O servidor dele efetua uma consulta DNS MX para captaindns.com
3. O DNS retorna o MX Barracuda (por exemplo d9307303a.ess.barracudanetworks.com)
4. A mensagem chega à Barracuda, que a submete à sua cadeia de inspeção (reputação, anti-spam, anti-malware, ATP, anti-phishing)
5. Se a mensagem for aprovada, o Barracuda a transfere para seu servidor de email real (Microsoft 365, Google Workspace, Exchange on-premise)

A vantagem é direta: o Barracuda vê 100 % do tráfego entrante e bloqueia as ameaças antes que elas toquem sua infraestrutura. Seu servidor só recebe tráfego já filtrado.

A pré-filtragem cloud: reputação, anti-spam, anti-malware

A primeira linha de defesa do Barracuda é um estágio de pré-filtragem que elimina o ruído de fundo antes de qualquer análise custosa. O serviço pontua a reputação do IP de origem no momento da conexão SMTP, apoiando-se nos fluxos de reputação mantidos pela Barracuda (o fabricante opera, aliás, sua própria Barracuda Reputation Block List, uma blacklist histórica usada bem além dos seus próprios produtos). As conexões vindas de botnets conhecidos ou de IPs massivamente sinalizados são rejeitadas logo no handshake, sem nem mesmo analisar o conteúdo.

Vem em seguida a análise anti-spam e anti-malware clássica: assinaturas, heurísticas, scan antivírus multimotor. Essa camada trata o volume rapidamente e elimina as ameaças conhecidas. É eficaz no spam em massa e nos malwares catalogados, mas insuficiente para as ameaças direcionadas e os anexos desconhecidos, daí os estágios seguintes.

A sandbox ATP contra as ameaças zero-day

O Advanced Threat Protection (ATP) do Barracuda trata os anexos e as cargas úteis que as assinaturas não reconhecem. Os arquivos suspeitos são redirecionados para um ambiente de sandbox onde são executados e observados: tentativas de conexão de saída, modificação de arquivos de sistema, comportamento de criptografia, injeção de código. É a resposta às ameaças zero-day, para as quais nenhuma assinatura existe ainda.

O ATP combina análise estática (inspeção da estrutura do arquivo, das macros, dos scripts integrados) e análise dinâmica (detonação na sandbox). O veredicto alimenta em seguida as decisões de bloqueio. Nos planos superiores, ele também dispara ações de remediação automatizadas.

A proteção anti-usurpação por IA comportamental

A proteção contra a usurpação é um dos argumentos fortes do Barracuda no segmento PME, particularmente exposto aos ataques de Business Email Compromise (BEC) por falta de meios de detecção internos. O módulo Impersonation Protection (historicamente vindo do bloco "Sentinel") aplica uma análise comportamental por aprendizado de máquina para detectar a fraude.

O motor aprende os padrões de comunicação normais da organização: quem escreve para quem, a partir de quais endereços, com qual tom, em quais horários. Ele sinaliza em seguida as anomalias típicas de um ataque BEC: um email supostamente enviado pelo dirigente a partir de um endereço externo, um pedido de transferência incomum, um nome exibido que imita um colaborador, um domínio parecido (typosquatting). O problema é que esses ataques muitas vezes não contêm nem link nem anexo. Nenhuma assinatura pega neles. A detecção comportamental continua sendo o único meio de pegá-los.

A defesa por API e a remediação após a entrega

Além do gateway, os planos superiores adicionam uma camada de defesa da caixa de entrada por API no Microsoft 365. Essa abordagem complementa a filtragem em pré-entrega com uma análise pós-entrega das mensagens já chegadas, à maneira das soluções ICES. Ela explora o acesso aos metadados internos do tenant (relações entre usuários, histórico de comunicação) para refinar a detecção comportamental.

O módulo Incident Response fecha o ciclo: quando uma ameaça é identificada após a entrega, o administrador (ou o MSP) pode remover automaticamente a mensagem das caixas de entrada afetadas, na escala de todos os usuários atingidos. Para um MSP que gerencia dezenas de tenants, a remediação em massa é um ganho operacional decisivo: neutralizar uma campanha em todo o parque com alguns cliques, em vez de tenant por tenant.

Datacenters regionais e arquitetura multi-tenant para MSP

O Barracuda opera o EGD a partir de várias regiões geográficas, cada uma com seu próprio console e seu próprio include SPF. Duas questões justificam esse recorte: a latência (tratar o email o mais próximo possível da organização) e a residência dos dados (um cliente europeu quer seus dados tratados na Europa, conformidade RGPD obriga). As regiões disponíveis hoje cobrem os Estados Unidos, a Alemanha (para a Europa), o Reino Unido, o Canadá, a Austrália e a Índia.

A arquitetura é nativamente multi-tenant, moldada para o modelo MSP. Um prestador dispõe de um console central a partir do qual provisiona, configura e supervisiona a segurança de email de todos os seus clientes. As políticas se herdam de um modelo comum e depois se refinam por tenant, e a cobrança segue o uso. É uma das razões da forte presença do Barracuda entre os MSPs, onde as soluções enterprise continuam pesadas de operar em modo multi-cliente.

🔧 A configuração DNS, etapa por etapa

Implantar o EGD modifica quatro registros DNS: MX, SPF, DKIM e DMARC. Um erro em um deles, e seus emails desaparecem ou contornam a filtragem. Aqui está cada etapa com os valores reais e as armadilhas a evitar.

O registro MX no formato ess.barracudanetworks.com

O registro MX do Barracuda EGD segue o formato <identificador-cliente>.ess.barracudanetworks.com. O identificador é um código único gerado pelo Barracuda para sua conta, visível na página de verificação de domínio do console (seção Domains). Por exemplo, uma conta pode receber um MX do tipo d9307303a.ess.barracudanetworks.com.

É uma diferença notável em relação ao Mimecast ou ao Proofpoint, cujos MX seguem uma nomenclatura regional genérica (eu-smtp-inbound-1.mimecast.com, mx0a-XXXXXXXX.pphosted.com). No Barracuda, o hostname MX é próprio da sua conta, o que constitui aliás uma assinatura de detecção conveniente (ver mais abaixo).

O Barracuda recomenda uma abordagem de mudança em dois tempos via prioridade MX. Durante a fase de teste, você adiciona o MX Barracuda com uma prioridade alta (99), ou seja, a menos prioritária. Seus MX existentes conservam sua prioridade baixa e continuam a receber o email legítimo. Isso permite validar que a conta Barracuda aceita bem o tráfego do seu domínio sem arriscar perder mensagens. Uma vez validada a configuração, você inverte: o MX Barracuda passa para prioridade baixa (10) e você remove os antigos MX.

# Verificar os MX atuais
dig MX captaindns.com +short

Resultado esperado uma vez concluída a mudança:

10 d9307303a.ess.barracudanetworks.com.

Armadilha clássica. Não deixe nenhum MX residual apontando para seu antigo servidor (Exchange on-premise, ou diretamente seu tenant *.mail.protection.outlook.com). Um MX residual é uma porta dos fundos: um atacante que conhece sua infraestrutura Microsoft 365 pode entregar diretamente nas suas caixas contornando o Barracuda. Após a mudança, verifique com dig MX que só resta o MX Barracuda, e bloqueie seu conector M365 para só aceitar os IPs Barracuda.

O SPF com o include regional

É aqui que a geografia conta. Para o email de saída retransmitido pelo Barracuda, você deve adicionar o include SPF correspondente à sua região. Usar o include de outra região não funcionará, pois os IPs de envio diferem.

Região	Include SPF	Console regional
Estados Unidos (US)	include:spf.ess.barracudanetworks.com	us.ess.barracudanetworks.com
Alemanha / Europa (DE)	include:spf.ess.de.barracudanetworks.com	de.ess.barracudanetworks.com
Reino Unido (UK)	include:spf.ess.uk.barracudanetworks.com	uk.ess.barracudanetworks.com
Canadá (CA)	include:spf.ess.ca.barracudanetworks.com	ca.ess.barracudanetworks.com
Austrália (AU)	include:spf.ess.au.barracudanetworks.com	au.ess.barracudanetworks.com
Índia (IN)	include:spf.ess.in.barracudanetworks.com	in.ess.barracudanetworks.com

Exemplo de registro SPF para um cliente US que também envia via Google Workspace:

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

O Barracuda recomenda o mecanismo -all (hardfail), mais estrito que o ~all (softfail). Com uma política DMARC em p=reject, o ~all basta já que o DMARC dita a rejeição, mas o -all adiciona uma proteção no nível do próprio SPF, o que é coerente com a postura padrão aconselhada pelo fabricante. Fique de olho, ainda assim, no número total de lookups DNS: a especificação SPF (RFC 7208) impõe um limite de 10 lookups recursivos. Some Barracuda, Google Workspace e dois ou três ESPs, e você chega rápido ao teto, acabando num PermError.

Verifique seu registro com o verificador de sintaxe SPF CaptainDNS, que conta os lookups e sinaliza os estouros.

A assinatura DKIM

O DKIM assina criptograficamente seus emails de saída, permitindo ao destinatário verificar que eles vêm mesmo do seu domínio e não foram alterados. Com o Barracuda EGD, a configuração se gerencia no console:

1. Ativar a assinatura DKIM para seu domínio no console EGD (seção Outbound / Sender Authentication), escolhendo um seletor
2. Recuperar a chave pública gerada pelo Barracuda e publicá-la no seu DNS sob a forma de um registro TXT no local seletor._domainkey.captaindns.com
3. Ativar a assinatura uma vez que o registro DNS esteja propagado e verificado pelo console

Verificação da publicação:

dig TXT barracuda._domainkey.captaindns.com +short

O resultado deve conter a chave pública no formato v=DKIM1; k=rsa; p=MIGfMA0GCS.... Lembre-se de escolher um comprimento de chave de 2048 bits em vez de 1024 para uma segurança conforme às boas práticas atuais, e planeje uma rotação a cada seis a doze meses.

O alinhamento DMARC

O DMARC verifica que o domínio visível no campo From está alinhado com o domínio autenticado por SPF ou DKIM, e define a política a aplicar em caso de falha. É a peça final da autenticação, e o Barracuda se apoia na sua configuração SPF/DKIM para produzir o alinhamento.

Um ponto frequentemente negligenciado em modo gateway: o relay de saída via Barracuda reescreve o envelope SMTP, o que faz perder a informação SPF de origem do lado do destinatário. O SPF deixa então de se apresentar alinhado com o domínio do From, e é o DKIM que se torna o pilar do alinhamento DMARC atrás do Barracuda. Daí a importância de ativar corretamente a assinatura DKIM no console EGD antes de endurecer a política: sem ela, mensagens mesmo legítimas falharão no DMARC.

A progressão recomendada é a mesma que para qualquer implantação:

1. p=none (monitoramento): você recebe os relatórios agregados sem afetar a entrega. Duração recomendada: 2 a 4 semanas.
2. p=quarantine: as mensagens não autenticadas vão para o spam. Duração: 2 a 4 semanas.
3. p=reject: as mensagens não autenticadas são rejeitadas. É a política alvo.

Exemplo de registro DMARC inicial:

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

Nos planos superiores (Premium Plus), o Barracuda fornece um módulo de Domain Fraud Protection que agrega e visualiza os relatórios DMARC, identifica as fontes de envio legítimas ainda não autenticadas e acompanha a subida até p=reject. Se você ficar apenas no EGD, você gerencia o DMARC com uma ferramenta de terceiros. Valide cada evolução do seu registro com o verificador de sintaxe DMARC CaptainDNS.

🔍 Como detectar que um domínio está protegido pelo Barracuda?

Para saber se um domínio usa o Barracuda Email Gateway Defense, examine seus registros MX e SPF: um MX terminado em .ess.barracudanetworks.com ou um SPF contendo include:spf.ess[.<region>].barracudanetworks.com é a assinatura inequívoca do serviço cloud.

Essa detecção é útil em vários casos: auditar um prospect antes de uma reunião comercial, qualificar a stack de um parceiro, ou simplesmente entender por onde transitam seus próprios emails. O método repousa sobre duas assinaturas DNS.

Assinatura MX. Todo registro MX cujo hostname termina em .ess.barracudanetworks.com indica um domínio por trás do Barracuda EGD. O prefixo (d9307303a nos nossos exemplos) é o identificador único da conta do cliente.

# Detectar Barracuda pelo MX
dig MX captaindns.com +short
# Uma resposta do tipo "10 d9307303a.ess.barracudanetworks.com." = Barracuda EGD

Assinatura SPF. A presença de um include:spf.ess.barracudanetworks.com (ou da sua variante regional spf.ess.de/uk/ca/au/in.barracudanetworks.com) no registro TXT do domínio confirma que o Barracuda retransmite o email de saída.

# Detectar Barracuda pelo SPF
dig TXT captaindns.com +short | grep spf
# Presença de "include:spf.ess.barracudanetworks.com" = Barracuda na saída

Para uma análise completa e legível dos registros de um domínio sem manipular o dig, use a ferramenta DNS Lookup da CaptainDNS, que exibe os MX, TXT e outros registros num piscar de olhos. Cruzar MX e SPF elimina toda ambiguidade: um MX em .ess.barracudanetworks.com acoplado ao include SPF correspondente identifica sem erro um domínio integralmente protegido pelo Barracuda EGD, na entrada e na saída.

🔄 Comparativo frente a Mimecast, Proofpoint e Microsoft

O Barracuda se distingue pelo seu posicionamento SMB e MSP, onde o Proofpoint e o Mimecast miram o enterprise e as empresas de médio porte. A tabela abaixo compara os critérios que realmente pesam numa escolha.

Critério	Barracuda EGD	Mimecast	Proofpoint	Microsoft Defender
Tipo	SEG cloud + Inbox Defense API	SEG + API (2026)	SEG enterprise + ICES	Nativo M365
Alvo	PME, mid-market, MSP	PME/médio porte multinecess.	Fortune 100, grandes empresas	Ambientes M365
Detecção IA/ML	Impersonation Protection, ML comportamental	Multi-vector + CyberGraph	Nexus AI 6 componentes	9,1/10 testes independentes
Modelo MSP multi-tenant	Sim (ponto forte)	Parcial	Limitado	Via parceiros CSP
DMARC	Domain Fraud (Premium Plus)	DMARC Analyzer integrado	EFD com consultores	Não
Arquivamento	Via Cloud Archiving (add-on)	Sim (1 dia a 99 anos)	Via parceiros	Via retenção M365
Formato MX	<id>.ess.barracudanetworks.com	eu-smtp-inbound-1.mimecast.com	mx0a-XXXX.pphosted.com	*.mail.protection.outlook.com
Gartner 2025	Visionário	Líder	Líder (#1 Execução)	Líder
Ideal para	SMB e MSP buscando simplicidade/preço	Centralizar segurança + arquivamento	Threat intel de elite	Full M365, orçamento apertado

Mimecast e Proofpoint: a referência médio porte e enterprise

No mid-market e nas empresas de médio porte, o Mimecast propõe uma suíte mais ampla do lado das funcionalidades nativas: arquivamento de longa duração integrado, continuidade de email, DMARC Analyzer sem custo adicional. Se sua necessidade é centralizar segurança, arquivamento e continuidade num único console, o Mimecast oferece frequentemente uma relação funcional melhor que o Barracuda, ao preço de um console mais complexo. Nosso guia completo sobre o Mimecast detalha sua arquitetura e sua configuração DNS.

Nas grandes contas, o Proofpoint domina pela sua threat intelligence e sua abordagem people-centric (conceito VAP). É a referência para os SOCs maduros dos setores mais visados (finanças, defesa, saúde), mas a um custo e uma complexidade que ultrapassam largamente as necessidades de uma PME. Veja nosso guia completo sobre o Proofpoint.

Microsoft Defender e Abnormal: o nativo e o comportamental

Se sua organização é full Microsoft 365, o Defender for Office 365 continua sendo a escolha mais evidente em relação preço/cobertura: proteção nativa sem mudança de MX, frequentemente menos de 2 euros por usuário por mês, ou até incluído na licença E5. Os testes independentes lhe atribuem um score de detecção elevado. Para uma PME M365 com necessidades padrão, é um ponto de entrada difícil de bater. O Barracuda mantém a vantagem na independência em relação ao provedor de email (útil em ambiente híbrido ou Google Workspace) e no modelo MSP.

Do lado da detecção comportamental pura, o Abnormal Security funciona exclusivamente por API e se destaca no BEC e no VEC (veja nosso guia completo sobre o Abnormal Security). Muitas organizações o usam em complemento de um SEG, em vez de em substituição.

O veredicto: para quem o Barracuda é a escolha certa?

O Barracuda EGD é pertinente se você é uma PME ou uma empresa de médio porte que busca uma proteção de email cloud simples de implantar e de operar, sem equipe SOC dedicada, com uma boa relação preço/cobertura. É também a escolha preferencial dos MSPs graças ao seu console multi-tenant e à sua remediação em massa. O Barracuda, em contrapartida, não é o candidato natural se você mira a threat intelligence de elite de uma grande conta (Proofpoint), uma suíte arquivamento/continuidade tudo-em-um (Mimecast), ou se você é full M365 com necessidades básicas (o Defender basta).

🖥️ Migração e implantação passo a passo

Uma vez escolhido o Barracuda Email Gateway Defense, resta implantá-lo sem interromper o serviço. A sequência abaixo se apoia na mudança por prioridade MX.

Guia de implantação em 5 etapas, do inventário DNS à mudança de MX

1. Documente o estado atual dos seus registros MX, SPF, DKIM e DMARC com as ferramentas CaptainDNS. Recenseie sobretudo todas as fontes de envio legítimas do seu domínio: servidor principal, marketing (Mailchimp, HubSpot), transacional (SendGrid, Mailgun), CRM (Salesforce), ticketing (Zendesk), produtos internos. Cada uma deverá ser autenticada na sua nova configuração SPF e levada em conta na roadmap DMARC.

2. No console EGD da sua região (us., de., uk., ca., au. ou in.ess.barracudanetworks.com), adicione seu domínio e verifique a propriedade. Recupere seu identificador de conta único para o MX (<id>.ess.barracudanetworks.com). Configure a conexão para seu servidor de destino (M365, Google Workspace, Exchange) e sincronize o diretório de usuários. Anote bem sua região: ela condiciona o include SPF a usar.

3. Adicione o MX Barracuda com uma prioridade 99 (a menos prioritária). Seus MX existentes conservam uma prioridade baixa e continuam a receber o email legítimo. Envie emails de teste para verificar que a conta Barracuda aceita bem o tráfego do seu domínio e que o roteamento para seu servidor de destino funciona. Essa fase valida a configuração sem nenhum risco de perda de mensagem.

4. Uma vez validada a configuração, passe o MX Barracuda para prioridade baixa (10) e remova todos os antigos MX. Efetue a mudança fora dos horários de pico. Verifique com dig MX captaindns.com +short que só subsiste o MX Barracuda. Bloqueie em seguida seu conector Microsoft 365 ou Google Workspace para só aceitar o tráfego entrante a partir dos IPs Barracuda, fechando a porta dos fundos do MX residual.

5. Adicione o include SPF regional Barracuda (não de outra região), permanecendo abaixo dos 10 lookups. Ative a assinatura DKIM 2048 bits no console e publique a chave pública no DNS. Implante o DMARC em p=none, monitore os relatórios por 2 a 4 semanas, depois suba para p=quarantine e p=reject. Valide cada registro com os verificadores CaptainDNS.

O caso particular da migração desde o appliance ESG

Se você ainda explora o appliance Email Security Gateway (ESG), o Barracuda promove a migração para o serviço cloud EGD via seu programa "ESG Elevate". A lógica é clara: o appliance legacy não recebe mais os mesmos investimentos, impõe gerenciar o hardware e as correções você mesmo, e o incidente de 2023 lembrou o custo de uma vulnerabilidade num produto que o cliente deve corrigir ele mesmo.

A migração ESG para EGD equivale a passar de uma filtragem on-premise para uma filtragem cloud. Concretamente: você provisiona o EGD no console, você transpõe suas políticas de filtragem (o Barracuda fornece assistentes para isso), você testa em prioridade 99 como descrito acima, depois muda os MX do appliance para <id>.ess.barracudanetworks.com. Para limitar o trabalho manual, o programa propõe uma ferramenta de conversão que migra automaticamente os parâmetros, domínios e usuários do ESG para o EGD por meio de uma conta Barracuda Cloud Control, com o Barracuda anunciando uma mudança "em menos de uma hora". O benefício principal: você não tem mais appliance para manter nem patch crítico para aplicar com urgência. É precisamente o cenário de incidente que a seção seguinte detalha.

⚠️ Limites, desvantagens e a vulnerabilidade de 2023

Nenhuma solução é perfeita, e o Barracuda carrega a reputação de um incidente sério. Só que esse incidente diz respeito a um produto preciso, que é preciso distinguir do serviço cloud. Vamos primeiro passar em revista os limites factuais do EGD, depois a CVE-2023-2868.

Os limites do serviço cloud

• Threat intelligence abaixo dos Líderes. Na detecção dos ataques BEC e APT mais sofisticados, o Barracuda fica atrás do Proofpoint e do Mimecast segundo os analistas. Seu posicionamento de Visionário no Gartner 2025 reflete uma visão de produto reconhecida mas uma execução julgada inferior aos Líderes. Para um setor ultra-visado (finanças, defesa), não é a primeira escolha.

• Suíte menos completa em nativo. O arquivamento (Cloud Archiving), a conscientização e certas proteções avançadas são módulos ou planos superiores (Premium, Premium Plus). O preço de entrada do EGD é atrativo, mas uma postura completa impõe acumular os blocos, e o custo total sobe. Compare o perímetro exato de cada plano antes de assinar.

• Cobertura regional mais restrita. Seis regiões (US, DE, UK, CA, AU, IN), é menos granular que certos concorrentes. Verifique que sua exigência de residência dos dados corresponde a uma região disponível, em particular para restrições de soberania estritas.

• Reescrita de URL e falsos positivos. Como todo SEG, o Barracuda pode reescrever links via Link Protection: as URLs apontam então para um endereço de redirecionamento Barracuda. Boa notícia para os receios habituais sobre os magic links, as URLs reescritas não expiram, e o Barracuda não reescreve os domínios comuns (google.com, microsoft.com, teams.microsoft.com) justamente para limitar os falsos positivos. O risco nos links de uso único (redefinição de senha) é, portanto, mais moderado do que se teme. A vigilância recai mais na quarentena, a monitorar nas primeiras semanas: remetentes mesmo colocados em lista de autorização às vezes acabam bloqueados ali, e os relatos de usuários (G2) sinalizam um ajuste manual a prever logo de início.

A CVE-2023-2868 visava o appliance, não o cloud

A CVE-2023-2868 é o incidente de segurança mais marcante da história do Barracuda. Uma precisão se impõe de imediato: essa vulnerabilidade visava o appliance Email Security Gateway (ESG), não o serviço cloud Email Gateway Defense (EGD) de que trata este artigo. Se você avalia ou usa o EGD, você não estava exposto. Vamos retomar os fatos em ordem, sem dramatizar.

A vulnerabilidade era uma injeção de comando via módulo de parsing dos arquivos .tar recebidos como anexo, no código Perl do appliance ESG. Seu score CVSS era de 9,8 (crítico), o quase máximo. Concretamente, um atacante podia enviar um email com um anexo .tar especialmente formado para executar código arbitrário no appliance.

A cronologia é instrutiva. A exploração in-the-wild começou já em outubro de 2022, ou seja, vários meses antes de qualquer detecção. A Mandiant (Google Cloud Threat Intelligence) atribuiu a campanha ao UNC4841, um ator suspeito de estar ligado à China (China-nexus). O Barracuda detectou um tráfego anormal em 18 de maio de 2023, implantou um patch mundial em 20 de maio de 2023 e publicou a divulgação em 23 de maio de 2023.

O ponto que marcou os espíritos é a recomendação de substituição física: o Barracuda a formulou inicialmente em 31 de maio de 2023, depois reiterada em 6 de junho de 2023, aconselhando a substituição imediata de todos os appliances ESG comprometidos, qualquer que fosse o nível de patch aplicado. A razão: os atacantes haviam implantado portas dos fundos persistentes (os malwares SEASPY, SUBMARINE e SALTWATER, entre outros) que sobreviviam às correções. O FBI repassou essa recomendação de substituição de hardware. É um caso raro em que um fabricante aconselha jogar fora o hardware em vez de corrigi-lo, o que diz muito sobre a profundidade do comprometimento. O Barracuda aliás nunca publicou um número exato de organizações atingidas, evocando apenas um "número limitado" entre as centenas de milhares de appliances implantados.

Para uma decisão em 2026, o incidente diz sobretudo uma coisa: o risco estrutural dos appliances que o cliente deve corrigir ele mesmo. Uma cloud gerenciada como o EGD transfere essa responsabilidade ao fabricante, e é isso que muda tudo. O EGD não foi afetado por essa CVE, e descartar o produto cloud com base no incidente ESG continua sendo um erro de análise frequente. É aliás o argumento que o Barracuda destaca para promover a migração de ESG para EGD: eliminar a superfície de ataque do appliance on-premise.

📋 Plano de ação recomendado

Da auditoria inicial à política DMARC estrita, aqui está a sequência completa para avaliar e depois implantar o Barracuda Email Gateway Defense.

1. Auditar sua postura de email atual (MX, SPF, DKIM, DMARC) com as ferramentas CaptainDNS
2. Esclarecer a necessidade de produto: confirme que você avalia o EGD (cloud) e não o appliance ESG, e escolha o plano (Advanced, Premium, Premium Plus) conforme suas necessidades em DMARC, conscientização e backup
3. Comparar com Mimecast, Proofpoint e Microsoft Defender conforme seu tamanho, seu orçamento e seu modelo (interno ou MSP)
4. Solicitar um POC e identificar sua região EGD (US, DE, UK, CA, AU, IN) que condiciona o include SPF
5. Configurar o console regional, adicionar o domínio, recuperar o identificador MX e sincronizar o diretório
6. Testar em prioridade 99: validar o roteamento sem risco de perda de mensagem
7. Mudar os MX para prioridade baixa fora dos horários de pico e remover todos os antigos MX
8. Bloquear o conector M365/Google Workspace para só aceitar os IPs Barracuda
9. Implementar SPF (include regional, -all), DKIM (2048 bits) e DMARC (p=none depois endurecimento)
10. Monitorar a quarentena, os relatórios DMARC e subir até p=reject após 4 a 8 semanas de monitoramento limpo

📚 Guias de gateways de email

Esta análise faz parte da nossa série sobre as soluções de segurança de email:

• Mimecast Secure Email Gateway: arquitetura, configuração DNS, comparativo e plano de ação
• Proofpoint Secure Email Gateway: Nexus AI, TAP, EchoSpoofing 2024 e configuração DNS
• Abnormal Security: IA comportamental, deployment API, Attune 1.0

FAQ

O que é o Barracuda Email Gateway Defense?

Barracuda Email Gateway Defense (EGD) é um Secure Email Gateway cloud que filtra 100 % do tráfego de email entrante antes que ele alcance seu servidor de mensagens. Você redireciona seus registros MX para a infraestrutura Barracuda (<id>.ess.barracudanetworks.com), que inspeciona cada mensagem (reputação, anti-spam, anti-malware, Advanced Threat Protection, anti-phishing) e depois transfere o tráfego limpo para o Microsoft 365, o Google Workspace ou o Exchange. É o antigo Barracuda Email Security Service (BESS), historicamente orientado a PMEs e MSPs, com mais de 200 mil clientes no mundo.

Qual é a diferença entre Email Gateway Defense e Email Security Gateway?

São dois produtos distintos. Email Gateway Defense (EGD) é o serviço SEG cloud, hospedado inteiramente na Barracuda sob ess.barracudanetworks.com, sem hardware para gerenciar. Email Security Gateway (ESG) é um appliance físico ou virtual legacy, implantado on-premise ou na cloud do cliente, que a organização administra e corrige ela mesma. É o appliance ESG, e não o serviço cloud EGD, que foi visado pela CVE-2023-2868 em 2023. O Barracuda promove ativamente a migração dos clientes ESG para EGD via seu programa ESG Elevate.

Quais são os registros MX do Barracuda?

Os MX do Barracuda Email Gateway Defense seguem o formato <identificador-cliente>.ess.barracudanetworks.com, por exemplo d9307303a.ess.barracudanetworks.com. O identificador é único para sua conta e visível na página de verificação de domínio do console EGD. Durante a implantação, o Barracuda recomenda adicionar esse MX em prioridade 99 para a fase de teste (o email legítimo fica no antigo servidor), depois passá-lo para prioridade baixa (10) e remover os antigos MX uma vez validada a configuração.

Qual SPF include usar com o Barracuda?

O include SPF depende da sua região. Nos Estados Unidos: include:spf.ess.barracudanetworks.com. Na Alemanha/Europa: include:spf.ess.de.barracudanetworks.com. No Reino Unido: include:spf.ess.uk.barracudanetworks.com. No Canadá: include:spf.ess.ca.barracudanetworks.com. Na Austrália: include:spf.ess.au.barracudanetworks.com. Na Índia: include:spf.ess.in.barracudanetworks.com. O Barracuda recomenda terminar o registro por -all. Fique de olho no número total de lookups DNS para permanecer abaixo do limite de 10 imposto pela RFC 7208.

Como detectar que um domínio está protegido pelo Barracuda?

Duas assinaturas DNS o identificam. Do lado entrante: um registro MX terminado em .ess.barracudanetworks.com (dig MX dominio.com +short). Do lado de saída: a presença de um include:spf.ess[.<region>].barracudanetworks.com no registro TXT do domínio (dig TXT dominio.com +short). Cruzar os dois elimina toda ambiguidade. Você também pode usar a ferramenta DNS Lookup da CaptainDNS para exibir esses registros de forma legível sem manipular o dig.

O Barracuda funciona com Microsoft 365 e Google Workspace?

Sim. O Barracuda Email Gateway Defense é independente do provedor de mensagens. Em modo gateway, você redireciona os MX para o Barracuda qualquer que seja seu servidor de destino (Microsoft 365, Google Workspace, Exchange on-premise), depois configura a conexão de saída no console EGD. Do lado Microsoft 365, a integração repousa concretamente em três conectores (dois entrantes, um de saída) mais uma política "allow spoofing" para o tráfego vindo do Barracuda; o bloqueio anti-contorno passa por um conector partner entrante que só aceita os IPs Barracuda. Para o Microsoft 365, os planos superiores adicionam uma camada de defesa da caixa de entrada por API e um módulo Incident Response para remover as mensagens maliciosas já entregues.

A CVE-2023-2868 afeta o Email Gateway Defense (cloud)?

Não. A CVE-2023-2868 (injeção de comando via parsing de arquivos .tar, CVSS 9.8) visava exclusivamente o appliance Email Security Gateway (ESG), não o serviço cloud Email Gateway Defense (EGD). Se você usa o EGD, você não estava exposto a essa falha. O incidente, explorado já em outubro de 2022 pelo ator UNC4841 (atribuição Mandiant, China-nexus), levou o Barracuda a recomendar a substituição física dos appliances ESG comprometidos em 6 de junho de 2023, em razão de portas dos fundos persistentes que sobreviviam às correções. É um dos argumentos avançados para migrar do appliance ESG para a cloud EGD.

O Barracuda é adequado às PMEs e MSPs?

Sim, é até seu posicionamento preferencial. O Barracuda EGD é concebido para ser simples de implantar e de operar sem equipe SOC dedicada, com uma relação preço/cobertura atrativa para as PMEs e o mid-market. Para os MSPs, a arquitetura multi-tenant permite provisionar, configurar e supervisionar a segurança de email de dezenas de clientes a partir de um console central, com remediação em massa e cobrança por uso. É um dos programas MSP mais completos do mercado, onde as soluções enterprise continuam pesadas de operar em modo multi-cliente.

Como migrar do appliance ESG para o Email Gateway Defense?

A migração consiste em passar de uma filtragem on-premise para uma filtragem cloud, via programa Barracuda "ESG Elevate". Você provisiona o EGD no console regional, você transpõe suas políticas de filtragem (o Barracuda fornece assistentes), você testa em prioridade 99 sem risco de perda de mensagem, depois muda os MX do appliance para <id>.ess.barracudanetworks.com em prioridade baixa, removendo os antigos MX. O benefício principal: não há mais appliance para manter nem patch crítico para aplicar com urgência, o que elimina a superfície de ataque que havia sido explorada pela CVE-2023-2868.

O Barracuda gerencia DMARC e DKIM?

Sim. A assinatura DKIM se configura no console EGD: você escolhe um seletor, o Barracuda gera o par de chaves, e você publica a chave pública em TXT em seletor._domainkey.captaindns.com (prefira 2048 bits). Para o DMARC, o EGD se apoia no seu alinhamento SPF/DKIM, e você gerencia a política de p=none até p=reject. No plano Premium Plus, o módulo Domain Fraud Protection agrega e visualiza os relatórios DMARC e acompanha a subida até a política estrita. No EGD sozinho, você pode gerenciar o DMARC com uma ferramenta de terceiros validando a sintaxe com o verificador DMARC CaptainDNS.

Baixe as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os arquivos JSON ou CSV abaixo.

• Baixar o comparativo (CSV)
• Baixar o comparativo (JSON)

Glossário

• SEG (Secure Email Gateway): gateway de segurança de email que filtra o tráfego entrante e de saída entre a Internet e o servidor de mensagens, analisando cada mensagem (spam, malware, phishing) antes de transmiti-la ao destinatário.

• EGD (Email Gateway Defense): o Secure Email Gateway cloud do Barracuda, hospedado sob ess.barracudanetworks.com. Antigamente Barracuda Email Security Service (BESS). Assunto deste artigo.

• ESG (Email Security Gateway): o appliance Barracuda legacy (físico ou virtual), administrado e corrigido pelo cliente. A não confundir com o EGD. É a linha visada pela CVE-2023-2868.

• BESS (Barracuda Email Security Service): antigo nome do serviço cloud hoje chamado Email Gateway Defense.

• MX (Mail Exchanger): registro DNS que indica os servidores responsáveis pela recepção dos emails de um domínio. Implantar o Barracuda EGD implica redirecionar os MX para <id>.ess.barracudanetworks.com.

• SPF (Sender Policy Framework): protocolo de autenticação que lista os servidores autorizados a enviar emails por um domínio. Registro TXT limitado a 10 lookups recursivos (RFC 7208). O Barracuda usa um include regional (spf.ess[.<region>].barracudanetworks.com).

• DKIM (DomainKeys Identified Mail): protocolo que assina criptograficamente os emails. A chave pública é publicada no DNS, permitindo ao destinatário verificar a integridade e a origem da mensagem.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): protocolo que verifica o alinhamento entre o domínio From e os domínios autenticados por SPF ou DKIM, e define a política a aplicar em caso de falha (none, quarantine, reject).

• ATP (Advanced Threat Protection): módulo Barracuda que analisa os anexos e cargas úteis desconhecidas numa sandbox para detectar as ameaças zero-day por observação comportamental.

• Impersonation Protection: motor Barracuda de detecção dos ataques por usurpação (BEC), baseado no aprendizado dos padrões de comunicação normais da organização para identificar as anomalias.

• Incident Response: módulo Barracuda que permite remover automaticamente os emails maliciosos já entregues nas caixas de entrada, com remediação em massa, particularmente útil para os MSPs.

• BEC (Business Email Compromise): fraude por email em que o atacante se faz passar por um dirigente ou um parceiro de confiança para obter uma transferência ou dados sensíveis. Frequentemente sem link nem anexo, portanto invisível aos filtros por assinatura.

• MSP (Managed Service Provider): prestador que gerencia a infraestrutura de TI de vários clientes. A arquitetura multi-tenant do Barracuda é pensada para esse modelo.

• CVE-2023-2868: vulnerabilidade crítica (CVSS 9.8) de injeção de comando via parsing de arquivos .tar no appliance ESG, explorada pelo UNC4841. Não afeta o serviço cloud EGD.

• UNC4841: ator de ameaça suspeito de estar ligado à China (China-nexus), a quem a Mandiant atribui a exploração da CVE-2023-2868 nos appliances ESG já em outubro de 2022.

Fontes

• Barracuda Campus: Email Gateway Defense, verificação de domínio e MX
• Barracuda Campus: Sender Policy Framework para o email de saída (includes regionais)
• Barracuda Campus: Understanding Link Protection
• Barracuda Campus: integração Microsoft 365 (conectores)
• Barracuda: 2025 Email Threats Report
• Barracuda Trust Center: ESG Appliance Vulnerability (CVE-2023-2868)
• Gartner Peer Insights: Email Security Platforms, avaliações Barracuda
• Mandiant / Google Cloud: exploração mundial do ESG pelo UNC4841
• Gartner Magic Quadrant for Email Security 2025