Hornetsecurity Secure Email Gateway (ex-Vade): architettura, configurazione DNS e alternative

⚡TL;DR

• 🛡️ Hornetsecurity 365 Total Protection è un Secure Email Gateway cloud orientato alle PMI e agli MSP, con circa 125.000 clienti e oltre 12.000 partner. Si frappone davanti a Microsoft 365 tramite redirezione MX e filtra il traffico in entrata.
• 🔁 Il marchio Vade è scomparso. Il vendor francese Vade (anti-phishing IA) è stato acquisito da Hornetsecurity nel marzo 2024, poi il suo marchio è stato spento nel febbraio 2025 durante il rebranding «One Team, one Brand». Trattiamo quindi Vade come un'entità assorbita.
• 🔧 Impatto DNS specifico: MX verso mx01.hornetsecurity.com fino a mx04 (priorità 10/20/30/40), include spf.hornetsecurity.com, e soprattutto un DKIM tramite CNAME (hse1._domainkey / hse2._domainkey). Nessuna chiave TXT da pubblicare nella tua zona, a differenza di Barracuda o Mimecast.
• 📊 Nuovo proprietario da dicembre 2025: Proofpoint ha finalizzato l'acquisizione di Hornetsecurity per 1,8 miliardi di dollari, che diventa la sua business unit dedicata agli MSP. In Nord America, l'offerta è ora commercializzata sotto il nome Proofpoint Total Protection (pp-tp.com).

Se gestisci la posta di una PMI, di uno studio professionale o di un parco di clienti come MSP, hai probabilmente già incrociato Hornetsecurity, o il suo vecchio concorrente diventato filiale, Vade. Il vendor tedesco rivendica circa 125.000 clienti e oltre 12.000 partner su una nicchia che ha occupato con pazienza: la sicurezza Microsoft 365 venduta da e per i fornitori di servizi informatici. Là dove Proofpoint dominava storicamente le grandi aziende e Barracuda le PMI americane, Hornetsecurity si è ritagliato un posto di riferimento europeo sul modello MSP multi-tenant.

Ma analizzare Hornetsecurity nel 2026 significa innanzitutto districare una tripla identità che genera confusione. C'è Hornetsecurity, il vendor di Hannover dietro la suite 365 Total Protection. C'è Vade, il vendor francese di Hem (vicino a Lille), assorbito nel 2024 e il cui marchio ufficialmente non esiste più dal febbraio 2025. E c'è Proofpoint, che ha acquisito l'insieme a fine 2025. Tre nomi, una sola realtà capitalistica oggi. Ma due modelli tecnici ben distinti continuano a coesistere, ed è lì che si gioca tutto sul fronte DNS.

La posta in gioco non ha nulla di astratto. L'Hornetsecurity secure email gateway, ossia un gateway di posta sicura (in inglese secure email gateway, o SEG), non serve a nulla se il tuo dominio resta vulnerabile all'usurpazione per mancanza di autenticazione corretta. Filtrare il flusso in entrata protegge le tue caselle. Non protegge il tuo marchio dall'usurpazione in uscita. Prima ancora di distribuire Hornetsecurity, verifica a che punto sei con il verificatore di sintassi DMARC CaptainDNS: è lui a dirti se un aggressore può inviare email a tuo nome.

In CaptainDNS, guardiamo Hornetsecurity sotto l'angolo che ci riguarda: l'impatto concreto sui tuoi record DNS e sulla tua autenticazione email. Distribuire 365 Total Protection in modalità gateway significa reindirizzare i tuoi MX verso mx01.hornetsecurity.com, aggiungere l'include spf.hornetsecurity.com e delegare il tuo DKIM tramite CNAME. Distribuire Vade for M365 in modalità API, al contrario, non tocca alcun record DNS. Questa guida copre la saga delle acquisizioni, le due architetture, la configurazione DNS dettagliata con i valori reali, il rilevamento di un dominio dietro Hornetsecurity, il confronto e un piano d'azione. E non nasconde le incertezze del post-acquisizione: le segnaliamo dove esistono.

📌 Cos'è il secure email gateway di hornetsecurity?

Hornetsecurity 365 Total Protection è una suite di sicurezza email cloud costruita attorno a un Secure Email Gateway: un filtro ospitato che ispeziona il traffico email in entrata prima che raggiunga il tuo tenant Microsoft 365. In modalità gateway, reindirizzi i tuoi record MX verso l'infrastruttura Hornetsecurity, che analizza ogni messaggio poi trasferisce unicamente il traffico pulito verso Exchange Online.

Per i fondamentali di un SEG (modello gateway, redirezione MX, distinzione con le soluzioni ICES API-native), rimandiamo alla nostra guida completa su Barracuda, che pone queste basi in dettaglio. L'essenziale sta in una frase: un SEG si frappone tra Internet e la tua posta, vede l'integralità del flusso in entrata e blocca le minacce prima della consegna invece che a posteriori.

La particolarità di Hornetsecurity sta nel fatto che il marchio ricopre due approcci tecnici senza granché in comune, ereditati dalla fusione con Vade. Da un lato, 365 Total Protection, il SEG classico fondato sulla redirezione MX, oggetto principale di questo articolo. Dall'altro, Vade for M365, una protezione API-native che si attiva tramite journaling senza toccare gli MX. Confondere i due porta dritti all'errore diagnostico: un dominio protetto da Vade for M365 non mostra alcuna signature DNS, mentre un dominio in 365 Total Protection si identifica al primo colpo d'occhio dai suoi MX. Approfondiamo questo contrasto più avanti.

La suite 365 Total Protection si declina in più piani, dal filtraggio di base (anti-spam, anti-malware) fino ai piani superiori che aggiungono la sandbox ATP, la protezione anti-usurpazione, la continuità di servizio, l'archiviazione legalmente conforme e il backup Microsoft 365. Hornetsecurity vi affianca moduli trasversali come il Security Awareness Service (sensibilizzazione al phishing) e un DMARC Manager. Tutto si pilota da un Control Panel multi-tenant, tagliato per gli MSP.

🕰️ La saga delle acquisizioni: da vade a proofpoint

Tre operazioni in meno di due anni hanno fuso due vendor concorrenti, poi fatto passare l'insieme sotto un gigante americano. Ecco la cronologia, date alla mano.

Vade: l'anti-phishing IA francese, in api-native

Vade (precedentemente Vade Secure) è un vendor francese fondato nel 2009 e con sede a Hem, nell'area metropolitana di Lille. La sua reputazione si è costruita su un motore di anti-phishing tramite intelligenza artificiale riconosciuto, e su un modello di distribuzione orientato ai provider di accesso e agli MSP. Al momento dell'acquisizione, l'azienda rivendicava la protezione di circa 1,4 miliardi di caselle nel mondo e l'analisi di diversi miliardi di messaggi al giorno, in gran parte tramite partnership con operatori.

Soprattutto, Vade portava un approccio tecnico distinto da quello del SEG classico: il suo prodotto di punta, Vade for M365, funziona in API-native su Microsoft 365. Nessuna redirezione MX, nessun gateway fisico nel flusso: l'analisi si collega direttamente al tenant tramite l'API Microsoft. È questo know-how che Hornetsecurity, storicamente posizionato sul modello gateway, è venuto a cercare.

5 marzo 2024: hornetsecurity acquisisce vade

Il 5 marzo 2024, Hornetsecurity, vendor tedesco con sede a Hannover, annuncia l'acquisizione di Vade. L'operazione è presentata come la creazione di un campione europeo della sicurezza Microsoft 365, che combina la base MSP e la suite 365 Total Protection di Hornetsecurity con il motore di IA e l'impronta operatore di Vade. Sulla carta, i due mattoni si completano: un SEG cloud collaudato da un lato, un'expertise API e anti-phishing dall'altro.

21 febbraio 2025: «one team, one brand», vade si spegne

Meno di un anno dopo, il 21 febbraio 2025, Hornetsecurity sancisce la fusione dei marchi sotto il motto «One Team, one Brand». Il marchio Vade scompare: logo, colori, comunicazione e processi vengono unificati sotto l'identità Hornetsecurity. I prodotti ereditati da Vade sopravvivono tecnicamente (Vade for M365 resta un'opzione di deployment), ma il nome commerciale si cancella. Ecco perché questo articolo tratta Vade come un'entità assorbita, di cui restano soprattutto un modello tecnico e un traffico di ricerca residuo.

8 dicembre 2025: proofpoint finalizza l'acquisizione

Ultimo atto, l'8 dicembre 2025: Proofpoint, attore americano di riferimento della sicurezza email, finalizza l'acquisizione di Hornetsecurity per circa 1,8 miliardi di dollari. L'operazione valorizza un ricavo ricorrente annuale (ARR) di circa 200 milioni di dollari in forte crescita. Hornetsecurity diventa una business unit dedicata agli MSP all'interno di Proofpoint, colmando precisamente il segmento SMB e canale dove Proofpoint, storicamente orientato all'enterprise, era meno presente. In Nord America, l'offerta è ora commercializzata sotto il nome Proofpoint Total Protection, con un'infrastruttura dedicata sotto il dominio pp-tp.com. Il marchio Hornetsecurity resta invece in vigore in Europa, almeno per il tempo dell'integrazione.

🏢 Hornetsecurity in breve

Hornetsecurity è un vendor tedesco di sicurezza del cloud, fondato nel 2007 e con sede a Hannover, che rivendica circa 125.000 clienti e oltre 12.000 partner, con una forte concentrazione sul segmento PMI e sul modello MSP. La sua crescita è stata trainata da acquisizioni successive e da un prodotto di punta, 365 Total Protection, pensato per il canale.

L'azienda ha operato a lungo sotto il nome Antispameurope prima di diventare Hornetsecurity. Il suo posizionamento non è cambiato granché: filtraggio email cloud, rapido da distribuire, venduto in marchio bianco o in co-branding dai fornitori di servizi informatici. Là dove certi concorrenti enterprise si rivolgono al singolo cliente finale, Hornetsecurity vende al fornitore che rivende. Un MSP provisiona i suoi clienti da un Control Panel centrale, eredita le policy di un modello comune, le affina per tenant, e fattura a consumo. Questa meccanica multi-tenant è il cuore dell'attrattività di Hornetsecurity sul canale.

La presenza è nettamente europea, con una forza commerciale e datacenter concentrati in Europa (Germania e Francia in particolare, quest'ultima rafforzata dall'apporto di Vade). Questa impronta geografica risponde a un argomento ricorrente del segmento: la residenza dei dati in Europa, attesa dalle organizzazioni soggette al GDPR o riluttanti ad affidare il proprio flusso email a un'infrastruttura fuori dall'UE. L'acquisizione di Vade ha aggiunto una R&S anti-phishing riconosciuta e un'impronta operatore. Il passaggio sotto Proofpoint apporta, dal canto suo, l'appoggio a una threat intelligence di primo piano, i cui effetti concreti sul prodotto restano da osservare.

⚙️ Architettura: due modelli sotto uno stesso tetto

È il punto cardine di questo articolo. Dall'assorbimento di Vade, Hornetsecurity propone due modi di proteggere Microsoft 365 che non hanno quasi nulla in comune sul fronte del deployment e del DNS. Sapere quale stai distribuendo determina tutto il resto della tua configurazione.

365 total protection: il modello gateway, redirezione mx

Il prodotto storico di Hornetsecurity, 365 Total Protection, è un SEG classico. I tuoi record MX puntano all'infrastruttura cloud Hornetsecurity. Quando un mittente scrive a contact@captaindns.com, il suo server risolve l'MX, trova un host Hornetsecurity (mx01.hornetsecurity.com e i suoi pari), e vi consegna il messaggio. Hornetsecurity applica la sua catena di ispezione (reputazione, anti-spam, anti-malware, sandbox ATP, anti-phishing), poi trasferisce il messaggio convalidato verso Exchange Online.

Il vantaggio è lo stesso di qualsiasi SEG: Hornetsecurity vede il 100% del traffico in entrata e blocca le minacce prima che tocchino il tuo tenant. Il rovescio è un deployment visibile e intrusivo. Bisogna modificare gli MX, regolare l'SPF, delegare il DKIM e gestire una commutazione senza interruzioni. È precisamente l'operazione che questa guida dettaglia.

Vade for M365: l'api-native, senza cambio di mx

L'eredità Vade introduce un modello radicalmente diverso. Vade for M365 non si frappone nel flusso SMTP. Si attiva tramite journaling Microsoft 365: si configura una regola di journaling che invia una copia di ogni messaggio a Vade, si associa il tenant e un account O365, e l'analisi avviene dopo la ricezione, sulla copia. Il motore applica un apprendimento automatico comportamentale per rilevare lo spear phishing, i malware polimorfi e le minacce zero-day, con remediation possibile dei messaggi già consegnati.

Conseguenza maggiore per chi ci legge: questo deployment è invisibile sul fronte DNS. Nessun cambio di MX, nessuna signature SPF in entrata, niente da pubblicare nella zona. La protezione vive interamente nella relazione API/journaling tra il tenant e Vade. È comodo: deployment «senza interruzioni», e nessun rischio di perdita di posta legato a una commutazione MX mal riuscita. Ma questo solleva una questione di audit, che riprendiamo più avanti: non si può rilevare questa protezione con un semplice lookup DNS.

Api-native contro gateway/mx: cosa cambia davvero

Tre differenze separano realmente i due modelli.

Visibilità del flusso. Un SEG in modalità gateway vede il messaggio prima della sua consegna e può bloccarlo in pre-ricezione. Una protezione API/journaling analizza una copia dopo la ricezione, poi agisce in remediation (spostamento o eliminazione a posteriori). La finestra di esposizione non è quindi la stessa. Il gateway impedisce, l'API recupera.

Rilevabilità DNS. Il gateway lascia tracce nette: MX, SPF, DKIM CNAME, autodiscover. L'API non lascia alcuna traccia DNS in entrata. Per un auditor esterno, un dominio sotto Vade for M365 assomiglia a un dominio Microsoft 365 nudo.

Integrazione e rischio operativo. Il gateway impone una commutazione MX, con il suo rischio classico di perdita di posta se mal condotta, ma offre un controllo totale del flusso. L'API, dal canto suo, si distribuisce in pochi clic senza toccare il DNS, al prezzo di una dipendenza dall'API Microsoft e di un'azione condotta dopo la consegna. Molte organizzazioni già full M365 vanno verso l'API per la sua semplicità. Quelle che vogliono intercettare prima della casella conservano il gateway.

🔧 Configurazione DNS passo dopo passo

Questa sezione riguarda la modalità gateway (365 Total Protection). Il deployment modifica quattro famiglie di record: MX, SPF, DKIM e DMARC, più un eventuale CNAME autodiscover. Un errore su uno di essi, e le tue email spariscono o aggirano il filtraggio. Ecco ogni tappa con i valori reali comunicati da Hornetsecurity all'onboarding, e le trappole da evitare.

I record MX

Nella regione europea, Hornetsecurity fa puntare gli MX verso quattro host, con priorità scaglionate per la ridondanza:

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

Il server più prioritario (priorità 10) riceve il traffico; i successivi assicurano la commutazione in caso di indisponibilità. È una nomenclatura regionale generica, a differenza di Barracuda il cui MX integra un identificativo di account unico. Questa genericità è comoda per il rilevamento (vedi più avanti), ma implica che il routing verso il tuo tenant si configura lato Control Panel, non tramite l'hostname MX.

Punto cruciale post-acquisizione: in Nord America, l'offerta è ora commercializzata sotto Proofpoint Total Protection, con un'infrastruttura dedicata sotto il dominio pp-tp.com (relay di invio del tipo relay01-hz14.pp-tp.com, include SPF spf.pp-tp.com). I valori MX in entrata nordamericani differiscono quindi dai valori europei e ti vengono comunicati al momento dell'attivazione, tramite il pannello di amministrazione. Non riportare meccanicamente i valori mx01.hornetsecurity.com se il tuo tenant è provisionato nella regione nordamericana: conferma sempre gli host esatti nel tuo Control Panel.

# Verificare gli MX attuali
dig MX captaindns.com +short

La trappola dell'MX residuo. Dopo la commutazione verso Hornetsecurity, non lasciare alcun MX residuo che punti al tuo vecchio server o direttamente al tuo tenant *.mail.protection.outlook.com. Un MX residuo è una backdoor: un aggressore che conosce la tua infrastruttura Microsoft 365 può consegnare direttamente alle tue caselle aggirando Hornetsecurity. Dopo la commutazione, verifica con dig MX che restino solo gli MX Hornetsecurity, e blocca il tuo connettore Microsoft 365 affinché accetti solo il traffico proveniente da Hornetsecurity.

Un deployment pulito prevede anche un CNAME autodiscover che punta verso autodiscover.hornetsecurity.com, che facilita la configurazione automatica dei client di posta. Non è indispensabile al filtraggio, ma fa parte della configurazione tipo documentata dal vendor.

L'SPF con l'include hornetsecurity

Per la posta in uscita veicolata da Hornetsecurity, aggiungi l'include SPF del vendor. Il valore comunicato all'onboarding europeo è semplice e senza variante regionale apparente sul fronte dell'SPF in entrata:

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

In Nord America (Proofpoint Total Protection), l'include diventa include:spf.pp-tp.com. In entrambi i casi, se invii anche da Microsoft 365 direttamente, combini gli include:

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

Hornetsecurity documenta il ~all (softfail) nel suo esempio di onboarding, ma puoi irrigidire in -all (hardfail) una volta completato l'inventario dei tuoi mittenti e stabilizzato il tuo DMARC. Il -all aggiunge una protezione a livello dell'SPF stesso, là dove il ~all lascia passare in caso di fallimento senza bloccare. Sorveglia soprattutto il numero totale di lookup DNS: la specifica SPF (RFC 7208) impone un limite di 10 lookup ricorsivi. Cumula Hornetsecurity, Microsoft 365 e due o tre ESP (Mailchimp, SendGrid, ecc.), e ti avvicini rapidamente al tetto, con un PermError come conseguenza che rompe tutta la validazione SPF. Il verificatore di sintassi SPF CaptainDNS conteggia questi lookup e segnala i superamenti.

Il DKIM tramite CNAME, il fattore differenziante

È qui che Hornetsecurity si distingue nettamente da Barracuda o Mimecast. Invece di farti pubblicare una chiave pubblica TXT generata in console, Hornetsecurity opera la firma DKIM dal suo lato e ti chiede semplicemente di delegare due selettori tramite record CNAME:

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

La conseguenza pratica è comoda: nessuna chiave TXT nella tua zona, quindi nessuna rotazione di chiave da gestire manualmente dal tuo lato. Hornetsecurity ruota le sue chiavi dietro il CNAME, in modo trasparente. Pubblichi i due CNAME una volta per tutte, poi attivi la firma (e, se desiderato, la validazione DKIM in entrata) nel Control Panel, sotto Email Authentication. La presenza di due selettori (hse1 e hse2) permette proprio la rotazione lato vendor senza intervento sul tuo DNS.

# Verificare la delega DKIM tramite CNAME
dig CNAME hse1._domainkey.captaindns.com +short
# Risposta attesa: hse1._domainkey.hornetsecurity.com.

Il rovescio di questa comodità è una dipendenza: il tuo DKIM si appoggia interamente sulla catena CNAME verso Hornetsecurity. Se la delega si rompe (CNAME eliminato, zona mal modificata, o problema lato risoluzione del target), la tua firma DKIM cade, e con essa l'allineamento DMARC. Ci torniamo nei limiti.

L'allineamento DMARC

DMARC verifica che il dominio visibile nel campo From sia allineato con il dominio autenticato da SPF o DKIM, e definisce la policy da applicare in caso di fallimento. Dietro un gateway, un punto merita attenzione: il relay in uscita tramite Hornetsecurity può riscrivere l'envelope SMTP, il che fa perdere l'allineamento SPF lato destinatario. È allora DKIM a diventare il pilastro dell'allineamento DMARC. Da qui l'importanza di impostare correttamente i due CNAME DKIM prima di irrigidire la policy: senza firma DKIM valida, messaggi pur legittimi falliranno a DMARC una volta in p=reject.

La progressione raccomandata è la stessa di qualsiasi deployment:

1. p=none (sorveglianza): ricevi i report aggregati senza intaccare la consegna. Durata: da 2 a 4 settimane.
2. p=quarantine: i messaggi non autenticati partono in spam. Durata: da 2 a 4 settimane.
3. p=reject: i messaggi non autenticati sono rifiutati. È la policy obiettivo.

Esempio di record DMARC di partenza:

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

Hornetsecurity propone un modulo DMARC Manager che aggrega e visualizza i report, identifica le sorgenti di invio legittime non ancora autenticate e accompagna la salita verso p=reject. Se piloti DMARC con un altro strumento, convalida ogni evoluzione del record con il verificatore di sintassi DMARC CaptainDNS.

🔍 Rilevare che un dominio è protetto da hornetsecurity

Per sapere se un dominio utilizza 365 Total Protection in modalità gateway, esamina i suoi record DNS: un MX che termina con .hornetsecurity.com, un include spf.hornetsecurity.com, o dei CNAME hse1._domainkey / hse2._domainkey che puntano verso hornetsecurity.com sono signature non ambigue. Con una riserva di peso: questo rilevamento funziona solo per il modello gateway, non per Vade for M365 in modalità API.

A cosa serve? Auditare un prospect prima di un appuntamento, qualificare lo stack di un partner, o semplicemente capire da cosa transitano le tue stesse email. Il metodo si basa su quattro signature DNS.

Signature MX. Qualsiasi MX il cui hostname termina con .hornetsecurity.com (gli host mx01 fino a mx04) indica un dominio dietro 365 Total Protection in modalità gateway.

# Rilevare Hornetsecurity tramite l'MX
dig MX captaindns.com +short
# Risposte del tipo "10 mx01.hornetsecurity.com." = 365 Total Protection (gateway)

Signature SPF. La presenza di un include:spf.hornetsecurity.com (o include:spf.pp-tp.com in Nord America) nel record TXT del dominio conferma che Hornetsecurity veicola la posta in uscita.

# Rilevare Hornetsecurity tramite l'SPF
dig TXT captaindns.com +short | grep spf
# Presenza di "include:spf.hornetsecurity.com" = relay in uscita Hornetsecurity

Signature DKIM e autodiscover. I CNAME hse1._domainkey / hse2._domainkey verso hornetsecurity.com, e un eventuale CNAME autodiscover verso autodiscover.hornetsecurity.com, completano il fascio di indizi e confermano la delega di firma.

# Rilevare la delega DKIM Hornetsecurity
dig CNAME hse1._domainkey.captaindns.com +short
# Risposta "hse1._domainkey.hornetsecurity.com." = DKIM delegato a Hornetsecurity

Per un'analisi completa e leggibile dei record di un dominio senza manipolare dig, utilizza lo strumento DNS Lookup di CaptainDNS, che mostra gli MX, i TXT e i CNAME con un solo colpo d'occhio. Incrociare MX, SPF e CNAME DKIM toglie ogni ambiguità sulla modalità gateway.

Il punto chiave da ricordare: Vade for M365 è irrilevabile in DNS. Poiché si distribuisce tramite journaling Microsoft 365 senza toccare né gli MX né l'SPF in entrata, un dominio protetto da Vade for M365 non presenta alcuna signature DNS di Hornetsecurity. È un limite strutturale di qualsiasi audit esterno: l'assenza di signature DNS non prova l'assenza di protezione. Per questi deployment, solo un'ispezione della configurazione interna del tenant (regole di journaling, applicazioni connesse) permette di concludere.

🔄 Confronto con proofpoint, barracuda, mimecast e microsoft

Hornetsecurity si distingue per il suo posizionamento PMI e MSP europeo, ora appoggiato a Proofpoint. La tabella qui sotto confronta i criteri che pesano realmente in una scelta. La riga «Proofpoint» va letta con la sfumatura che impone l'acquisizione: Hornetsecurity è ora parte di Proofpoint, ma i due prodotti conservano il loro posizionamento distinto (SMB/MSP per Hornetsecurity, enterprise per Proofpoint storico).

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
Target	PMI, MSP (Europa)	Fortune 100, grandi ETI	PMI, mid-market, MSP	PMI/ETI multi-esigenze	Ambienti M365
Rilevamento IA	ML comportamentale + motore Vade anti-phishing	Nexus AI	Impersonation Protection	CyberGraph	Rilevamento nativo
MSP multi-tenant	Sì (punto di forza storico)	Tramite la BU Hornetsecurity	Sì (punto di forza)	Parziale	Tramite partner CSP
Modello DNS	API (senza MX) o gateway (MX)	Gateway/MX	Gateway/MX	Gateway/MX	API/nativo (senza MX)
DMARC	DMARC Manager integrato	EFD con consulenti	Domain Fraud (Premium Plus)	DMARC Analyzer integrato	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
Ideale per	PMI/MSP Europa, doppio modello API+gateway	Threat intel d'élite	SMB e MSP, semplicità/prezzo	Centralizzare sicurezza + archiviazione	Full M365, budget ridotto

Proofpoint, il proprietario e il concorrente enterprise

Il caso Proofpoint è particolare poiché, da dicembre 2025, Hornetsecurity gli appartiene. Ma i due prodotti restano distinti: Proofpoint storico mira alle grandissime aziende, con la sua threat intelligence d'élite e il suo approccio people-centric, a un costo e a una complessità che superano largamente le esigenze di una PMI. Hornetsecurity colma il segmento SMB/MSP che Proofpoint indirizzava male. Per un acquirente, la scelta non è quindi «Hornetsecurity o Proofpoint» in assoluto, ma «quale prodotto del portafoglio Proofpoint corrisponde alla mia dimensione». La nostra guida completa su Proofpoint descrive l'offerta enterprise e la sua configurazione DNS.

Barracuda, il concorrente diretto sullo stesso segmento

Sul segmento PMI e MSP, Barracuda Email Gateway Defense è il concorrente più frontale di Hornetsecurity. Stesso modello gateway/MX, stesso cuore di target, stesso argomento multi-tenant per gli MSP. La differenza si gioca nei dettagli: Barracuda fa pubblicare una chiave DKIM TXT là dove Hornetsecurity delega tramite CNAME, il suo MX integra un identificativo di account unico, e la sua copertura regionale (sei regioni) differisce dall'impronta piuttosto europea di Hornetsecurity. La nostra guida completa su Barracuda descrive la sua architettura e la sua configurazione DNS per il confronto fine.

Mimecast, abnormal e microsoft defender

Sull'ETI multi-esigenze, Mimecast propone una suite più ampia in nativo (archiviazione a lunga durata, continuità, DMARC Analyzer), al prezzo di una console più complessa. Sul fronte del rilevamento comportamentale puro e API-native, Abnormal Security eccelle sul BEC e sul VEC e si utilizza spesso a complemento di un SEG invece che in sostituzione (vedi la nostra guida completa su Abnormal Security); il suo approccio API ricorda del resto quello di Vade for M365. Infine, se sei full Microsoft 365 con esigenze standard, Defender for Office 365 resta imbattibile in rapporto prezzo/copertura (protezione nativa senza cambio di MX, spesso inclusa nella licenza E5). Hornetsecurity conserva il vantaggio sull'indipendenza di prodotto e sul modello MSP, ma la decisione dipende dalla tua dimensione, dal tuo canale e dalla tua esigenza di residenza dei dati.

🖥️ Migrazione e deployment

Il deployment in modalità gateway si fa senza interruzioni se si segue l'ordine: inventario DNS, scelta del modello, configurazione della console, commutazione MX, poi autenticazione e sorveglianza. La sequenza qui sotto dettaglia le cinque tappe.

Guida di deployment in 5 tappe, dall'inventario DNS alla commutazione MX o all'attivazione del journaling

1. Documenta lo stato attuale dei tuoi record MX, SPF, DKIM e DMARC con gli strumenti CaptainDNS. Censisci soprattutto tutte le sorgenti di invio legittime del tuo dominio: Microsoft 365, marketing (Mailchimp, HubSpot), transazionale (SendGrid, Mailgun), CRM, ticketing. Ciascuna dovrà essere autenticata nella tua nuova configurazione SPF e presa in considerazione nella roadmap DMARC, restando sotto il limite di 10 lookup.

2. Decidi tra i due approcci. La modalità gateway (365 Total Protection) intercetta prima della casella, vede il 100% del flusso in entrata, ma impone una commutazione MX e una configurazione DNS completa. La modalità API (Vade for M365) si distribuisce tramite journaling senza toccare il DNS, analizza una copia dopo la ricezione e rimedia a posteriori. La scelta dipende dalla tua tolleranza al rischio, dalla tua esigenza di intercettare il messaggio prima della consegna e dalla tua dimestichezza con una commutazione MX.

3. Nel Control Panel Hornetsecurity (o Proofpoint Total Protection in Nord America), aggiungi il tuo dominio, verificane la proprietà e sincronizza la directory utente. Recupera i valori DNS esatti comunicati all'onboarding per la tua regione (MX, include SPF, CNAME DKIM, autodiscover): differiscono tra l'Europa (hornetsecurity.com) e il Nord America (pp-tp.com). In modalità API, configura piuttosto la regola di journaling e l'associazione del tenant.

4. In modalità gateway, pubblica gli MX mx01 fino a mx04.hornetsecurity.com (priorità 10/20/30/40) al di fuori delle ore di punta, rimuovi tutti i vecchi MX, e blocca il tuo connettore Microsoft 365 affinché accetti solo il traffico Hornetsecurity (chiusura della backdoor dell'MX residuo). In modalità API, attiva la regola di journaling M365 e verifica che le copie risalgano bene verso Vade. Verifica il risultato con dig MX captaindns.com +short.

5. Aggiungi l'include SPF Hornetsecurity restando sotto i 10 lookup. Pubblica i due CNAME DKIM (hse1 e hse2._domainkey) e attiva la firma nel Control Panel. Distribuisci DMARC in p=none, sorveglia i report da 2 a 4 settimane, poi sali verso p=quarantine e p=reject. Convalida ogni record con i verificatori CaptainDNS.

⚠️ Limiti e punti di vigilanza

Hornetsecurity è solido sul suo segmento, ma alcuni punti meritano una vigilanza onesta, soprattutto nel contesto post-acquisizione.

Incertezza post-acquisizione Proofpoint. L'acquisizione è recente (dicembre 2025) e l'integrazione resta da sviluppare. Roadmap di prodotto, mantenimento dei due modelli (gateway e Vade for M365), eventuale convergenza con i mattoni Proofpoint, evoluzione tariffaria, destino del marchio Hornetsecurity in Europa: altrettante incognite a questo stadio. Nessuno può garantire oggi la stabilità dell'insieme, ed è meglio saperlo. Per un impegno pluriennale, poni queste domande esplicitamente al vendor e fai inserire le garanzie nel contratto.

Copertura regionale e cambio di marchio. L'impronta è nettamente europea. In Nord America, l'offerta passa sotto Proofpoint Total Protection con un'infrastruttura distinta (pp-tp.com), il che cambia i valori DNS e può complicare un deployment multi-regioni sotto un marchio unico. Verifica che la tua esigenza di residenza dei dati corrisponda bene a una regione disponibile.

Falsi positivi e quarantena. Come ogni SEG, Hornetsecurity può mettere in quarantena mittenti legittimi, soprattutto nelle prime settimane. Prevedi una fase di regolazione: sorveglianza attiva della quarantena, liste di autorizzazione, aggiustamento delle policy. È un lavoro di esercizio classico, ma reale, da non sottovalutare all'avvio.

Dipendenza dalla catena CNAME DKIM. La comodità del DKIM tramite CNAME ha un costo: la tua firma dipende interamente dalla delega verso hornetsecurity.com. Un'eliminazione accidentale di un CNAME, una zona mal modificata o un problema lato target, e il tuo DKIM cade, provocando fallimenti DMARC su posta pur legittima. Sorveglia la risoluzione di questi CNAME come sorveglieresti una chiave TXT, e documentali per evitare che una «pulizia» di DNS se li porti via.

📋 Piano d'azione raccomandato

Dall'audit iniziale alla policy DMARC rigorosa, ecco la sequenza completa per valutare poi distribuire Hornetsecurity.

1. Auditare la tua postura email attuale (MX, SPF, DKIM, DMARC) con gli strumenti CaptainDNS.
2. Chiarire l'identità di prodotto: stai valutando Hornetsecurity 365 Total Protection (e/o Vade for M365), ora proprietà di Proofpoint, e non l'offerta enterprise Proofpoint storica.
3. Scegliere il modello: gateway (365 Total Protection, MX) per intercettare prima della casella, o API (Vade for M365, journaling) per un deployment senza cambio di DNS.
4. Confrontare con Barracuda (concorrente diretto PMI/MSP), Mimecast, Abnormal e Microsoft Defender in base alla tua dimensione, al tuo canale e alla tua esigenza di residenza dei dati.
5. Identificare la tua regione (Europa hornetsecurity.com vs Nord America pp-tp.com), che condiziona i valori DNS esatti.
6. Configurare la console (Control Panel), aggiungere il dominio, verificare la proprietà e sincronizzare la directory.
7. Commutare gli MX (mx01 fino a mx04, priorità 10/20/30/40) al di fuori delle ore di punta e rimuovere tutti i vecchi MX, o attivare il journaling in modalità API.
8. Bloccare il connettore Microsoft 365 affinché accetti solo il traffico Hornetsecurity e chiudere la backdoor dell'MX residuo.
9. Mettere in posizione SPF (include, sotto i 10 lookup), DKIM (due CNAME hse1/hse2) e DMARC (p=none poi irrigidimento), sorvegliando la catena CNAME DKIM.
10. Sorvegliare la quarantena e i report DMARC, poi salire verso p=reject dopo 4-8 settimane di sorveglianza pulita.

📚 Guide ai gateway email

Questa analisi fa parte della nostra serie sulle soluzioni di sicurezza email enterprise:

• Mimecast Secure Email Gateway: funzionamento, configurazione DNS, confronto e piano d'azione
• Proofpoint Secure Email Gateway: Nexus AI, TAP, configurazione DNS e il nuovo proprietario di Hornetsecurity
• Cisco Secure Email Cloud Gateway (CES): architettura SaaS, DNS iphmx.com e migrazione dall'ESA
• Abnormal Security: IA comportamentale e deployment API, paragonabile al modello Vade for M365
• Cloudflare Email Service: Email Routing, Security e DMARC Management spiegati
• Barracuda Email Gateway Defense: concorrente diretto sul segmento PMI/MSP, architettura e configurazione DNS
• Hornetsecurity Secure Email Gateway: 365 Total Protection, ex-Vade, ora Proofpoint (questo articolo)

FAQ

Cos'è Hornetsecurity 365 Total Protection?

Hornetsecurity 365 Total Protection è una suite di sicurezza email cloud costruita attorno a un Secure Email Gateway. In modalità gateway, reindirizzi i tuoi record MX verso l'infrastruttura Hornetsecurity (mx01.hornetsecurity.com fino a mx04), che ispeziona ogni messaggio in entrata (reputazione, anti-spam, anti-malware, sandbox ATP, anti-phishing) poi trasferisce il traffico pulito verso Microsoft 365. La suite aggiunge, in base ai piani, la continuità, l'archiviazione, il backup M365, un DMARC Manager e un servizio di sensibilizzazione. È storicamente orientata alle PMI e agli MSP, con circa 125.000 clienti nel mondo.

Cosa ne è di Vade dopo l'acquisizione da parte di Hornetsecurity?

Vade, vendor francese di anti-phishing tramite IA (Hem, vicino a Lille), è stato acquisito da Hornetsecurity il 5 marzo 2024. Il suo marchio è stato poi spento il 21 febbraio 2025 durante il rebranding «One Team, one Brand», a favore dell'identità Hornetsecurity. Tecnicamente, il prodotto Vade for M365 sopravvive come opzione di deployment API-native, ma il nome commerciale Vade non esiste più. Trattiamo quindi Vade come un'entità assorbita, di cui restano soprattutto un modello tecnico distinto (API/journaling) e un know-how anti-phishing.

Hornetsecurity appartiene a Proofpoint?

Sì. Proofpoint ha finalizzato l'acquisizione di Hornetsecurity l'8 dicembre 2025, per circa 1,8 miliardi di dollari. Hornetsecurity diventa la business unit dedicata agli MSP all'interno di Proofpoint, colmando il segmento SMB e canale dove Proofpoint, orientato all'enterprise, era meno presente. In Nord America, l'offerta è ora commercializzata sotto il nome Proofpoint Total Protection, con un'infrastruttura dedicata sotto il dominio pp-tp.com. Il marchio Hornetsecurity resta in vigore in Europa, almeno per il tempo dell'integrazione.

Quali sono i record MX di Hornetsecurity?

Nella regione europea, Hornetsecurity fa puntare gli MX verso quattro host con priorità scaglionate: mx01.hornetsecurity.com (priorità 10), mx02.hornetsecurity.com (20), mx03.hornetsecurity.com (30) e mx04.hornetsecurity.com (40). In Nord America, sotto il marchio Proofpoint Total Protection, l'infrastruttura passa per il dominio pp-tp.com e i valori esatti ti vengono comunicati al momento dell'attivazione, tramite il Control Panel. Conferma sempre gli host esatti nel tuo pannello di amministrazione in base alla tua regione.

Quale include SPF utilizzare con Hornetsecurity?

In Europa, l'include SPF è include:spf.hornetsecurity.com, da collocare prima del meccanismo finale (~all nell'esempio di onboarding, o -all se irrigidisci dopo l'inventario completo dei tuoi mittenti). In Nord America (Proofpoint Total Protection), l'include diventa include:spf.pp-tp.com. Sorveglia il numero totale di lookup DNS per restare sotto il limite di 10 imposto dalla RFC 7208, soprattutto se cumuli Microsoft 365 e più ESP.

Come configurare DKIM con Hornetsecurity (CNAME)?

Hornetsecurity opera la firma DKIM dal suo lato e ti chiede di delegare due selettori tramite CNAME: hse1._domainkey.<tuo-dominio> verso hse1._domainkey.hornetsecurity.com, e hse2._domainkey.<tuo-dominio> verso hse2._domainkey.hornetsecurity.com. A differenza di Barracuda o Mimecast, non pubblichi alcuna chiave TXT nella tua zona: la rotazione delle chiavi avviene lato Hornetsecurity, dietro il CNAME. Una volta pubblicati i due CNAME, attiva la firma (ed eventualmente la validazione in entrata) nel Control Panel, sotto Email Authentication.

Quale differenza tra l'approccio gateway (MX) e l'approccio API di Vade?

La modalità gateway (365 Total Protection) reindirizza i tuoi MX verso Hornetsecurity, che filtra il 100% del flusso in entrata prima della consegna; è visibile in DNS (MX, SPF, CNAME DKIM). La modalità API (Vade for M365) si distribuisce tramite journaling Microsoft 365 senza cambio di MX, analizza una copia dopo la ricezione e rimedia a posteriori; è invisibile in DNS. Il gateway impedisce in pre-consegna ma impone una commutazione MX; l'API recupera in post-consegna ma si distribuisce senza toccare il DNS. La scelta dipende dalla tua esigenza di intercettare prima della consegna e dalla tua tolleranza a una commutazione MX.

Come rilevare che un dominio è protetto da Hornetsecurity?

Per la modalità gateway, quattro signature DNS lo identificano: un MX che termina con .hornetsecurity.com (mx01 fino a mx04), un include:spf.hornetsecurity.com nel TXT, dei CNAME hse1._domainkey / hse2._domainkey verso hornetsecurity.com, e un eventuale CNAME autodiscover. Incrociare queste signature toglie ogni ambiguità. Attenzione tuttavia: la modalità API (Vade for M365) è irrilevabile in DNS, poiché si distribuisce tramite journaling senza toccare gli MX. L'assenza di signature DNS non prova quindi l'assenza di protezione. Lo strumento DNS Lookup di CaptainDNS mostra questi record in modo leggibile.

Hornetsecurity funziona con Microsoft 365 e Google Workspace?

Hornetsecurity è concepito prima di tutto per Microsoft 365, dove si applicano i due modelli: il gateway (redirezione MX verso Hornetsecurity poi trasferimento verso Exchange Online) e l'API/journaling (Vade for M365), quest'ultimo nativamente legato a M365. La modalità gateway, fondata sulla redirezione MX, resta in teoria indipendente dal server di destinazione e può proteggere altri ambienti tramite redirezione MX, ma l'ecosistema, il DMARC Manager e Vade for M365 sono tagliati per M365. Per Google Workspace o un deployment ibrido, conferma la compatibilità esatta e la modalità supportata presso il vendor.

Hornetsecurity è adatto alle PMI e agli MSP?

Sì, è il suo posizionamento d'elezione. La suite è concepita per essere semplice da distribuire e da operare senza team SOC dedicato, e il suo Control Panel multi-tenant permette a un MSP di provisionare, configurare e supervisionare la sicurezza email di decine di clienti da una console centrale, con fatturazione a consumo. È uno dei programmi MSP più riusciti in Europa, il che spiega del resto l'interesse di Proofpoint, che ne ha fatto la sua business unit MSP mondiale dopo l'acquisizione del dicembre 2025.

Scarica le tabelle comparative

Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.

• Scarica il confronto (CSV)
• Scarica il confronto (JSON)

Glossario

• SEG (Secure Email Gateway): gateway di sicurezza email che filtra il traffico in entrata (e talvolta in uscita) tra Internet e il server di posta, analizzando ogni messaggio (spam, malware, phishing) prima di trasmetterlo al destinatario.

• 365 Total Protection: la suite di sicurezza email cloud di Hornetsecurity, articolata attorno a un SEG in modalità gateway (redirezione MX) per proteggere Microsoft 365. Oggetto principale di questo articolo.

• Vade for M365: prodotto ereditato dal vendor Vade, protezione email API-native che si attiva tramite journaling Microsoft 365, senza cambio di MX. Analizza una copia dei messaggi dopo la ricezione, con remediation a posteriori.

• MX (Mail Exchanger): record DNS che indica i server responsabili della ricezione delle email di un dominio. Distribuire 365 Total Protection in gateway implica reindirizzare gli MX verso mx01.hornetsecurity.com fino a mx04.

• SPF (Sender Policy Framework): protocollo di autenticazione che elenca i server autorizzati a inviare email per un dominio. Record TXT limitato a 10 lookup ricorsivi (RFC 7208). Hornetsecurity utilizza include:spf.hornetsecurity.com (o spf.pp-tp.com in Nord America).

• DKIM tramite CNAME: metodo in cui il cliente non pubblica una chiave pubblica TXT ma delega la firma tramite record CNAME (hse1._domainkey, hse2._domainkey verso hornetsecurity.com). La rotazione delle chiavi avviene lato vendor, in modo trasparente. È il fattore differenziante di Hornetsecurity rispetto a Barracuda o Mimecast.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): protocollo che verifica l'allineamento tra il dominio From e i domini autenticati da SPF o DKIM, e definisce la policy da applicare in caso di fallimento (none, quarantine, reject).

• Journaling: funzionalità Microsoft 365 che invia una copia dei messaggi a una destinazione di terze parti. È il meccanismo di deployment di Vade for M365, che rende la protezione invisibile sul fronte DNS.

• MSP (Managed Service Provider): fornitore che gestisce l'infrastruttura IT di più clienti. Il Control Panel multi-tenant di Hornetsecurity è pensato per questo modello, che è il suo cuore di mercato.

• BEC (Business Email Compromise): frode tramite email in cui l'aggressore si spaccia per un dirigente o un partner di fiducia per ottenere un bonifico o dati sensibili. Spesso senza link né allegato, quindi invisibile ai filtri per signature, da cui l'interesse del rilevamento comportamentale.

• API-native vs gateway: due modelli di protezione email. Il gateway si frappone nel flusso SMTP tramite redirezione MX e blocca prima della consegna; l'API-native si collega al tenant (journaling o API), analizza dopo la ricezione e rimedia a posteriori, senza toccare il DNS.

Fonti

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