Hornetsecurity Secure Email Gateway (ex-Vade): arquitetura, configuração DNS e alternativas

⚡TL;DR

• 🛡️ Hornetsecurity 365 Total Protection é um Secure Email Gateway cloud orientado a PMEs e MSPs, com cerca de 125 000 clientes e mais de 12 000 parceiros. Ele se posiciona à frente do Microsoft 365 via redirecionamento MX e filtra o tráfego entrante.
• 🔁 A marca Vade desapareceu. A fabricante francesa Vade (anti-phishing por IA) foi comprada pela Hornetsecurity em março de 2024, e sua marca foi depois extinta em fevereiro de 2025 durante o rebranding "One Team, one Brand". Tratamos, portanto, a Vade como uma entidade absorvida.
• 🔧 Impacto DNS específico: MX para mx01.hornetsecurity.com até mx04 (prioridades 10/20/30/40), include spf.hornetsecurity.com, e sobretudo um DKIM por CNAME (hse1._domainkey / hse2._domainkey). Nenhuma chave TXT a publicar na sua zona, ao contrário de Barracuda ou Mimecast.
• 📊 Nova proprietária desde dezembro de 2025: a Proofpoint finalizou a aquisição da Hornetsecurity por US$ 1,8 bilhão, que se torna sua business unit dedicada aos MSPs. Na América do Norte, a oferta agora é comercializada sob o nome Proofpoint Total Protection (pp-tp.com).

Se você gerencia o email de uma PME, de um escritório ou de um parque de clientes como MSP, provavelmente já cruzou com a Hornetsecurity, ou com sua antiga concorrente que virou subsidiária, a Vade. A fabricante alemã reivindica cerca de 125 000 clientes e mais de 12 000 parceiros num nicho que ela ocupou pacientemente: a segurança Microsoft 365 vendida por e para os prestadores de TI. Onde a Proofpoint dominava historicamente a grande conta e a Barracuda o SMB americano, a Hornetsecurity construiu uma posição de referência europeia no modelo MSP multi-tenant.

Mas analisar a Hornetsecurity em 2026 é, antes de tudo, desembaraçar uma tripla identidade que confunde. Há a Hornetsecurity, a fabricante de Hanôver por trás da suíte 365 Total Protection. Há a Vade, a fabricante francesa de Hem (perto de Lille), absorvida em 2024 e cuja marca oficialmente não existe mais desde fevereiro de 2025. E há a Proofpoint, que comprou o conjunto no fim de 2025. Três nomes, uma só realidade societária hoje. Mas dois modelos técnicos bem distintos continuam a coexistir, e é aí que tudo se decide do lado do DNS.

A questão não tem nada de abstrato. Um gateway de email seguro (em inglês secure email gateway, ou SEG) não serve de nada se o seu domínio continuar usurpável por falta de autenticação correta. Filtrar o fluxo entrante protege suas caixas. Não protege sua marca contra a usurpação de saída. Antes mesmo de implantar a Hornetsecurity, verifique onde você está com o verificador de sintaxe DMARC CaptainDNS: é ele que dirá se um atacante pode enviar email em seu nome.

Na CaptainDNS, olhamos a Hornetsecurity sob o ângulo que nos interessa: o impacto concreto nos seus registros DNS e na sua autenticação de email. Implantar o 365 Total Protection em modo gateway é redirecionar seus MX para mx01.hornetsecurity.com, adicionar o include spf.hornetsecurity.com, e delegar seu DKIM por CNAME. Implantar o Vade for M365 em modo API, ao contrário, não toca nenhum registro DNS. Este guia cobre a saga das aquisições, as duas arquiteturas, a configuração DNS detalhada com os valores reais, a detecção de um domínio por trás da Hornetsecurity, o comparativo e um plano de ação. E ele não esconde as incertezas do pós-aquisição: nós as sinalizamos onde elas existem.

📌 O que é o secure email gateway da hornetsecurity?

Hornetsecurity 365 Total Protection é uma suíte de segurança de email cloud construída em torno de um secure email gateway (SEG): um filtro hospedado que inspeciona o tráfego de email entrante antes que ele alcance seu tenant Microsoft 365. Em modo gateway, você redireciona seus registros MX para a infraestrutura Hornetsecurity, que analisa cada mensagem e depois transfere apenas o tráfego limpo para o Exchange Online.

Para os fundamentos de um SEG (modelo gateway, redirecionamento MX, distinção com as soluções ICES API-native), remetemos ao nosso guia completo sobre o Barracuda, que apresenta esses fundamentos em detalhe. O essencial cabe numa frase: um SEG se posiciona entre a Internet e seu servidor de mensagens, vê a totalidade do fluxo entrante, e bloqueia as ameaças antes da entrega em vez de remediar depois.

A particularidade da Hornetsecurity está em que a marca abrange duas abordagens técnicas sem muita coisa em comum, herdadas da fusão com a Vade. De um lado, o 365 Total Protection, o SEG clássico baseado no redirecionamento MX, assunto principal deste artigo. Do outro, o Vade for M365, uma proteção API-native que se ativa por journaling sem tocar nos MX. Confundir os dois leva direto ao erro de diagnóstico: um domínio protegido pelo Vade for M365 não mostra nenhuma assinatura DNS, ao passo que um domínio em 365 Total Protection se identifica de cara pelos seus MX. Detalhamos esse contraste mais adiante.

A suíte 365 Total Protection se declina em vários planos, da filtragem de base (anti-spam, anti-malware) até os planos superiores que adicionam a sandbox ATP, a proteção anti-usurpação, a continuidade de serviço, o arquivamento juridicamente conforme e o backup Microsoft 365. A Hornetsecurity acrescenta módulos transversais como o Security Awareness Service (conscientização sobre phishing) e um DMARC Manager. Tudo é pilotado a partir de um Control Panel multi-tenant, talhado para os MSPs.

🕰️ A saga das aquisições: de vade a proofpoint

Três operações em menos de dois anos fundiram duas fabricantes concorrentes, e depois passaram o conjunto para uma gigante americana. Aqui está a cronologia, datas em mãos.

Vade: o anti-phishing por ia francês, em api-native

A Vade (antiga Vade Secure) é uma fabricante francesa fundada em 2009 e sediada em Hem, na região metropolitana de Lille. Sua reputação se construiu sobre um motor de anti-phishing por inteligência artificial reconhecido, e sobre um modelo de distribuição orientado a provedores de acesso e MSPs. No momento da aquisição, a empresa reivindicava a proteção de cerca de 1,4 bilhão de caixas no mundo e a análise de vários bilhões de mensagens por dia, em grande parte via parcerias com operadoras.

Sobretudo, a Vade trazia uma abordagem técnica distinta da do SEG clássico: seu produto principal, Vade for M365, funciona em API-native sobre o Microsoft 365. Sem redirecionamento MX, sem gateway físico no fluxo: a análise se conecta diretamente ao tenant via a API Microsoft. É esse know-how que a Hornetsecurity, historicamente posicionada no modelo gateway, foi buscar.

5 de março de 2024: a hornetsecurity compra a vade

Em 5 de março de 2024, a Hornetsecurity, fabricante alemã sediada em Hanôver, anuncia a aquisição da Vade. A operação é apresentada como a criação de um campeão europeu da segurança Microsoft 365, combinando a base MSP e a suíte 365 Total Protection da Hornetsecurity com o motor de IA e a presença junto a operadoras da Vade. No papel, as duas peças se complementam: um SEG cloud comprovado de um lado, uma expertise em API e anti-phishing do outro.

21 de fevereiro de 2025: "one team, one brand", a vade se apaga

Menos de um ano depois, em 21 de fevereiro de 2025, a Hornetsecurity formaliza a fusão das marcas sob o lema "One Team, one Brand". A marca Vade desaparece: logo, cores, comunicação e processos são unificados sob a identidade Hornetsecurity. Os produtos herdados da Vade sobrevivem tecnicamente (o Vade for M365 continua sendo uma opção de implantação), mas o nome comercial se apaga. É por isso que este artigo trata a Vade como uma entidade absorvida, da qual restam sobretudo um modelo técnico e um tráfego de busca residual.

8 de dezembro de 2025: a proofpoint finaliza a aquisição

Último ato, em 8 de dezembro de 2025: a Proofpoint, ator americano de referência da segurança de email, finaliza a aquisição da Hornetsecurity por cerca de US$ 1,8 bilhão. A operação valoriza uma receita recorrente anual (ARR) de cerca de 200 milhões de dólares em forte crescimento. A Hornetsecurity se torna uma business unit dedicada aos MSPs dentro da Proofpoint, preenchendo precisamente o segmento SMB e de canal onde a Proofpoint, historicamente voltada ao enterprise, estava menos presente. Na América do Norte, a oferta agora é comercializada sob o nome Proofpoint Total Protection, com uma infraestrutura dedicada sob o domínio pp-tp.com. A marca Hornetsecurity, por outro lado, permanece em vigor na Europa, ao menos durante a integração.

🏢 Hornetsecurity em resumo

A Hornetsecurity é uma fabricante alemã de segurança da cloud, fundada em 2007 e sediada em Hanôver, que reivindica cerca de 125 000 clientes e mais de 12 000 parceiros, com uma forte concentração no segmento PME e no modelo MSP. Seu crescimento foi impulsionado por aquisições sucessivas e por um produto principal, o 365 Total Protection, pensado para o canal.

A empresa operou por muito tempo sob o nome Antispameurope antes de se tornar Hornetsecurity. Seu posicionamento pouco variou: filtragem de email cloud, rápida de implantar, vendida em marca branca ou em co-marca por prestadores de TI. Onde certos concorrentes enterprise se dirigem ao cliente final único, a Hornetsecurity vende ao prestador que revende. Um MSP provisiona seus clientes a partir de um Control Panel central, herda as políticas de um modelo comum, as refina por tenant, e cobra por uso. Essa mecânica multi-tenant é o coração da atratividade da Hornetsecurity no canal.

A presença é nitidamente europeia, com uma força comercial e datacenters concentrados na Europa (Alemanha e França sobretudo, esta última reforçada pelo aporte da Vade). Essa pegada geográfica responde a um argumento recorrente do segmento: a residência dos dados na Europa, esperada pelas organizações sujeitas ao RGPD ou relutantes em confiar seu fluxo de email a uma infraestrutura fora da UE. A aquisição da Vade acrescentou uma P&D anti-phishing reconhecida e uma presença junto a operadoras. A passagem para a Proofpoint traz, por sua vez, o respaldo de uma threat intelligence de primeiro plano, cujos efeitos concretos sobre o produto ainda estão por observar.

⚙️ Arquitetura: dois modelos sob o mesmo teto

Desde a absorção da Vade, a Hornetsecurity propõe duas formas de proteger o Microsoft 365 que quase não têm nada em comum do lado da implantação e do lado do DNS: o gateway (365 Total Protection) e o API-native (Vade for M365). É o ponto central deste artigo, pois saber qual delas você implanta determina toda a sequência da sua configuração.

365 total protection: o modelo gateway, redirecionamento mx

O produto histórico da Hornetsecurity, o 365 Total Protection, é um SEG clássico. Seus registros MX apontam para a infraestrutura cloud Hornetsecurity. Quando um remetente escreve para contact@captaindns.com, o servidor dele resolve o MX, encontra um host Hornetsecurity (mx01.hornetsecurity.com e seus pares), e entrega a mensagem lá. A Hornetsecurity aplica sua cadeia de inspeção (reputação, anti-spam, anti-malware, sandbox ATP, anti-phishing), e depois transfere a mensagem validada para o Exchange Online.

A vantagem é a mesma de qualquer SEG: a Hornetsecurity vê 100 % do tráfego entrante e bloqueia as ameaças antes que elas toquem seu tenant. O reverso é uma implantação visível e intrusiva. É preciso modificar os MX, ajustar o SPF, delegar o DKIM, e gerenciar uma mudança sem interrupção. É precisamente a operação que este guia detalha.

Vade for M365: o api-native, sem mudança de mx

O legado Vade introduz um modelo radicalmente diferente. O Vade for M365 não se posiciona no fluxo SMTP. Ele se ativa por journaling Microsoft 365: configura-se uma regra de journaling que envia uma cópia de cada mensagem à Vade, associa-se o tenant e uma conta O365, e a análise se faz após a recepção, sobre a cópia. O motor aplica um aprendizado de máquina comportamental para detectar o spear phishing, os malwares polimórficos e as ameaças zero-day, com remediação possível das mensagens já entregues.

Consequência maior para quem nos lê: essa implantação é invisível do lado do DNS. Nenhuma mudança de MX, nenhuma assinatura SPF entrante, nada a publicar na zona. A proteção vive inteiramente na relação API/journaling entre o tenant e a Vade. É cômodo: implantação "sem interrupção", e nenhum risco de perda de email ligado a uma mudança de MX malfeita. Mas isso levanta uma questão de auditoria, que retomamos mais abaixo: não é possível detectar essa proteção por uma simples consulta DNS.

Api-native contra gateway/mx: o que muda de fato

Três diferenças separam de verdade os dois modelos.

Visibilidade do fluxo. Um SEG em modo gateway vê a mensagem antes da entrega e pode bloqueá-la em pré-recepção. Uma proteção API/journaling analisa uma cópia após a recepção, e depois age em remediação (movimentação ou exclusão a posteriori). A janela de exposição, portanto, não é a mesma. O gateway impede, a API recupera.

Detectabilidade DNS. O gateway deixa rastros nítidos: MX, SPF, DKIM CNAME, autodiscover. A API não deixa nenhum rastro DNS entrante. Para um auditor externo, um domínio sob Vade for M365 se parece com um domínio Microsoft 365 nu.

Integração e risco operacional. O gateway impõe uma mudança de MX, com seu risco clássico de perda de email se ela for malconduzida, mas oferece um controle total do fluxo. A API, por sua vez, se implanta em alguns cliques sem tocar no DNS, ao preço de uma dependência da API Microsoft e de uma ação conduzida após a entrega. Muitas organizações já full M365 optam pela API por sua simplicidade. As que querem interceptar antes da caixa mantêm o gateway.

🔧 Configuração DNS etapa por etapa

Esta seção diz respeito ao modo gateway (365 Total Protection). A implantação modifica quatro famílias de registros: MX, SPF, DKIM e DMARC, mais um eventual CNAME autodiscover. Um erro em um deles, e seus emails desaparecem ou contornam a filtragem. Aqui está cada etapa com os valores reais comunicados pela Hornetsecurity no onboarding, e as armadilhas a evitar.

Os registros MX

Na região europeia, a Hornetsecurity faz os MX apontarem para quatro hosts, com prioridades escalonadas para a redundância:

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

O servidor mais prioritário (prioridade 10) recebe o tráfego; os seguintes garantem a comutação em caso de indisponibilidade. É uma nomenclatura regional genérica, ao contrário da Barracuda, cujo MX integra um identificador de conta único. Essa generalidade é cômoda para a detecção (ver mais adiante), mas implica que o roteamento para o seu tenant se configura do lado do Control Panel, não via o hostname MX.

Ponto crucial no pós-aquisição: na América do Norte, a oferta agora é comercializada sob o nome Proofpoint Total Protection, com uma infraestrutura dedicada sob o domínio pp-tp.com (relay de envio do tipo relay01-hz14.pp-tp.com, include SPF spf.pp-tp.com). Os valores MX entrantes norte-americanos, portanto, diferem dos valores europeus e são comunicados a você na ativação, via o painel de administração. Não copie mecanicamente os valores mx01.hornetsecurity.com se o seu tenant for provisionado na região norte-americana: confirme sempre os hosts exatos no seu Control Panel.

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

A armadilha do MX residual. Após a mudança para a Hornetsecurity, não deixe nenhum MX residual apontando para seu antigo servidor ou diretamente para 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 a Hornetsecurity. Após a mudança, verifique com dig MX que só restam os MX Hornetsecurity, e bloqueie seu conector Microsoft 365 para só aceitar o tráfego vindo da Hornetsecurity.

Uma implantação limpa prevê também um CNAME autodiscover apontando para autodiscover.hornetsecurity.com, que facilita a configuração automática dos clientes de email. Ele não é indispensável à filtragem, mas faz parte da configuração padrão documentada pela fabricante.

O SPF com o include hornetsecurity

Para o email de saída retransmitido pela Hornetsecurity, você adiciona o include SPF da fabricante. O valor comunicado no onboarding europeu é simples e sem variante regional aparente do lado do SPF entrante:

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

Na América do Norte (Proofpoint Total Protection), o include passa a ser include:spf.pp-tp.com. Nos dois casos, se você também envia direto pelo Microsoft 365, você combina os includes:

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

A Hornetsecurity documenta o ~all (softfail) no seu exemplo de onboarding, mas você pode endurecer para -all (hardfail) uma vez que seu inventário de remetentes esteja completo e seu DMARC estabilizado. O -all adiciona uma proteção no nível do próprio SPF, lá onde o ~all deixa passar em caso de falha sem bloquear. Fique de olho sobretudo no número total de lookups DNS: a especificação SPF (RFC 7208) impõe um limite de 10 lookups recursivos. Acumule Hornetsecurity, Microsoft 365 e dois ou três ESPs (Mailchimp, SendGrid etc.), e você chega rápido ao teto, com um PermError na conta que quebra toda a validação SPF. O verificador de sintaxe SPF CaptainDNS contabiliza esses lookups e sinaliza os estouros.

O DKIM por CNAME, o diferenciador

É aqui que a Hornetsecurity se distingue nitidamente da Barracuda ou da Mimecast. Em vez de fazer você publicar uma chave pública TXT gerada no console, a Hornetsecurity opera a assinatura DKIM do seu lado e pede a você apenas que delegue dois seletores por registros CNAME:

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

A consequência prática é cômoda: nenhuma chave TXT na sua zona, portanto nenhuma rotação de chave a gerenciar manualmente do seu lado. A Hornetsecurity rotaciona suas chaves por trás do CNAME, de forma transparente. Você publica os dois CNAME de uma vez por todas, e depois ativa a assinatura (e, se quiser, a validação DKIM entrante) no Control Panel, em Email Authentication. A presença de dois seletores (hse1 e hse2) permite justamente a rotação do lado da fabricante sem intervenção no seu DNS.

# Verificar a delegação DKIM por CNAME
dig CNAME hse1._domainkey.captaindns.com +short
# Resposta esperada: hse1._domainkey.hornetsecurity.com.

O reverso dessa comodidade é uma dependência: seu DKIM repousa inteiramente na cadeia CNAME para a Hornetsecurity. Se a delegação quebrar (CNAME removido, zona DNS mal editada, ou problema do lado da resolução do alvo), sua assinatura DKIM cai, e com ela o alinhamento DMARC. Voltamos a isso nos limites.

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. Por trás de um gateway, um ponto merece atenção: o relay de saída via Hornetsecurity pode reescrever o envelope SMTP, o que faz perder o alinhamento SPF do lado do destinatário. É então o DKIM que se torna o pilar do alinhamento DMARC. Daí a importância de colocar corretamente os dois CNAME DKIM antes de endurecer a política: sem assinatura DKIM válida, mensagens mesmo legítimas falharão no DMARC uma vez em p=reject.

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

1. p=none (monitoramento): você recebe os relatórios agregados sem afetar a entrega. Duração: 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;

A Hornetsecurity propõe um módulo DMARC Manager que agrega e visualiza os relatórios, identifica as fontes de envio legítimas ainda não autenticadas e acompanha a subida até p=reject. Se você pilota o DMARC com outra ferramenta, valide cada evolução do registro com o verificador de sintaxe DMARC CaptainDNS.

🔍 Detectar que um domínio está protegido pela hornetsecurity

Para saber se um domínio usa o 365 Total Protection em modo gateway, examine seus registros DNS: um MX terminado em .hornetsecurity.com, um include spf.hornetsecurity.com, ou CNAME hse1._domainkey / hse2._domainkey apontando para hornetsecurity.com são assinaturas inequívocas. Com uma ressalva de peso: essa detecção só funciona para o modelo gateway, não para o Vade for M365 em modo API.

Para que isso serve? Auditar um prospect antes de uma reunião, qualificar a stack de um parceiro, ou simplesmente entender por onde transitam seus próprios emails. O método repousa sobre quatro assinaturas DNS.

Assinatura MX. Todo MX cujo hostname termina em .hornetsecurity.com (os hosts mx01 a mx04) indica um domínio por trás do 365 Total Protection em modo gateway.

# Detectar Hornetsecurity pelo MX
dig MX captaindns.com +short
# Respostas do tipo "10 mx01.hornetsecurity.com." = 365 Total Protection (gateway)

Assinatura SPF. A presença de um include:spf.hornetsecurity.com (ou include:spf.pp-tp.com na América do Norte) no registro TXT do domínio confirma que a Hornetsecurity retransmite o email de saída.

# Detectar Hornetsecurity pelo SPF
dig TXT captaindns.com +short | grep spf
# Presença de "include:spf.hornetsecurity.com" = relay de saída Hornetsecurity

Assinaturas DKIM e autodiscover. Os CNAME hse1._domainkey / hse2._domainkey para hornetsecurity.com, e um eventual CNAME autodiscover para autodiscover.hornetsecurity.com, completam o feixe de indícios e confirmam a delegação de assinatura.

# Detectar a delegação DKIM Hornetsecurity
dig CNAME hse1._domainkey.captaindns.com +short
# Resposta "hse1._domainkey.hornetsecurity.com." = DKIM delegado à Hornetsecurity

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 CNAME num piscar de olhos. Cruzar MX, SPF e CNAME DKIM elimina toda ambiguidade sobre o modo gateway.

O ponto-chave a reter: o Vade for M365 é indetectável no DNS. Como ele se implanta por journaling Microsoft 365 sem tocar nos MX nem no SPF entrante, um domínio protegido pelo Vade for M365 não apresenta nenhuma assinatura DNS da Hornetsecurity. É um limite estrutural de qualquer auditoria externa: a ausência de assinatura DNS não prova a ausência de proteção. Para essas implantações, só uma inspeção da configuração interna do tenant (regras de journaling, aplicações conectadas) permite concluir.

🔄 Comparativo frente a proofpoint, barracuda, mimecast e microsoft

A Hornetsecurity se distingue pelo seu posicionamento PME e MSP europeu, agora respaldado pela Proofpoint. A tabela abaixo compara os critérios que realmente pesam numa escolha. A linha "Proofpoint" deve ser lida com a nuance que a aquisição impõe: a Hornetsecurity agora é parte da Proofpoint, mas os dois produtos mantêm seu posicionamento distinto (SMB/MSP para a Hornetsecurity, enterprise para a Proofpoint histórica).

Critério	Hornetsecurity	Proofpoint	Barracuda	Mimecast	Microsoft Defender
Tipo	SEG cloud (365 TP) + API (Vade for M365)	SEG enterprise + ICES	SEG cloud + Inbox Defense API	SEG + API	Nativo M365
Alvo	PME, MSP (Europa)	Fortune 100, grandes empresas	PME, mid-market, MSP	PME/médio porte multinecessidades	Ambientes M365
Detecção IA	ML comportamental + motor Vade anti-phishing	Nexus AI	Impersonation Protection	CyberGraph	Detecção nativa
MSP multi-tenant	Sim (ponto forte histórico)	Via a BU Hornetsecurity	Sim (ponto forte)	Parcial	Via parceiros CSP
Modelo DNS	API (sem MX) ou gateway (MX)	Gateway/MX	Gateway/MX	Gateway/MX	API/nativo (sem MX)
DMARC	DMARC Manager integrado	EFD com consultores	Domain Fraud (Premium Plus)	DMARC Analyzer integrado	Não
Formato MX	mx01.hornetsecurity.com (EU)	mx0a-XXXX.pphosted.com	<id>.ess.barracudanetworks.com	eu-smtp-inbound-1.mimecast.com	*.mail.protection.outlook.com
Ideal para	PME/MSP Europa, duplo modelo API+gateway	Threat intel de elite	SMB e MSP, simplicidade/preço	Centralizar segurança + arquivamento	Full M365, orçamento apertado

Proofpoint, a proprietária e a concorrente enterprise

O caso Proofpoint é particular, já que, desde dezembro de 2025, a Hornetsecurity pertence a ela. Mas os dois produtos permanecem distintos: a Proofpoint histórica visa a grande conta, com sua threat intelligence de elite e sua abordagem people-centric, a um custo e a uma complexidade que ultrapassam largamente as necessidades de uma PME. A Hornetsecurity preenche o segmento SMB/MSP que a Proofpoint atendia mal. Para um comprador, a escolha, portanto, não é "Hornetsecurity ou Proofpoint" no absoluto, mas "qual produto do portfólio Proofpoint corresponde ao meu tamanho". Nosso guia completo sobre o Proofpoint detalha a oferta enterprise e sua configuração DNS.

Barracuda, a concorrente direta no mesmo segmento

No segmento PME e MSP, o Barracuda Email Gateway Defense é a concorrente mais frontal da Hornetsecurity. Mesmo modelo gateway/MX, mesmo cerne de alvo, mesmo argumento multi-tenant para os MSPs. A diferença se decide nos detalhes: a Barracuda faz publicar uma chave DKIM TXT lá onde a Hornetsecurity delega por CNAME, seu MX integra um identificador de conta único, e sua cobertura regional (seis regiões) difere da pegada antes europeia da Hornetsecurity. Nosso guia completo sobre o Barracuda detalha sua arquitetura e sua configuração DNS para a comparação fina.

Mimecast, abnormal e microsoft defender

No médio porte multinecessidades, a Mimecast propõe uma suíte mais ampla em nativo (arquivamento de longa duração, continuidade, DMARC Analyzer), ao preço de um console mais complexo. Do lado da detecção comportamental pura e API-native, a Abnormal Security se destaca no BEC e no VEC e se usa muitas vezes em complemento de um SEG em vez de em substituição (veja nosso guia completo sobre a Abnormal Security); sua abordagem API lembra, aliás, a do Vade for M365. Por fim, se você é full Microsoft 365 com necessidades padrão, o Defender for Office 365 continua imbatível na relação preço/cobertura (proteção nativa sem mudança de MX, muitas vezes incluso na licença E5). A Hornetsecurity mantém a vantagem na independência de produto e no modelo MSP, mas a decisão depende do seu tamanho, do seu canal e da sua exigência de residência dos dados.

🖥️ Migração e implantação

A implantação em modo gateway se faz sem interrupção se você seguir a ordem: inventário DNS, escolha do modelo, configuração do console, mudança de MX, e depois autenticação e monitoramento. A sequência abaixo detalha as cinco etapas.

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

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: Microsoft 365, marketing (Mailchimp, HubSpot), transacional (SendGrid, Mailgun), CRM, ticketing. Cada uma deverá ser autenticada na sua nova configuração SPF e levada em conta na roadmap DMARC, permanecendo abaixo do limite de 10 lookups.

2. Decida entre as duas abordagens. O modo gateway (365 Total Protection) intercepta antes da caixa, vê 100 % do fluxo entrante, mas impõe uma mudança de MX e uma configuração DNS completa. O modo API (Vade for M365) se implanta por journaling sem tocar no DNS, analisa uma cópia após a recepção e remedia a posteriori. A escolha depende da sua tolerância ao risco, da sua exigência de interceptação em pré-entrega e do seu conforto com uma mudança de MX.

3. No Control Panel Hornetsecurity (ou Proofpoint Total Protection na América do Norte), adicione seu domínio, verifique sua propriedade e sincronize o diretório de usuários. Recupere os valores DNS exatos comunicados no onboarding para a sua região (MX, include SPF, CNAME DKIM, autodiscover): eles diferem entre a Europa (hornetsecurity.com) e a América do Norte (pp-tp.com). Em modo API, configure antes a regra de journaling e a associação do tenant.

4. Em modo gateway, publique os MX mx01 a mx04.hornetsecurity.com (prioridades 10/20/30/40) fora dos horários de pico, remova todos os antigos MX, e bloqueie seu conector Microsoft 365 para só aceitar o tráfego Hornetsecurity (fechamento da porta dos fundos do MX residual). Em modo API, ative a regra de journaling M365 e verifique que as cópias chegam bem à Vade. Verifique o resultado com dig MX captaindns.com +short.

5. Adicione o include SPF Hornetsecurity permanecendo abaixo dos 10 lookups. Publique os dois CNAME DKIM (hse1 e hse2._domainkey) e ative a assinatura no Control Panel. Implante o DMARC em p=none, monitore os relatórios por 2 a 4 semanas, e depois suba para p=quarantine e p=reject. Valide cada registro com os verificadores CaptainDNS.

⚠️ Limites e pontos de atenção

A Hornetsecurity é sólida no seu segmento, mas alguns pontos merecem uma vigilância honesta, sobretudo no contexto pós-aquisição.

Incerteza pós-aquisição Proofpoint. A aquisição é recente (dezembro de 2025) e a integração ainda está por acontecer. Roadmap de produto, manutenção dos dois modelos (gateway e Vade for M365), eventual convergência com as peças Proofpoint, evolução tarifária, futuro da marca Hornetsecurity na Europa: são outras tantas incógnitas neste estágio. Ninguém pode garantir hoje a estabilidade do conjunto, e é melhor saber disso. Para um compromisso plurianual, faça essas perguntas explicitamente à fabricante e exija que as garantias sejam registradas no contrato.

Cobertura regional e mudança de marca. A pegada é nitidamente europeia. Na América do Norte, a oferta passa para Proofpoint Total Protection com uma infraestrutura distinta (pp-tp.com), o que muda os valores DNS e pode complicar uma implantação multirregiões sob uma marca única. Verifique que sua exigência de residência dos dados corresponde bem a uma região disponível.

Falsos positivos e quarentena. Como qualquer SEG, a Hornetsecurity pode colocar em quarentena remetentes legítimos, sobretudo nas primeiras semanas. Preveja uma fase de ajuste: monitoramento ativo da quarentena, listas de autorização, ajuste das políticas. É um trabalho de operação clássico, mas real, que não se deve subestimar no início.

Dependência da cadeia CNAME DKIM. O conforto do DKIM por CNAME tem um custo: sua assinatura depende inteiramente da delegação para hornetsecurity.com. Uma remoção acidental de um CNAME, uma zona DNS mal editada ou um problema do lado do alvo, e seu DKIM cai, acarretando falhas DMARC em email mesmo legítimo. Monitore a resolução desses CNAME como você monitoraria uma chave TXT, e documente-os para evitar que uma "limpeza" de DNS os leve embora.

📋 Plano de ação recomendado

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

1. Auditar sua postura de email atual (MX, SPF, DKIM, DMARC) com as ferramentas CaptainDNS.
2. Esclarecer a identidade de produto: você avalia a Hornetsecurity 365 Total Protection (e/ou o Vade for M365), agora propriedade da Proofpoint, e não a oferta enterprise Proofpoint histórica.
3. Escolher o modelo: gateway (365 Total Protection, MX) para interceptar antes da caixa, ou API (Vade for M365, journaling) para uma implantação sem mudança de DNS.
4. Comparar com Barracuda (concorrente direta PME/MSP), Mimecast, Abnormal e Microsoft Defender conforme seu tamanho, seu canal e sua exigência de residência dos dados.
5. Identificar sua região (Europa hornetsecurity.com vs América do Norte pp-tp.com), que condiciona os valores DNS exatos.
6. Configurar o console (Control Panel), adicionar o domínio, verificar a propriedade e sincronizar o diretório.
7. Mudar os MX (mx01 a mx04, prioridades 10/20/30/40) fora dos horários de pico e remover todos os antigos MX, ou ativar o journaling em modo API.
8. Bloquear o conector Microsoft 365 para só aceitar o tráfego Hornetsecurity e fechar a porta dos fundos do MX residual.
9. Implementar SPF (include, abaixo de 10 lookups), DKIM (dois CNAME hse1/hse2) e DMARC (p=none depois endurecimento), monitorando a cadeia CNAME DKIM.
10. Monitorar a quarentena e os relatórios DMARC, e depois subir para 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 enterprise:

• Mimecast Secure Email Gateway: funcionamento, configuração DNS, comparativo e plano de ação
• Proofpoint Secure Email Gateway: Nexus AI, TAP, configuração DNS e a nova proprietária da Hornetsecurity
• Cisco Secure Email Cloud Gateway (CES): arquitetura SaaS, DNS iphmx.com e migração desde o ESA
• Abnormal Security: IA comportamental e deployment API, comparável ao modelo Vade for M365
• Cloudflare Email Service: Email Routing, Security e DMARC Management explicados
• Barracuda Email Gateway Defense: concorrente direta no segmento PME/MSP, arquitetura e configuração DNS
• Hornetsecurity Secure Email Gateway: 365 Total Protection, ex-Vade, agora Proofpoint (este artigo)

FAQ

O que é a Hornetsecurity 365 Total Protection?

A Hornetsecurity 365 Total Protection é uma suíte de segurança de email cloud construída em torno de um Secure Email Gateway. Em modo gateway, você redireciona seus registros MX para a infraestrutura Hornetsecurity (mx01.hornetsecurity.com a mx04), que inspeciona cada mensagem entrante (reputação, anti-spam, anti-malware, sandbox ATP, anti-phishing) e depois transfere o tráfego limpo para o Microsoft 365. A suíte adiciona, conforme os planos, a continuidade, o arquivamento, o backup M365, um DMARC Manager e um serviço de conscientização. Ela é historicamente orientada a PMEs e MSPs, com cerca de 125 000 clientes no mundo.

O que acontece com a Vade após a aquisição pela Hornetsecurity?

A Vade, fabricante francesa de anti-phishing por IA (Hem, perto de Lille), foi comprada pela Hornetsecurity em 5 de março de 2024. Sua marca foi depois extinta em 21 de fevereiro de 2025 durante o rebranding "One Team, one Brand", em favor da identidade Hornetsecurity. Tecnicamente, o produto Vade for M365 sobrevive como opção de implantação API-native, mas o nome comercial Vade não existe mais. Tratamos, portanto, a Vade como uma entidade absorvida, da qual restam sobretudo um modelo técnico distinto (API/journaling) e um know-how anti-phishing.

A Hornetsecurity pertence à Proofpoint?

Sim. A Proofpoint finalizou a aquisição da Hornetsecurity em 8 de dezembro de 2025, por cerca de US$ 1,8 bilhão. A Hornetsecurity se torna a business unit dedicada aos MSPs dentro da Proofpoint, preenchendo o segmento SMB e de canal onde a Proofpoint, voltada ao enterprise, estava menos presente. Na América do Norte, a oferta agora é comercializada sob o nome Proofpoint Total Protection, com uma infraestrutura dedicada sob o domínio pp-tp.com. A marca Hornetsecurity permanece em vigor na Europa, ao menos durante a integração.

Quais são os registros MX da Hornetsecurity?

Na região europeia, a Hornetsecurity faz os MX apontarem para quatro hosts com prioridades escalonadas: mx01.hornetsecurity.com (prioridade 10), mx02.hornetsecurity.com (20), mx03.hornetsecurity.com (30) e mx04.hornetsecurity.com (40). Na América do Norte, sob a marca Proofpoint Total Protection, a infraestrutura passa pelo domínio pp-tp.com e os valores exatos são comunicados a você na ativação, via o Control Panel. Confirme sempre os hosts exatos no seu painel de administração conforme a sua região.

Qual include SPF usar com a Hornetsecurity?

Na Europa, o include SPF é include:spf.hornetsecurity.com, a colocar antes do mecanismo final (~all no exemplo de onboarding, ou -all se você endurecer após o inventário completo dos seus remetentes). Na América do Norte (Proofpoint Total Protection), o include passa a ser include:spf.pp-tp.com. Fique de olho no número total de lookups DNS para permanecer abaixo do limite de 10 imposto pela RFC 7208, sobretudo se você acumular Microsoft 365 e vários ESPs.

Como configurar o DKIM com a Hornetsecurity (CNAME)?

A Hornetsecurity opera a assinatura DKIM do seu lado e pede a você que delegue dois seletores por CNAME: hse1._domainkey.<seu-dominio> para hse1._domainkey.hornetsecurity.com, e hse2._domainkey.<seu-dominio> para hse2._domainkey.hornetsecurity.com. Ao contrário de Barracuda ou Mimecast, você não publica nenhuma chave TXT na sua zona: a rotação das chaves se faz do lado da Hornetsecurity, por trás do CNAME. Uma vez publicados os dois CNAME, ative a assinatura (e eventualmente a validação entrante) no Control Panel, em Email Authentication.

Qual a diferença entre a abordagem gateway (MX) e a abordagem API da Vade?

O modo gateway (365 Total Protection) redireciona seus MX para a Hornetsecurity, que filtra 100 % do fluxo entrante antes da entrega; ele é visível no DNS (MX, SPF, CNAME DKIM). O modo API (Vade for M365) se implanta por journaling Microsoft 365 sem mudança de MX, analisa uma cópia após a recepção e remedia a posteriori; ele é invisível no DNS. O gateway impede em pré-entrega mas impõe uma mudança de MX; a API recupera em pós-entrega mas se implanta sem tocar no DNS. A escolha depende da sua necessidade de interceptação e da sua tolerância a uma mudança de MX.

Como detectar que um domínio está protegido pela Hornetsecurity?

Para o modo gateway, quatro assinaturas DNS o identificam: um MX terminado em .hornetsecurity.com (mx01 a mx04), um include:spf.hornetsecurity.com no TXT, CNAME hse1._domainkey / hse2._domainkey para hornetsecurity.com, e um eventual CNAME autodiscover. Cruzar essas assinaturas elimina toda ambiguidade. Atenção, porém: o modo API (Vade for M365) é indetectável no DNS, pois se implanta por journaling sem tocar nos MX. A ausência de assinatura DNS, portanto, não prova a ausência de proteção. A ferramenta DNS Lookup da CaptainDNS exibe esses registros de forma legível.

A Hornetsecurity funciona com Microsoft 365 e Google Workspace?

A Hornetsecurity é concebida antes de tudo para o Microsoft 365, onde os dois modelos se aplicam: o gateway (redirecionamento MX para a Hornetsecurity e depois transferência para o Exchange Online) e a API/journaling (Vade for M365), este último nativamente ligado ao M365. O modo gateway, baseado no redirecionamento MX, permanece em teoria independente do servidor de destino e pode proteger outros ambientes via redirecionamento MX, mas o ecossistema, o DMARC Manager e o Vade for M365 são talhados para o M365. Para o Google Workspace ou uma implantação híbrida, confirme a compatibilidade exata e o modo suportado junto à fabricante.

A Hornetsecurity é adequada às PMEs e MSPs?

Sim, é o seu posicionamento preferencial. A suíte é concebida para ser simples de implantar e de operar sem equipe SOC dedicada, e seu Control Panel multi-tenant permite a um MSP provisionar, configurar e supervisionar a segurança de email de dezenas de clientes a partir de um console central, com cobrança por uso. É um dos programas MSP mais completos da Europa, o que explica, aliás, o interesse da Proofpoint, que dele fez sua business unit MSP mundial após a aquisição de dezembro de 2025.

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 às vezes de saída) entre a Internet e o servidor de mensagens, analisando cada mensagem (spam, malware, phishing) antes de transmiti-la ao destinatário.

• 365 Total Protection: a suíte de segurança de email cloud da Hornetsecurity, articulada em torno de um SEG em modo gateway (redirecionamento MX) para proteger o Microsoft 365. Assunto principal deste artigo.

• Vade for M365: produto herdado da fabricante Vade, proteção de email API-native que se ativa por journaling Microsoft 365, sem mudança de MX. Analisa uma cópia das mensagens após a recepção, com remediação a posteriori.

• MX (Mail Exchanger): registro DNS que indica os servidores responsáveis pela recepção dos emails de um domínio. Implantar o 365 Total Protection em gateway implica redirecionar os MX para mx01.hornetsecurity.com a mx04.

• 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). A Hornetsecurity usa include:spf.hornetsecurity.com (ou spf.pp-tp.com na América do Norte).

• DKIM por CNAME: método em que o cliente não publica chave pública TXT mas delega a assinatura por registros CNAME (hse1._domainkey, hse2._domainkey para hornetsecurity.com). A rotação das chaves se faz do lado da fabricante, de forma transparente. É o diferenciador da Hornetsecurity frente a Barracuda ou Mimecast.

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

• Journaling: funcionalidade Microsoft 365 que envia uma cópia das mensagens a um destino terceiro. É o mecanismo de implantação do Vade for M365, que torna a proteção invisível do lado do DNS.

• MSP (Managed Service Provider): prestador que gerencia a infraestrutura de TI de vários clientes. O Control Panel multi-tenant da Hornetsecurity é pensado para esse modelo, que é o seu cerne de mercado.

• 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, daí o interesse da detecção comportamental.

• API-native vs gateway: dois modelos de proteção de email. O gateway se posiciona no fluxo SMTP por redirecionamento MX e bloqueia antes da entrega; o API-native se conecta ao tenant (journaling ou API), analisa após a recepção e remedia a posteriori, sem tocar no DNS.

Fontes

• Proofpoint Newsroom: Proofpoint Completes Acquisition of Hornetsecurity (US$ 1,8 bi, 8 de dezembro de 2025)
• Hornetsecurity: Onboarding information (Europa), MX, include SPF, autodiscover
• Proofpoint Total Protection: Onboarding information North America (pp-tp.com)
• Hornetsecurity KnowledgeBase: How to set up DKIM (CNAME hse1/hse2._domainkey)
• Hornetsecurity Services: 365 Total Protection (suíte e planos)
• Proofpoint: Launches Dedicated MSP Business Unit and Introduces 365 Total Protection for North America