Hornetsecurity Secure Email Gateway (ex-Vade): arquitectura, configuración DNS y alternativas

⚡TL;DR

• 🛡️ Hornetsecurity 365 Total Protection es un Secure Email Gateway cloud orientado a pymes y MSP, con cerca de 125 000 clientes y más de 12 000 partners. Se intercala delante de Microsoft 365 mediante redirección MX y filtra el tráfico entrante.
• 🔁 La marca Vade ha desaparecido. El editor francés Vade (anti-phishing por IA) fue comprado por Hornetsecurity en marzo de 2024, y luego su marca se extinguió en febrero de 2025 durante el rebranding «One Team, one Brand». Tratamos por tanto a Vade como una entidad absorbida.
• 🔧 Impacto DNS específico: MX hacia mx01.hornetsecurity.com a mx04 (prioridades 10/20/30/40), include spf.hornetsecurity.com y, sobre todo, un DKIM por CNAME (hse1._domainkey / hse2._domainkey). Ninguna clave TXT que publicar en tu zona, a diferencia de Barracuda o Mimecast.
• 📊 Nuevo propietario desde diciembre de 2025: Proofpoint ha finalizado la compra de Hornetsecurity por 1800 millones de dólares, que pasa a ser su business unit dedicada a los MSP. En Norteamérica, la oferta se comercializa ahora bajo Proofpoint Total Protection (pp-tp.com).

Si gestionas el correo de una pyme, de un despacho o de un parque de clientes como MSP, probablemente te hayas cruzado con Hornetsecurity, o con su antiguo competidor convertido en filial, Vade. El editor alemán reivindica cerca de 125 000 clientes y más de 12 000 partners en un nicho que ha ocupado pacientemente: la seguridad de Microsoft 365 vendida por y para los proveedores informáticos. Allí donde Proofpoint dominaba históricamente la gran cuenta y Barracuda el SMB estadounidense, Hornetsecurity se ha labrado un puesto de referencia europea sobre el modelo MSP multi-tenant.

Pero analizar Hornetsecurity en 2026 es, antes que nada, desenredar una triple identidad que se presta a confusión. Está Hornetsecurity, el editor de Hannover detrás de la suite 365 Total Protection. Está Vade, el editor francés de Hem (cerca de Lille), absorbido en 2024 y cuya marca oficialmente ya no existe desde febrero de 2025. Y está Proofpoint, que compró el conjunto a finales de 2025. Tres nombres, una sola realidad accionarial hoy. Pero dos modelos técnicos bien distintos siguen conviviendo, y es ahí donde se juega todo del lado del DNS.

El reto no tiene nada de abstracto. Una pasarela de correo segura (en inglés secure email gateway, o SEG) no sirve de nada si tu dominio sigue siendo suplantable por falta de una autenticación correcta. Filtrar el flujo entrante protege tus buzones. No protege tu marca contra la suplantación saliente. Antes incluso de desplegar Hornetsecurity, comprueba en qué punto estás con el verificador de sintaxis DMARC de CaptainDNS: te dirá si un atacante puede enviar correo en tu nombre.

En CaptainDNS, miramos Hornetsecurity desde el ángulo que nos ocupa: el impacto concreto sobre tus registros DNS y tu autenticación de email. Desplegar 365 Total Protection en modo gateway es redirigir tus MX hacia mx01.hornetsecurity.com, añadir el include spf.hornetsecurity.com y delegar tu DKIM por CNAME. Desplegar Vade for M365 en modo API, por el contrario, no toca ningún registro DNS. Esta guía cubre la saga de adquisiciones, las dos arquitecturas, la configuración DNS detallada con los valores reales, la detección de un dominio detrás de Hornetsecurity, la comparativa y un plan de acción. Y no oculta las incertidumbres post-adquisición: las señalamos allí donde existen.

📌 ¿Qué es la pasarela de email de hornetsecurity?

Hornetsecurity 365 Total Protection es una suite de seguridad de email cloud construida en torno a un Secure Email Gateway: un filtro alojado que inspecciona el tráfico de email entrante antes de que alcance tu tenant Microsoft 365. En modo gateway, rediriges tus registros MX hacia la infraestructura Hornetsecurity, que analiza cada mensaje y luego transfiere únicamente el tráfico limpio hacia Exchange Online.

Para los fundamentos de un SEG (modelo gateway, redirección MX, distinción con las soluciones ICES API-native), te remitimos a nuestra guía completa sobre Barracuda, que sienta estas bases en detalle. Lo esencial cabe en una frase: un SEG se intercala entre Internet y tu servidor de correo, ve la totalidad del flujo entrante y bloquea las amenazas antes de la entrega en lugar de a posteriori.

La particularidad de Hornetsecurity reside en que la marca recubre dos enfoques técnicos sin gran cosa en común, heredados de la fusión con Vade. Por un lado, 365 Total Protection, el SEG clásico basado en la redirección MX, tema principal de este artículo. Por otro, Vade for M365, una protección API-native que se activa por journaling sin tocar los MX. Confundir los dos lleva directo al error de diagnóstico: un dominio protegido por Vade for M365 no muestra ninguna firma DNS, mientras que un dominio en 365 Total Protection se identifica a primera vista por sus MX. Desglosamos este contraste más abajo.

La suite 365 Total Protection se declina en varios planes, del filtrado básico (anti-spam, anti-malware) hasta los planes superiores, que añaden la sandbox ATP, la protección anti-suplantación, la continuidad de servicio, el archivado conforme a la legalidad y la copia de seguridad de Microsoft 365. Hornetsecurity le suma módulos transversales como el Security Awareness Service (concienciación frente al phishing) y un DMARC Manager. Todo se pilota desde un Control Panel multi-tenant, tallado para los MSP.

🕰️ La saga de adquisiciones: de vade a proofpoint

Tres operaciones en menos de dos años han fusionado a dos editores competidores y luego han pasado el conjunto bajo un gigante estadounidense. Aquí tienes la cronología, con las fechas en la mano.

Vade: el anti-phishing por IA francés, en api-native

Vade (antes Vade Secure) es un editor francés fundado en 2009 y con sede en Hem, en el área metropolitana de Lille. Su reputación se construyó sobre un motor de anti-phishing por inteligencia artificial reconocido, y sobre un modelo de distribución orientado a proveedores de acceso y MSP. En el momento de la compra, la empresa reivindicaba la protección de cerca de 1400 millones de buzones en el mundo y el análisis de varios miles de millones de mensajes al día, en gran parte mediante asociaciones con operadores.

Sobre todo, Vade aportaba un enfoque técnico distinto del SEG clásico: su producto estrella, Vade for M365, funciona en API-native sobre Microsoft 365. Sin redirección MX, sin pasarela física en el flujo: el análisis se conecta directamente al tenant mediante la API de Microsoft. Es ese saber hacer lo que Hornetsecurity, históricamente posicionado en el modelo gateway, vino a buscar.

5 de marzo de 2024: hornetsecurity compra vade

El 5 de marzo de 2024, Hornetsecurity, editor alemán con sede en Hannover, anuncia la compra de Vade. La operación se presenta como la creación de un campeón europeo de la seguridad de Microsoft 365, que combina la base MSP y la suite 365 Total Protection de Hornetsecurity con el motor de IA y la huella de operadores de Vade. Sobre el papel, las dos piezas se complementan: un SEG cloud probado por un lado, una experiencia en API y anti-phishing por el otro.

21 de febrero de 2025: «one team, one brand», vade se extingue

Menos de un año más tarde, el 21 de febrero de 2025, Hornetsecurity hace efectiva la fusión de marcas bajo el lema «One Team, one Brand». La marca Vade desaparece: logo, colores, comunicación y procesos se unifican bajo la identidad Hornetsecurity. Los productos heredados de Vade sobreviven técnicamente (Vade for M365 sigue siendo una opción de despliegue), pero el nombre comercial se borra. Por eso este artículo trata a Vade como una entidad absorbida, de la que quedan sobre todo un modelo técnico y un tráfico de búsqueda residual.

8 de diciembre de 2025: proofpoint finaliza la compra

Último acto, el 8 de diciembre de 2025: Proofpoint, actor estadounidense de referencia en seguridad de email, finaliza la compra de Hornetsecurity por unos 1800 millones de dólares. La operación valora unos ingresos recurrentes anuales (ARR) de cerca de 200 millones de dólares en fuerte crecimiento. Hornetsecurity pasa a ser una business unit dedicada a los MSP dentro de Proofpoint, cubriendo precisamente el segmento SMB y canal donde Proofpoint, históricamente volcado en el enterprise, era el menos presente. En Norteamérica, la oferta se comercializa ahora bajo el nombre Proofpoint Total Protection, con una infraestructura dedicada bajo el dominio pp-tp.com. La marca Hornetsecurity, en cambio, se mantiene en Europa, al menos mientras dure la integración.

🏢 Hornetsecurity en resumen

Hornetsecurity es un editor alemán de seguridad del cloud, fundado en 2007 y con sede en Hannover, que reivindica cerca de 125 000 clientes y más de 12 000 partners, con una fuerte concentración en el segmento pyme y el modelo MSP. Su crecimiento ha estado impulsado por adquisiciones sucesivas y por un producto estrella, 365 Total Protection, pensado para el canal.

La empresa operó durante mucho tiempo bajo el nombre Antispameurope antes de convertirse en Hornetsecurity. Su posicionamiento apenas ha variado: filtrado de email cloud, rápido de desplegar, vendido en marca blanca o en co-marca por proveedores informáticos. Allí donde algunos competidores enterprise se dirigen al cliente final único, Hornetsecurity vende al proveedor que revende. Un MSP aprovisiona a sus clientes desde un Control Panel central, hereda las políticas de una plantilla común, las afina por tenant y factura por uso. Esta mecánica multi-tenant es el corazón del atractivo de Hornetsecurity en el canal.

La presencia es netamente europea, con una fuerza comercial y unos datacenters concentrados en Europa (Alemania y Francia en particular, esta última reforzada por el aporte de Vade). Esta huella geográfica responde a un argumento recurrente del segmento: la residencia de los datos en Europa, esperada por las organizaciones sujetas al RGPD o reacias a confiar su flujo de email a una infraestructura fuera de la UE. La compra de Vade añadió una I+D anti-phishing reconocida y una huella de operadores. El paso bajo Proofpoint aporta, por su parte, el respaldo de una threat intelligence de primer nivel, cuyos efectos concretos sobre el producto quedan por observar.

⚙️ Arquitectura: dos modelos bajo un mismo techo

Es el punto angular de este artículo. Desde la absorción de Vade, Hornetsecurity propone dos formas de proteger Microsoft 365 que casi no tienen nada en común en cuanto a despliegue y DNS. Saber cuál despliegas determina toda la continuación de tu configuración.

365 total protection: el modelo gateway, redirección mx

El producto histórico de Hornetsecurity, 365 Total Protection, es un SEG clásico. Tus registros MX apuntan hacia la infraestructura cloud de Hornetsecurity. Cuando un remitente escribe a contact@captaindns.com, su servidor resuelve el MX, encuentra un host Hornetsecurity (mx01.hornetsecurity.com y sus pares) y le entrega el mensaje. Hornetsecurity aplica su cadena de inspección (reputación, anti-spam, anti-malware, sandbox ATP, anti-phishing) y luego transfiere el mensaje validado hacia Exchange Online.

La ventaja es la misma que para todo SEG: Hornetsecurity ve el 100 % del tráfico entrante y bloquea las amenazas antes de que toquen tu tenant. El reverso es un despliegue visible e intrusivo. Hay que modificar los MX, ajustar el SPF, delegar el DKIM y gestionar una conmutación sin corte. Es precisamente la operación que esta guía detalla.

Vade for M365: el api-native, sin cambio de mx

La herencia Vade introduce un modelo radicalmente distinto. Vade for M365 no se intercala en el flujo SMTP. Se activa por journaling (registro en diario) de Microsoft 365: se configura una regla de journaling que envía una copia de cada mensaje a Vade, se asocia el tenant y una cuenta O365, y el análisis se hace después de la recepción, sobre la copia. El motor aplica un aprendizaje automático conductual para detectar el spear phishing, los malwares polimórficos y las amenazas zero-day, con remediación posible de los mensajes ya entregados.

Consecuencia mayor para quien nos lee: este despliegue es invisible del lado DNS. Ningún cambio de MX, ninguna firma SPF entrante, nada que publicar en la zona. La protección vive enteramente en la relación API/journaling entre el tenant y Vade. Es cómodo: despliegue «sin corte» y ningún riesgo de pérdida de correo ligado a una mala conmutación de MX. Pero eso plantea una cuestión de auditoría, que retomamos más abajo: no se puede detectar esta protección con un simple lookup DNS.

Api-native frente a gateway/mx: lo que cambia de verdad

Tres diferencias separan realmente los dos modelos.

Visibilidad del flujo. Un SEG en modo gateway ve el mensaje antes de su entrega y puede bloquearlo en pre-recepción. Una protección API/journaling analiza una copia después de la recepción, y luego actúa en remediación (movimiento o supresión a posteriori). La ventana de exposición no es, por tanto, la misma. La gateway impide, la API rescata.

Detectabilidad DNS. La gateway deja rastros netos: MX, SPF, DKIM CNAME, autodiscover. La API no deja ningún rastro DNS entrante. Para un auditor externo, un dominio bajo Vade for M365 se parece a un dominio Microsoft 365 desnudo.

Integración y riesgo operativo. La gateway impone una conmutación de MX, con su riesgo clásico de pérdida de correo si se lleva mal, pero ofrece un control total del flujo. La API, por su parte, se despliega en unos pocos clics sin tocar el DNS, al precio de una dependencia de la API de Microsoft y de una acción ejecutada después de la entrega. Muchas organizaciones ya full M365 se decantan por la API por su simplicidad. Las que quieren interceptar antes del buzón conservan la gateway.

🔧 Configuración DNS paso a paso

Esta sección concierne al modo gateway (365 Total Protection). El despliegue modifica cuatro familias de registros: MX, SPF, DKIM y DMARC, más un eventual CNAME autodiscover. Un error en uno de ellos y tus emails desaparecen o se saltan el filtrado. Aquí tienes cada paso con los valores reales comunicados por Hornetsecurity en el onboarding, y las trampas que hay que evitar.

Los registros MX

En la región europea, Hornetsecurity hace apuntar los MX hacia cuatro hosts, con prioridades escalonadas para la redundancia:

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

El servidor más prioritario (prioridad 10) recibe el tráfico; los siguientes aseguran la conmutación en caso de indisponibilidad. Es una nomenclatura regional genérica, a diferencia de Barracuda, cuyo MX integra un identificador de cuenta único. Esta genericidad es cómoda para la detección (ver más abajo), pero implica que el enrutamiento hacia tu tenant se configura del lado del Control Panel, no mediante el hostname MX.

Punto crucial post-adquisición: en Norteamérica, la oferta se comercializa ahora bajo Proofpoint Total Protection, con una infraestructura dedicada bajo el dominio pp-tp.com (relay de envío del tipo relay01-hz14.pp-tp.com, include SPF spf.pp-tp.com). Los valores MX entrantes norteamericanos difieren por tanto de los valores europeos y se te comunican en el momento de la activación, mediante el panel de administración. No traslades mecánicamente los valores mx01.hornetsecurity.com si tu tenant está aprovisionado en la región norteamericana: confirma siempre los hosts exactos en tu Control Panel.

# Verificar los MX actuales
dig MX captaindns.com +short

La trampa del MX residual. Tras la conmutación hacia Hornetsecurity, no dejes ningún MX residual apuntando hacia tu antiguo servidor o directamente hacia tu tenant *.mail.protection.outlook.com. Un MX residual es una puerta trasera: un atacante que conoce tu infraestructura Microsoft 365 puede entregar directamente a tus buzones saltándose Hornetsecurity. Tras la conmutación, verifica con dig MX que solo quedan los MX de Hornetsecurity, y bloquea tu conector Microsoft 365 para que solo acepte el tráfico procedente de Hornetsecurity.

Un despliegue limpio prevé también un CNAME autodiscover apuntando hacia autodiscover.hornetsecurity.com, que facilita la configuración automática de los clientes de correo. No es indispensable para el filtrado, pero forma parte de la configuración tipo documentada por el editor.

El SPF con el include de hornetsecurity

Para el correo saliente retransmitido por Hornetsecurity, añades el include SPF del editor. El valor comunicado en el onboarding europeo es simple y sin variante regional aparente del lado del SPF entrante:

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

En Norteamérica (Proofpoint Total Protection), el include pasa a ser include:spf.pp-tp.com. En ambos casos, si también envías directamente desde Microsoft 365, combinas los includes:

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

Hornetsecurity documenta el ~all (softfail) en su ejemplo de onboarding, pero puedes endurecer a -all (hardfail) una vez completado tu inventario de remitentes y estabilizado tu DMARC. El -all añade una protección al nivel del propio SPF, allí donde el ~all deja pasar en caso de fallo sin bloquear. Vigila sobre todo el número total de lookups DNS: la especificación SPF (RFC 7208) impone un límite de 10 lookups recursivos. Acumula Hornetsecurity, Microsoft 365 y dos o tres ESP (Mailchimp, SendGrid, etc.), y te acercas rápido al tope, con un PermError como resultado que rompe toda la validación SPF. El verificador de sintaxis SPF de CaptainDNS cuenta estos lookups y señala los desbordamientos.

El DKIM por CNAME, el diferenciador

Es aquí donde Hornetsecurity se distingue netamente de Barracuda o Mimecast. En lugar de hacerte publicar una clave pública TXT generada en consola, Hornetsecurity opera la firma DKIM por su lado y simplemente te pide que delegues dos selectores mediante registros CNAME:

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

La consecuencia práctica es cómoda: ninguna clave TXT en tu zona, por tanto ninguna rotación de clave que gestionar manualmente por tu lado. Hornetsecurity rota sus claves detrás del CNAME, de forma transparente. Publicas los dos CNAME de una vez por todas, y luego activas la firma (y, si lo deseas, la validación DKIM entrante) en el Control Panel, bajo Email Authentication. La presencia de dos selectores (hse1 y hse2) permite precisamente la rotación del lado del editor sin intervención sobre tu DNS.

# Verificar la delegación DKIM por CNAME
dig CNAME hse1._domainkey.captaindns.com +short
# Respuesta esperada: hse1._domainkey.hornetsecurity.com.

El reverso de esta comodidad es una dependencia: tu DKIM reposa enteramente sobre la cadena CNAME hacia Hornetsecurity. Si la delegación se rompe (CNAME suprimido, zona mal editada, o problema del lado de la resolución del destino), tu firma DKIM cae, y con ella la alineación DMARC. Volvemos sobre ello en los límites.

La alineación DMARC

DMARC verifica que el dominio visible en el campo From está alineado con el dominio autenticado por SPF o DKIM, y define la política a aplicar en caso de fallo. Detrás de una pasarela, un punto merece atención: el relay saliente mediante Hornetsecurity puede reescribir el sobre SMTP, lo que hace perder la alineación SPF del lado del destinatario. Es entonces DKIM el que se convierte en el pilar de la alineación DMARC. De ahí la importancia de colocar correctamente los dos CNAME DKIM antes de endurecer la política: sin firma DKIM válida, incluso mensajes legítimos no pasarán DMARC una vez en p=reject.

La progresión recomendada es la misma que para cualquier despliegue:

1. p=none (vigilancia): recibes los informes agregados sin afectar a la entrega. Duración: de 2 a 4 semanas.
2. p=quarantine: los mensajes no autenticados van a spam. Duración: de 2 a 4 semanas.
3. p=reject: los mensajes no autenticados se rechazan. Es la política objetivo.

Ejemplo de registro DMARC de partida:

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

Hornetsecurity propone un módulo DMARC Manager que agrega y visualiza los informes, identifica las fuentes de envío legítimas todavía no autenticadas y acompaña la subida hacia p=reject. Si pilotas DMARC con otra herramienta, valida cada evolución del registro con el verificador de sintaxis DMARC de CaptainDNS.

🔍 Detectar que un dominio está protegido por hornetsecurity

Para saber si un dominio usa 365 Total Protection en modo gateway, examina sus registros DNS: un MX que termina por .hornetsecurity.com, un include spf.hornetsecurity.com, o unos CNAME hse1._domainkey / hse2._domainkey que apuntan hacia hornetsecurity.com son firmas inequívocas. Con una reserva de peso: esta detección solo funciona para el modelo gateway, no para Vade for M365 en modo API.

¿Para qué sirve? Auditar a un prospecto antes de una reunión, calificar la stack de un partner, o simplemente entender por dónde transitan tus propios emails. El método reposa sobre cuatro firmas DNS.

Firma MX. Todo MX cuyo hostname termina por .hornetsecurity.com (los hosts mx01 a mx04) indica un dominio detrás de 365 Total Protection en modo gateway.

# Detectar Hornetsecurity mediante el MX
dig MX captaindns.com +short
# Respuestas del tipo "10 mx01.hornetsecurity.com." = 365 Total Protection (gateway)

Firma SPF. La presencia de un include:spf.hornetsecurity.com (o include:spf.pp-tp.com en Norteamérica) en el registro TXT del dominio confirma que Hornetsecurity retransmite el correo saliente.

# Detectar Hornetsecurity mediante el SPF
dig TXT captaindns.com +short | grep spf
# Presencia de "include:spf.hornetsecurity.com" = relay saliente Hornetsecurity

Firmas DKIM y autodiscover. Los CNAME hse1._domainkey / hse2._domainkey hacia hornetsecurity.com, y un eventual CNAME autodiscover hacia autodiscover.hornetsecurity.com, completan el haz de indicios y confirman la delegación de firma.

# Detectar la delegación DKIM Hornetsecurity
dig CNAME hse1._domainkey.captaindns.com +short
# Respuesta "hse1._domainkey.hornetsecurity.com." = DKIM delegado a Hornetsecurity

Para un análisis completo y legible de los registros de un dominio sin manipular dig, utiliza la herramienta DNS Lookup de CaptainDNS, que muestra los MX, TXT y CNAME de un vistazo. Cruzar MX, SPF y CNAME DKIM disipa toda ambigüedad sobre el modo gateway.

El punto clave que hay que recordar: Vade for M365 es indetectable en DNS. Como se despliega por journaling de Microsoft 365 sin tocar los MX ni el SPF entrante, un dominio protegido por Vade for M365 no presenta ninguna firma DNS de Hornetsecurity. Es un límite estructural de toda auditoría externa: la ausencia de firma DNS no prueba la ausencia de protección. Para estos despliegues, solo una inspección de la configuración interna del tenant (reglas de journaling, aplicaciones conectadas) permite concluir.

🔄 Comparativa frente a proofpoint, barracuda, mimecast y microsoft

Hornetsecurity se distingue por su posicionamiento pyme y MSP europeo, ahora respaldado por Proofpoint. La tabla siguiente compara los criterios que pesan realmente en una elección. La línea «Proofpoint» hay que leerla con el matiz que impone la compra: Hornetsecurity es ahora una parte de Proofpoint, pero los dos productos conservan su posicionamiento distinto (SMB/MSP para Hornetsecurity, enterprise para el Proofpoint histórico).

Criterio	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
Público objetivo	Pymes, MSP (Europa)	Fortune 100, grandes empresas	Pymes, mid-market, MSP	Pymes/medianas multi-necesidad	Entornos M365
Detección IA	ML conductual + motor Vade anti-phishing	Nexus AI	Impersonation Protection	CyberGraph	Detección nativa
MSP multi-tenant	Sí (punto fuerte histórico)	Vía la BU Hornetsecurity	Sí (punto fuerte)	Parcial	Vía partners CSP
Modelo DNS	API (sin MX) o gateway (MX)	Gateway/MX	Gateway/MX	Gateway/MX	API/nativo (sin MX)
DMARC	DMARC Manager integrado	EFD con consultores	Domain Fraud (Premium Plus)	DMARC Analyzer integrado	No
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	Pymes/MSP Europa, doble modelo API+gateway	Threat intel de élite	SMB y MSP, simplicidad/precio	Centralizar seguridad + archivado	Full M365, presupuesto ajustado

Proofpoint, el propietario y el competidor enterprise

El caso de Proofpoint es particular, ya que, desde diciembre de 2025, Hornetsecurity le pertenece. Pero los dos productos siguen siendo distintos: el Proofpoint histórico apunta a la muy gran cuenta, con su threat intelligence de élite y su enfoque people-centric, a un coste y una complejidad que superan ampliamente las necesidades de una pyme. Hornetsecurity cubre el segmento SMB/MSP que Proofpoint atendía mal. Para un comprador, la elección no es por tanto «Hornetsecurity o Proofpoint» en abstracto, sino «qué producto de la cartera de Proofpoint corresponde a mi tamaño». Nuestra guía completa sobre Proofpoint detalla la oferta enterprise y su configuración DNS.

Barracuda, el competidor directo en el mismo segmento

En el segmento pyme y MSP, Barracuda Email Gateway Defense es el competidor más frontal de Hornetsecurity. Mismo modelo gateway/MX, mismo público objetivo, mismo argumento multi-tenant para los MSP. La diferencia se juega en los detalles: Barracuda hace publicar una clave DKIM TXT allí donde Hornetsecurity delega por CNAME, su MX integra un identificador de cuenta único, y su cobertura regional (seis regiones) difiere de la huella más bien europea de Hornetsecurity. Nuestra guía completa sobre Barracuda detalla su arquitectura y su configuración DNS para la comparación fina.

Mimecast, abnormal y microsoft defender

En la empresa mediana multi-necesidad, Mimecast propone una suite más amplia en nativo (archivado de larga duración, continuidad, DMARC Analyzer), al precio de una consola más compleja. Del lado de la detección conductual pura y API-native, Abnormal Security sobresale en el BEC y el VEC y se utiliza a menudo como complemento de un SEG en lugar de como reemplazo (consulta nuestra guía completa sobre Abnormal Security); su enfoque API recuerda además al de Vade for M365. Por último, si eres full Microsoft 365 con necesidades estándar, Defender for Office 365 sigue siendo imbatible en ratio precio/cobertura (protección nativa sin cambio de MX, a menudo incluido en licencia E5). Hornetsecurity conserva la ventaja en la independencia del producto y en el modelo MSP, pero la decisión depende de tu tamaño, de tu canal y de tu exigencia de residencia de los datos.

🖥️ Migración y despliegue

El despliegue en modo gateway se hace sin corte si se sigue el orden: inventario DNS, elección del modelo, configuración de la consola, conmutación MX, y luego autenticación y vigilancia. La secuencia siguiente detalla los cinco pasos.

Guía de despliegue en 5 pasos, del inventario DNS a la conmutación MX o la activación del journaling

1. Documenta el estado actual de tus registros MX, SPF, DKIM y DMARC con las herramientas de CaptainDNS. Enumera sobre todo todas las fuentes de envío legítimas de tu dominio: Microsoft 365, marketing (Mailchimp, HubSpot), transaccional (SendGrid, Mailgun), CRM, ticketing. Cada una deberá ser autenticada en tu nueva configuración SPF y tenida en cuenta en la roadmap DMARC, manteniéndote por debajo del límite de 10 lookups.

2. Decide entre los dos enfoques. El modo gateway (365 Total Protection) intercepta antes del buzón, ve el 100 % del flujo entrante, pero impone una conmutación MX y una configuración DNS completa. El modo API (Vade for M365) se despliega por journaling sin tocar el DNS, analiza una copia después de la recepción y remedia a posteriori. La elección depende de tu tolerancia al riesgo, de tu exigencia de interceptación en pre-entrega y de tu comodidad con una conmutación MX.

3. En el Control Panel de Hornetsecurity (o Proofpoint Total Protection en Norteamérica), añade tu dominio, verifica su propiedad y sincroniza el directorio de usuarios. Recupera los valores DNS exactos comunicados en el onboarding para tu región (MX, include SPF, CNAME DKIM, autodiscover): difieren entre Europa (hornetsecurity.com) y Norteamérica (pp-tp.com). En modo API, configura más bien la regla de journaling y la asociación del tenant.

4. En modo gateway, publica los MX mx01 a mx04.hornetsecurity.com (prioridades 10/20/30/40) fuera de las horas punta, suprime todos los antiguos MX y bloquea tu conector Microsoft 365 para que solo acepte el tráfico de Hornetsecurity (cierre de la puerta trasera del MX residual). En modo API, activa la regla de journaling M365 y verifica que las copias llegan bien a Vade. Verifica el resultado con dig MX captaindns.com +short.

5. Añade el include SPF de Hornetsecurity manteniéndote por debajo de los 10 lookups. Publica los dos CNAME DKIM (hse1 y hse2._domainkey) y activa la firma en el Control Panel. Despliega DMARC en p=none, vigila los informes de 2 a 4 semanas, y luego sube hacia p=quarantine y p=reject. Valida cada registro con los verificadores de CaptainDNS.

⚠️ Límites y puntos de vigilancia

Hornetsecurity es sólido en su segmento, pero algunos puntos merecen una vigilancia honesta, sobre todo en el contexto post-adquisición.

Incertidumbre post-adquisición Proofpoint. La compra es reciente (diciembre de 2025) y la integración está por desplegarse. Hoja de ruta del producto, mantenimiento de los dos modelos (gateway y Vade for M365), eventual convergencia con las piezas de Proofpoint, evolución tarifaria, futuro de la marca Hornetsecurity en Europa: otras tantas incógnitas en este momento. Nadie puede garantizar hoy la estabilidad del conjunto, y más vale saberlo. Para un compromiso plurianual, plantea estas preguntas explícitamente al editor y haz inscribir las garantías en el contrato.

Cobertura regional y cambio de marca. La huella es netamente europea. En Norteamérica, la oferta pasa bajo Proofpoint Total Protection con una infraestructura distinta (pp-tp.com), lo que cambia los valores DNS y puede complicar un despliegue multi-región bajo una marca única. Verifica que tu exigencia de residencia de los datos corresponde bien a una región disponible.

Falsos positivos y cuarentena. Como todo SEG, Hornetsecurity puede poner en cuarentena a remitentes legítimos, sobre todo en las primeras semanas. Prevé una fase de ajuste: vigilancia activa de la cuarentena, listas de autorización, ajuste de las políticas. Es un trabajo de explotación clásico, pero real, que no hay que subestimar al arranque.

Dependencia de la cadena CNAME DKIM. La comodidad del DKIM por CNAME tiene un coste: tu firma depende enteramente de la delegación hacia hornetsecurity.com. Una supresión accidental de un CNAME, una zona mal editada o un problema del lado del destino, y tu DKIM cae, lo que acarrea fallos DMARC sobre correo legítimo. Vigila la resolución de estos CNAME como vigilarías una clave TXT, y documéntalos para evitar que una «purga» del DNS se los lleve.

📋 Plan de acción recomendado

De la auditoría inicial a la política DMARC estricta, aquí tienes la secuencia completa para evaluar y luego desplegar Hornetsecurity.

1. Auditar tu postura de email actual (MX, SPF, DKIM, DMARC) con las herramientas de CaptainDNS.
2. Clarificar la identidad del producto: evalúas Hornetsecurity 365 Total Protection (o Vade for M365), ahora propiedad de Proofpoint, y no la oferta enterprise del Proofpoint histórico.
3. Elegir el modelo: gateway (365 Total Protection, MX) para interceptar antes del buzón, o API (Vade for M365, journaling) para un despliegue sin cambio de DNS.
4. Comparar con Barracuda (competidor directo pyme/MSP), Mimecast, Abnormal y Microsoft Defender según tu tamaño, tu canal y tu exigencia de residencia de los datos.
5. Identificar tu región (Europa hornetsecurity.com frente a Norteamérica pp-tp.com), que condiciona los valores DNS exactos.
6. Configurar la consola (Control Panel), añadir el dominio, verificar la propiedad y sincronizar el directorio.
7. Conmutar los MX (mx01 a mx04, prioridades 10/20/30/40) fuera de las horas punta y suprimir todos los antiguos MX, o activar el journaling en modo API.
8. Bloquear el conector Microsoft 365 para que solo acepte el tráfico de Hornetsecurity y cerrar la puerta trasera del MX residual.
9. Implementar SPF (include, por debajo de 10 lookups), DKIM (dos CNAME hse1/hse2) y DMARC (p=none y luego endurecimiento), vigilando la cadena CNAME DKIM.
10. Vigilar la cuarentena y los informes DMARC, y luego subir hacia p=reject tras 4 a 8 semanas de vigilancia limpia.

📚 Guías de pasarelas de email

Este análisis forma parte de nuestra serie sobre las soluciones de seguridad de email enterprise:

• Mimecast Secure Email Gateway: funcionamiento, configuración DNS, comparativa y plan de acción
• Proofpoint Secure Email Gateway: Nexus AI, TAP, configuración DNS y el nuevo propietario de Hornetsecurity
• Cisco Secure Email Cloud Gateway (CES): arquitectura SaaS, DNS iphmx.com y migración desde el ESA
• Abnormal Security: IA conductual y despliegue API, comparable al modelo Vade for M365
• Cloudflare Email Service: Email Routing, Security y DMARC Management explicados
• Barracuda Email Gateway Defense: competidor directo en el segmento pyme/MSP, arquitectura y configuración DNS
• Hornetsecurity Secure Email Gateway: 365 Total Protection, ex-Vade, ahora Proofpoint (este artículo)

FAQ

¿Qué es Hornetsecurity 365 Total Protection?

Hornetsecurity 365 Total Protection es una suite de seguridad de email cloud construida en torno a un Secure Email Gateway. En modo gateway, rediriges tus registros MX hacia la infraestructura Hornetsecurity (mx01.hornetsecurity.com a mx04), que inspecciona cada mensaje entrante (reputación, anti-spam, anti-malware, sandbox ATP, anti-phishing) y luego transfiere el tráfico limpio hacia Microsoft 365. La suite añade, según los planes, la continuidad, el archivado, la copia de seguridad de M365, un DMARC Manager y un servicio de concienciación. Está históricamente orientada a pymes y MSP, con cerca de 125 000 clientes en el mundo.

¿Qué ocurre con Vade tras la compra por Hornetsecurity?

Vade, editor francés de anti-phishing por IA (Hem, cerca de Lille), fue comprado por Hornetsecurity el 5 de marzo de 2024. Su marca se extinguió después el 21 de febrero de 2025 durante el rebranding «One Team, one Brand», en favor de la identidad Hornetsecurity. Técnicamente, el producto Vade for M365 sobrevive como opción de despliegue API-native, pero el nombre comercial Vade ya no existe. Tratamos por tanto a Vade como una entidad absorbida, de la que quedan sobre todo un modelo técnico distinto (API/journaling) y un saber hacer anti-phishing.

¿Hornetsecurity pertenece a Proofpoint?

Sí. Proofpoint finalizó la compra de Hornetsecurity el 8 de diciembre de 2025, por unos 1800 millones de dólares. Hornetsecurity pasa a ser la business unit dedicada a los MSP dentro de Proofpoint, cubriendo el segmento SMB y canal donde Proofpoint, volcado en el enterprise, era el menos presente. En Norteamérica, la oferta se comercializa ahora bajo el nombre Proofpoint Total Protection, con una infraestructura dedicada bajo el dominio pp-tp.com. La marca Hornetsecurity se mantiene en Europa, al menos mientras dure la integración.

¿Cuáles son los registros MX de Hornetsecurity?

En la región europea, Hornetsecurity hace apuntar los MX hacia cuatro hosts con prioridades escalonadas: mx01.hornetsecurity.com (prioridad 10), mx02.hornetsecurity.com (20), mx03.hornetsecurity.com (30) y mx04.hornetsecurity.com (40). En Norteamérica, bajo la marca Proofpoint Total Protection, la infraestructura pasa por el dominio pp-tp.com y los valores exactos se te comunican en el momento de la activación, mediante el Control Panel. Confirma siempre los hosts exactos en tu panel de administración según tu región.

¿Qué include SPF usar con Hornetsecurity?

En Europa, el include SPF es include:spf.hornetsecurity.com, a colocar antes del mecanismo final (~all en el ejemplo de onboarding, o -all si endureces tras un inventario completo de tus remitentes). En Norteamérica (Proofpoint Total Protection), el include pasa a ser include:spf.pp-tp.com. Vigila el número total de lookups DNS para mantenerte por debajo del límite de 10 impuesto por la RFC 7208, sobre todo si acumulas Microsoft 365 y varios ESP.

¿Cómo configurar DKIM con Hornetsecurity (CNAME)?

Hornetsecurity opera la firma DKIM por su lado y te pide que delegues dos selectores mediante CNAME: hse1._domainkey.<tu-dominio> hacia hse1._domainkey.hornetsecurity.com, y hse2._domainkey.<tu-dominio> hacia hse2._domainkey.hornetsecurity.com. A diferencia de Barracuda o Mimecast, no publicas ninguna clave TXT en tu zona: la rotación de las claves se hace del lado de Hornetsecurity, detrás del CNAME. Una vez publicados los dos CNAME, activa la firma (y eventualmente la validación entrante) en el Control Panel, bajo Email Authentication.

¿Qué diferencia hay entre el enfoque gateway (MX) y el enfoque API de Vade?

El modo gateway (365 Total Protection) redirige tus MX hacia Hornetsecurity, que filtra el 100 % del flujo entrante antes de la entrega; es visible en DNS (MX, SPF, CNAME DKIM). El modo API (Vade for M365) se despliega por journaling de Microsoft 365 sin cambio de MX, analiza una copia después de la recepción y remedia a posteriori; es invisible en DNS. La gateway impide en pre-entrega pero impone una conmutación MX; la API rescata en post-entrega pero se despliega sin tocar el DNS. La elección depende de tu necesidad de interceptación y de tu tolerancia a una conmutación MX.

¿Cómo detectar que un dominio está protegido por Hornetsecurity?

Para el modo gateway, cuatro firmas DNS lo identifican: un MX que termina por .hornetsecurity.com (mx01 a mx04), un include:spf.hornetsecurity.com en el TXT, unos CNAME hse1._domainkey / hse2._domainkey hacia hornetsecurity.com, y un eventual CNAME autodiscover. Cruzar estas firmas disipa toda ambigüedad. Atención, eso sí: el modo API (Vade for M365) es indetectable en DNS, ya que se despliega por journaling sin tocar los MX. La ausencia de firma DNS no prueba por tanto la ausencia de protección. La herramienta DNS Lookup de CaptainDNS muestra estos registros de forma legible.

¿Hornetsecurity funciona con Microsoft 365 y Google Workspace?

Hornetsecurity está concebido ante todo para Microsoft 365, donde se aplican los dos modelos: la gateway (redirección MX hacia Hornetsecurity y luego transferencia hacia Exchange Online) y la API/journaling (Vade for M365), esta última ligada nativamente a M365. El modo gateway, basado en la redirección MX, sigue siendo en teoría independiente del servidor de destino y puede proteger otros entornos mediante redirección MX, pero el ecosistema, el DMARC Manager y Vade for M365 están tallados para M365. Para Google Workspace o un despliegue híbrido, confirma la compatibilidad exacta y el modo soportado con el editor.

¿Hornetsecurity es adecuado para las pymes y los MSP?

Sí, es su posicionamiento predilecto. La suite está concebida para ser simple de desplegar y de operar sin equipo SOC dedicado, y su Control Panel multi-tenant permite a un MSP aprovisionar, configurar y supervisar la seguridad de email de decenas de clientes desde una consola central, con facturación por uso. Es uno de los programas MSP más logrados de Europa, lo que explica además el interés de Proofpoint, que lo ha convertido en su business unit MSP mundial tras la compra de diciembre de 2025.

Descarga las tablas comparativas

Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.

• Descargar la comparativa (CSV)
• Descargar la comparativa (JSON)

Glosario

• SEG (Secure Email Gateway): pasarela de seguridad de email que filtra el tráfico entrante (y a veces saliente) entre Internet y el servidor de correo, analizando cada mensaje (spam, malware, phishing) antes de transmitirlo al destinatario.

• 365 Total Protection: la suite de seguridad de email cloud de Hornetsecurity, articulada en torno a un SEG en modo gateway (redirección MX) para proteger Microsoft 365. Tema principal de este artículo.

• Vade for M365: producto heredado del editor Vade, protección de email API-native que se activa por journaling de Microsoft 365, sin cambio de MX. Analiza una copia de los mensajes después de la recepción, con remediación a posteriori.

• MX (Mail Exchanger): registro DNS que indica los servidores responsables de la recepción de los emails de un dominio. Desplegar 365 Total Protection en gateway implica redirigir los MX hacia mx01.hornetsecurity.com a mx04.

• SPF (Sender Policy Framework): protocolo de autenticación que lista los servidores autorizados a enviar emails para un dominio. Registro TXT limitado a 10 lookups recursivos (RFC 7208). Hornetsecurity usa include:spf.hornetsecurity.com (o spf.pp-tp.com en Norteamérica).

• DKIM por CNAME: método en el que el cliente no publica una clave pública TXT sino que delega la firma mediante registros CNAME (hse1._domainkey, hse2._domainkey hacia hornetsecurity.com). La rotación de las claves se hace del lado del editor, de forma transparente. Es el diferenciador de Hornetsecurity frente a Barracuda o Mimecast.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): protocolo que verifica la alineación entre el dominio From y los dominios autenticados por SPF o DKIM, y define la política a aplicar en caso de fallo (none, quarantine, reject).

• Journaling (registro en diario): funcionalidad de Microsoft 365 que envía una copia de los mensajes a un destino de terceros. Es el mecanismo de despliegue de Vade for M365, que hace la protección invisible del lado DNS.

• MSP (Managed Service Provider): proveedor que gestiona la infraestructura IT de varios clientes. El Control Panel multi-tenant de Hornetsecurity está pensado para este modelo, que es su corazón de mercado.

• BEC (Business Email Compromise): fraude por email en el que el atacante se hace pasar por un directivo o un partner de confianza para obtener una transferencia o datos sensibles. A menudo sin enlace ni archivo adjunto, por tanto invisible para los filtros por firma, de ahí el interés de la detección conductual.

• API-native frente a gateway: dos modelos de protección de email. La gateway se intercala en el flujo SMTP mediante redirección MX y bloquea antes de la entrega; la API-native se conecta al tenant (journaling o API), analiza después de la recepción y remedia a posteriori, sin tocar el DNS.

Fuentes

• Proofpoint Newsroom: Proofpoint Completes Acquisition of Hornetsecurity (1800 M$, 8 de diciembre 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 (suite y planes)
• Proofpoint: Launches Dedicated MSP Business Unit and Introduces 365 Total Protection for North America