Hornetsecurity Secure Email Gateway (ex-Vade): Architektur, DNS-Konfiguration und Alternativen

Wenn Sie die E-Mail-Infrastruktur eines KMU, einer Kanzlei oder eines ganzen Kundenparks als MSP betreuen, ist Ihnen Hornetsecurity wahrscheinlich schon begegnet, oder Vade, sein einstiger Wettbewerber und heutige Tochter. Der deutsche Anbieter beansprucht rund 125 000 Kunden und mehr als 12 000 Partner in einer Nische, die er geduldig besetzt hat: Microsoft-365-Sicherheit, verkauft von und für IT-Dienstleister. Während Proofpoint historisch den Großkundenmarkt dominierte und Barracuda das amerikanische SMB-Segment, hat sich Hornetsecurity als europäische Referenz beim MSP-Multi-Tenant-Modell etabliert.

Doch Hornetsecurity im Jahr 2026 zu analysieren heißt zunächst, eine verwirrende dreifache Identität zu entwirren. Da ist Hornetsecurity, der Hannoveraner Anbieter hinter der Suite 365 Total Protection. Da ist Vade, der französische Anbieter aus Hem (bei Lille), 2024 absorbiert und dessen Marke seit Februar 2025 offiziell nicht mehr existiert. Und da ist Proofpoint, das Ende 2025 das gesamte Unternehmen gekauft hat. Drei Namen, heute eine einzige kapitalseitige Realität. Aber zwei klar getrennte technische Modelle koexistieren weiterhin, und genau hier entscheidet sich alles auf der DNS-Seite.

Der Einsatz ist alles andere als abstrakt. Ein Secure Email Gateway (SEG) bringt nichts, wenn Ihre Domain mangels korrekter Authentifizierung weiterhin gefälscht werden kann. Den eingehenden Verkehr zu filtern schützt Ihre Postfächer. Es schützt nicht Ihre Marke vor ausgehendem Identitätsmissbrauch. Bevor Sie Hornetsecurity überhaupt bereitstellen, prüfen Sie Ihren Stand mit dem CaptainDNS DMARC-Syntax-Checker: Er sagt Ihnen, ob ein Angreifer in Ihrem Namen Mail versenden kann.

Bei CaptainDNS betrachten wir Hornetsecurity aus dem Blickwinkel, der uns beschäftigt: die konkreten Auswirkungen auf Ihre DNS-Einträge und Ihre E-Mail-Authentifizierung. 365 Total Protection im Gateway-Modus bereitzustellen bedeutet, Ihre MX zu mx01.hornetsecurity.com umzuleiten, den Include spf.hornetsecurity.com hinzuzufügen und Ihr DKIM per CNAME zu delegieren. Vade for M365 im API-Modus bereitzustellen hingegen rührt keinen einzigen DNS-Eintrag an. Dieser Leitfaden deckt die Übernahmesaga ab, die beiden Architekturen, die detaillierte DNS-Konfiguration mit den realen Werten, die Erkennung einer Domain hinter Hornetsecurity, den Vergleich und einen Aktionsplan. Und er verschweigt die Unsicherheiten nach der Übernahme nicht: Wir benennen sie dort, wo sie bestehen.

📌 Was ist das E-Mail-Gateway von hornetsecurity?

Hornetsecurity 365 Total Protection ist eine Cloud-E-Mail-Sicherheitssuite rund um ein Secure Email Gateway: ein gehosteter Filter, der den eingehenden E-Mail-Verkehr prüft, bevor er Ihren Microsoft-365-Tenant erreicht. Im Gateway-Modus leiten Sie Ihre MX-Einträge zur Hornetsecurity-Infrastruktur um, die jede Nachricht analysiert und dann nur den sauberen Verkehr an Exchange Online weiterleitet.

Für die Grundlagen eines SEG (Gateway-Modell, MX-Umleitung, Unterschied zu API-nativen ICES-Lösungen) verweisen wir auf unseren vollständigen Leitfaden zu Barracuda, der diese Grundlagen im Detail behandelt. Das Wesentliche in einem Satz: Ein SEG schaltet sich zwischen das Internet und Ihre Messaging-Infrastruktur, sieht den gesamten eingehenden Verkehr und blockiert Bedrohungen vor der Zustellung statt nachträglich.

Die Besonderheit von Hornetsecurity liegt darin, dass die Marke zwei technische Ansätze ohne nennenswerte Gemeinsamkeit umfasst, ererbt aus der Fusion mit Vade. Auf der einen Seite 365 Total Protection, das klassische SEG auf Basis der MX-Umleitung, Hauptthema dieses Artikels. Auf der anderen Seite Vade for M365, ein API-nativer Schutz, der per Journaling aktiviert wird, ohne die MX anzutasten. Die beiden zu verwechseln führt direkt zum Diagnosefehler: Eine durch Vade for M365 geschützte Domain zeigt keinerlei DNS-Signatur, während eine Domain unter 365 Total Protection auf den ersten Blick an ihren MX zu erkennen ist. Diesen Kontrast vertiefen wir weiter unten.

Die Suite 365 Total Protection gibt es in mehreren Plänen, von der Basisfilterung (Anti-Spam, Anti-Malware) bis zu den höheren Plänen, die die ATP-Sandbox, den Anti-Spoofing-Schutz, die Dienstkontinuität, die rechtskonforme Archivierung und das Microsoft-365-Backup hinzufügen. Hornetsecurity ergänzt das um übergreifende Module wie den Security Awareness Service (Phishing-Sensibilisierung) und einen DMARC Manager. Alles wird über ein Multi-Tenant Control Panel gesteuert, zugeschnitten auf MSP.

🕰️ Die übernahmesaga: von vade zu proofpoint

Drei Transaktionen in weniger als zwei Jahren haben zwei konkurrierende Anbieter fusioniert und das Ganze dann unter einen amerikanischen Riesen gestellt. Hier die Chronologie, mit Daten belegt.

Vade: das französische KI-anti-phishing, api-nativ

Vade (früher Vade Secure) ist ein französischer Anbieter, 2009 gegründet und mit Sitz in Hem, im Großraum Lille. Seinen Ruf hat sich das Unternehmen mit einer anerkannten KI-gestützten Anti-Phishing-Engine erarbeitet, sowie mit einem Vertriebsmodell, das auf Internetanbieter und MSP ausgerichtet ist. Zum Zeitpunkt der Übernahme beanspruchte das Unternehmen den Schutz von rund 1,4 Milliarden Postfächern weltweit und die Analyse mehrerer Milliarden Nachrichten pro Tag, größtenteils über Provider-Partnerschaften.

Vor allem trug Vade einen technischen Ansatz, der sich vom klassischen SEG unterscheidet: Sein Vorzeigeprodukt, Vade for M365, arbeitet API-nativ auf Microsoft 365. Keine MX-Umleitung, kein physisches Gateway im Verkehrsfluss: Die Analyse klinkt sich direkt über die Microsoft-API in den Tenant ein. Genau dieses Know-how hat sich Hornetsecurity geholt, historisch auf dem Gateway-Modell positioniert.

5. märz 2024: hornetsecurity übernimmt vade

Am 5. März 2024 gibt Hornetsecurity, der deutsche Anbieter mit Sitz in Hannover, die Übernahme von Vade bekannt. Die Transaktion wird als Geburt eines europäischen Champions für Microsoft-365-Sicherheit präsentiert, der die MSP-Basis und die Suite 365 Total Protection von Hornetsecurity mit der KI-Engine und dem Provider-Fußabdruck von Vade verbindet. Auf dem Papier ergänzen sich die beiden Bausteine: ein erprobtes Cloud-SEG auf der einen, API- und Anti-Phishing-Expertise auf der anderen Seite.

21. februar 2025: "one team, one brand", vade verschwindet

Weniger als ein Jahr später, am 21. Februar 2025, vollzieht Hornetsecurity die Fusion der Marken unter dem Motto "One Team, one Brand". Die Marke Vade verschwindet: Logo, Farben, Kommunikation und Prozesse werden unter der Hornetsecurity-Identität vereinheitlicht. Die von Vade ererbten Produkte überleben technisch (Vade for M365 bleibt eine Deployment-Option), doch der Markenname verblasst. Deshalb behandelt dieser Artikel Vade als absorbierte Einheit, von der vor allem ein technisches Modell und ein Rest an Suchverkehr übrig bleibt.

8. dezember 2025: proofpoint schließt die übernahme ab

Letzter Akt, der 8. Dezember 2025: Proofpoint, amerikanische Referenz für E-Mail-Sicherheit, schließt die Übernahme von Hornetsecurity für rund 1,8 Milliarden Dollar ab. Die Transaktion bewertet einen jährlich wiederkehrenden Umsatz (ARR) von etwa 200 Millionen Dollar bei starkem Wachstum. Hornetsecurity wird zu einer MSP-orientierten Business Unit innerhalb von Proofpoint und schließt genau das SMB- und Kanalsegment, in dem Proofpoint, historisch auf das Enterprise-Geschäft ausgerichtet, am schwächsten vertreten war. In Nordamerika wird das Angebot inzwischen unter dem Namen Proofpoint Total Protection vermarktet, mit einer dedizierten Infrastruktur unter der Domain pp-tp.com. Die Marke Hornetsecurity bleibt dagegen in Europa erhalten, zumindest während der Integration.

🏢 Hornetsecurity im überblick

Hornetsecurity ist ein deutscher Anbieter für Cloud-Sicherheit, 2007 gegründet und mit Sitz in Hannover, der rund 125 000 Kunden und mehr als 12 000 Partner beansprucht, mit starker Konzentration auf das KMU-Segment und das MSP-Modell. Sein Wachstum wurde von aufeinanderfolgenden Übernahmen und einem Vorzeigeprodukt getrieben, 365 Total Protection, gedacht für den Kanal.

Das Unternehmen firmierte lange unter dem Namen Antispameurope, bevor es zu Hornetsecurity wurde. Seine Positionierung hat sich kaum verändert: Cloud-E-Mail-Filterung, schnell bereitzustellen, als White-Label oder Co-Brand von IT-Dienstleistern verkauft. Wo manche Enterprise-Wettbewerber sich an den einzelnen Endkunden wenden, verkauft Hornetsecurity an den Dienstleister, der weiterverkauft. Ein MSP stellt seine Kunden über ein zentrales Control Panel bereit, erbt die Richtlinien eines gemeinsamen Modells, verfeinert sie pro Tenant und rechnet nach Nutzung ab. Diese Multi-Tenant-Mechanik ist der Kern der Attraktivität von Hornetsecurity im Kanal.

Die Präsenz ist deutlich europäisch, mit einer auf Europa konzentrierten Vertriebsmannschaft und Rechenzentren (insbesondere in Deutschland und Frankreich, letzteres gestärkt durch den Beitrag von Vade). Dieser geografische Fußabdruck bedient ein wiederkehrendes Argument des Segments: den Datenstandort in Europa, erwartet von Organisationen, die der DSGVO unterliegen oder davor zurückschrecken, ihren E-Mail-Verkehr einer Infrastruktur außerhalb der EU anzuvertrauen. Die Übernahme von Vade hat eine anerkannte Anti-Phishing-Forschung und einen Provider-Fußabdruck hinzugefügt. Der Übergang unter Proofpoint bringt seinerseits die Anbindung an eine erstklassige Threat Intelligence, deren konkrete Auswirkungen auf das Produkt noch zu beobachten bleiben.

⚙️ Architektur: zwei modelle unter einem dach

Das ist der Dreh- und Angelpunkt dieses Artikels. Seit der Absorption von Vade bietet Hornetsecurity zwei Wege, Microsoft 365 zu schützen, die beim Deployment und auf der DNS-Seite fast nichts gemein haben. Zu wissen, welchen Sie bereitstellen, bestimmt Ihre gesamte weitere Konfiguration.

365 total protection: das gateway-modell, mx-umleitung

Das historische Produkt von Hornetsecurity, 365 Total Protection, ist ein klassisches SEG. Ihre MX-Einträge zeigen auf die Cloud-Infrastruktur von Hornetsecurity. Wenn ein Absender an contact@captaindns.com schreibt, löst sein Server den MX auf, findet einen Hornetsecurity-Host (mx01.hornetsecurity.com und seine Pendants) und stellt die Nachricht dort zu. Hornetsecurity wendet seine Inspektionskette an (Reputation, Anti-Spam, Anti-Malware, ATP-Sandbox, Anti-Phishing) und leitet die validierte Nachricht dann an Exchange Online weiter.

Der Vorteil ist derselbe wie bei jedem SEG: Hornetsecurity sieht 100 % des eingehenden Verkehrs und blockiert Bedrohungen, bevor sie Ihren Tenant berühren. Die Kehrseite ist ein sichtbares und eingreifendes Deployment. Sie müssen die MX ändern, das SPF anpassen, das DKIM delegieren und eine unterbrechungsfreie Umschaltung managen. Genau diesen Vorgang beschreibt dieser Leitfaden.

Vade for M365: das api-native, ohne mx-änderung

Das Vade-Erbe bringt ein radikal anderes Modell ins Spiel. Vade for M365 schaltet sich nicht in den SMTP-Verkehr ein. Es wird per Journaling von Microsoft 365 aktiviert: Man konfiguriert eine Journaling-Regel, die eine Kopie jeder Nachricht an Vade sendet, verknüpft den Tenant und ein O365-Konto, und die Analyse erfolgt nach Empfang, auf der Kopie. Die Engine wendet ein verhaltensbasiertes maschinelles Lernen an, um Spear-Phishing, polymorphe Malware und Zero-Day-Bedrohungen zu erkennen, mit möglicher Remediation bereits zugestellter Nachrichten.

Wesentliche Folge für unsere Leserschaft: Dieses Deployment ist DNS-seitig unsichtbar. Keine MX-Änderung, keine eingehende SPF-Signatur, nichts in der Zone zu veröffentlichen. Der Schutz lebt vollständig in der API-/Journaling-Beziehung zwischen dem Tenant und Vade. Das ist bequem: "unterbrechungsfreies" Deployment, und kein Risiko von Mail-Verlust durch eine fehlerhafte MX-Umschaltung. Doch es wirft eine Audit-Frage auf, die wir weiter unten aufgreifen: Man kann diesen Schutz nicht per einfachem DNS-Lookup erkennen.

Api-nativ gegen gateway/mx: was wirklich anders ist

Drei Unterschiede trennen die beiden Modelle wirklich.

Sichtbarkeit des Verkehrs. Ein SEG im Gateway-Modus sieht die Nachricht vor ihrer Zustellung und kann sie vor dem Empfang blockieren. Ein API-/Journaling-Schutz analysiert eine Kopie nach Empfang und greift dann per Remediation ein (Verschieben oder nachträgliches Löschen). Das Zeitfenster der Exposition ist also nicht dasselbe. Das Gateway verhindert, die API holt nach.

DNS-Erkennbarkeit. Das Gateway hinterlässt klare Spuren: MX, SPF, DKIM-CNAME, Autodiscover. Die API hinterlässt keinerlei eingehende DNS-Spur. Für einen externen Auditor sieht eine Domain unter Vade for M365 aus wie eine nackte Microsoft-365-Domain.

Integration und operatives Risiko. Das Gateway erzwingt eine MX-Umschaltung mit ihrem klassischen Risiko von Mail-Verlust bei schlechter Durchführung, bietet dafür aber die volle Kontrolle über den Verkehr. Die API hingegen wird mit wenigen Klicks bereitgestellt, ohne das DNS anzutasten, zum Preis einer Abhängigkeit von der Microsoft-API und eines Eingriffs nach der Zustellung. Viele Organisationen, die bereits voll auf M365 setzen, entscheiden sich wegen ihrer Einfachheit für die API. Wer vor dem Postfach abfangen will, behält das Gateway.

🔧 DNS-Konfiguration Schritt für Schritt

Dieser Abschnitt betrifft den Gateway-Modus (365 Total Protection). Das Deployment ändert vier Familien von Einträgen: MX, SPF, DKIM und DMARC, plus einen eventuellen Autodiscover-CNAME. Ein Fehler bei einem davon, und Ihre E-Mails verschwinden oder umgehen die Filterung. Hier jeder Schritt mit den realen, von Hornetsecurity beim Onboarding kommunizierten Werten, und den zu vermeidenden Fallstricken.

Die MX-Einträge

In der europäischen Region lässt Hornetsecurity die MX auf vier Hosts zeigen, mit gestaffelten Prioritäten für die Redundanz:

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

Der vorrangigste Server (Priorität 10) empfängt den Verkehr; die folgenden sorgen für die Umschaltung bei Ausfall. Das ist eine regional generische Nomenklatur, anders als bei Barracuda, dessen MX eine eindeutige Kontokennung enthält. Diese Generik ist praktisch für die Erkennung (siehe weiter unten), bedeutet aber, dass das Routing zu Ihrem Tenant auf der Control-Panel-Seite konfiguriert wird, nicht über den MX-Hostnamen.

Entscheidender Punkt nach der Übernahme: In Nordamerika wird das Angebot inzwischen unter Proofpoint Total Protection vermarktet, mit einer dedizierten Infrastruktur unter der Domain pp-tp.com (Versand-Relay vom Typ relay01-hz14.pp-tp.com, SPF-Include spf.pp-tp.com). Die nordamerikanischen eingehenden MX-Werte unterscheiden sich also von den europäischen und werden Ihnen bei der Aktivierung mitgeteilt, über das Admin-Panel. Übertragen Sie nicht mechanisch die Werte mx01.hornetsecurity.com, wenn Ihr Tenant in der nordamerikanischen Region bereitgestellt wird: Bestätigen Sie die exakten Hosts immer in Ihrem Control Panel.

# Aktuelle MX überprüfen
dig MX captaindns.com +short

Der Fallstrick des Rest-MX. Lassen Sie nach der Umschaltung zu Hornetsecurity keinen Rest-MX bestehen, der auf Ihren alten Server oder direkt auf Ihren Tenant *.mail.protection.outlook.com zeigt. Ein Rest-MX ist eine Hintertür: Ein Angreifer, der Ihre Microsoft-365-Infrastruktur kennt, kann direkt an Ihre Postfächer zustellen und dabei Hornetsecurity umgehen. Überprüfen Sie nach der Umschaltung mit dig MX, dass nur noch die Hornetsecurity-MX vorhanden sind, und verriegeln Sie Ihren Microsoft-365-Connector, sodass er nur den von Hornetsecurity kommenden Verkehr annimmt.

Ein sauberes Deployment sieht zudem einen CNAME autodiscover vor, der auf autodiscover.hornetsecurity.com zeigt und die automatische Konfiguration der Mail-Clients erleichtert. Er ist für die Filterung nicht unverzichtbar, gehört aber zur vom Anbieter dokumentierten Standardkonfiguration.

Das SPF mit dem hornetsecurity-include

Für die über Hornetsecurity relayte ausgehende Post fügen Sie den SPF-Include des Anbieters hinzu. Der beim europäischen Onboarding kommunizierte Wert ist einfach und ohne erkennbare regionale Variante auf der eingehenden SPF-Seite:

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

In Nordamerika (Proofpoint Total Protection) wird der Include zu include:spf.pp-tp.com. In beiden Fällen kombinieren Sie die Includes, wenn Sie auch direkt aus Microsoft 365 versenden:

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

Hornetsecurity dokumentiert das ~all (Softfail) in seinem Onboarding-Beispiel, doch Sie können auf -all (Hardfail) verschärfen, sobald Ihre Bestandsaufnahme der Absender vollständig und Ihr DMARC stabilisiert ist. Das -all fügt einen Schutz auf SPF-Ebene selbst hinzu, während das ~all im Fehlerfall durchlässt, ohne zu blockieren. Überwachen Sie vor allem die Gesamtzahl der DNS-Lookups: Die SPF-Spezifikation (RFC 7208) schreibt ein Limit von 10 rekursiven Lookups vor. Kumulieren Sie Hornetsecurity, Microsoft 365 und zwei oder drei ESP (Mailchimp, SendGrid usw.), und Sie nähern sich schnell der Obergrenze, mit einem PermError als Folge, der die gesamte SPF-Validierung zerstört. Der CaptainDNS SPF-Syntax-Checker zählt diese Lookups und meldet Überschreitungen.

Das DKIM per CNAME, das unterscheidungsmerkmal

Hier hebt sich Hornetsecurity deutlich von Barracuda oder Mimecast ab. Statt Sie einen in der Konsole generierten öffentlichen TXT-Schlüssel veröffentlichen zu lassen, betreibt Hornetsecurity die DKIM-Signatur auf seiner Seite und bittet Sie lediglich, zwei Selektoren per CNAME-Einträgen zu delegieren:

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

Die praktische Folge ist bequem: kein TXT-Schlüssel in Ihrer Zone, also keine Schlüsselrotation, die Sie manuell auf Ihrer Seite verwalten müssten. Hornetsecurity rotiert seine Schlüssel hinter dem CNAME, transparent. Sie veröffentlichen die beiden CNAME ein für alle Mal, aktivieren dann die Signatur (und, falls gewünscht, die eingehende DKIM-Validierung) im Control Panel unter Email Authentication. Das Vorhandensein zweier Selektoren (hse1 und hse2) ermöglicht gerade die Rotation auf Anbieterseite ohne Eingriff in Ihr DNS.

# Die DKIM-Delegation per CNAME überprüfen
dig CNAME hse1._domainkey.captaindns.com +short
# Erwartete Antwort: hse1._domainkey.hornetsecurity.com.

Die Kehrseite dieser Bequemlichkeit ist eine Abhängigkeit: Ihr DKIM beruht vollständig auf der CNAME-Kette zu Hornetsecurity. Bricht die Delegation (gelöschter CNAME, schlecht editierte Zone oder ein Problem bei der Auflösung des Ziels), fällt Ihre DKIM-Signatur und mit ihr das DMARC-Alignment. Wir kommen darauf in den Grenzen zurück.

Das DMARC-Alignment

DMARC überprüft, dass die im Feld From sichtbare Domain mit der durch SPF oder DKIM authentifizierten Domain aligniert ist, und legt die im Fehlerfall anzuwendende Richtlinie fest. Hinter einem Gateway verdient ein Punkt Aufmerksamkeit: Das ausgehende Relay über Hornetsecurity kann den SMTP-Envelope umschreiben, was das SPF-Alignment auf Empfängerseite verloren gehen lässt. Dann wird DKIM zur Säule des DMARC-Alignments. Daher die Bedeutung, die beiden DKIM-CNAME korrekt zu setzen, bevor Sie die Richtlinie verschärfen: ohne gültige DKIM-Signatur werden eigentlich legitime Nachrichten an DMARC scheitern, sobald p=reject aktiv ist.

Die empfohlene Progression ist dieselbe wie bei jedem Deployment:

1. p=none (Überwachung): Sie erhalten die aggregierten Berichte, ohne die Zustellung zu beeinträchtigen. Dauer: 2 bis 4 Wochen.
2. p=quarantine: Nicht authentifizierte Nachrichten landen im Spam. Dauer: 2 bis 4 Wochen.
3. p=reject: Nicht authentifizierte Nachrichten werden abgelehnt. Das ist die Zielrichtlinie.

Beispiel für einen DMARC-Starteintrag:

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

Hornetsecurity bietet ein Modul DMARC Manager, das die Berichte aggregiert und visualisiert, die noch nicht authentifizierten legitimen Versandquellen identifiziert und den Aufstieg zu p=reject begleitet. Wenn Sie DMARC mit einem anderen Tool steuern, validieren Sie jede Änderung des Eintrags mit dem CaptainDNS DMARC-Syntax-Checker.

🔍 Erkennen, dass eine domain durch hornetsecurity geschützt ist

Um zu wissen, ob eine Domain 365 Total Protection im Gateway-Modus nutzt, untersuchen Sie ihre DNS-Einträge: ein MX, der auf .hornetsecurity.com endet, ein Include spf.hornetsecurity.com oder CNAME hse1._domainkey / hse2._domainkey, die auf hornetsecurity.com zeigen, sind eindeutige Signaturen. Mit einem gewichtigen Vorbehalt: Diese Erkennung funktioniert nur für das Gateway-Modell, nicht für Vade for M365 im API-Modus.

Wozu das gut ist? Einen Interessenten vor einem Termin auditieren, den Stack eines Partners qualifizieren oder einfach verstehen, worüber Ihre eigenen E-Mails laufen. Die Methode beruht auf vier DNS-Signaturen.

MX-Signatur. Jeder MX, dessen Hostname auf .hornetsecurity.com endet (die Hosts mx01 bis mx04), weist auf eine Domain hinter 365 Total Protection im Gateway-Modus hin.

# Hornetsecurity über den MX erkennen
dig MX captaindns.com +short
# Antworten vom Typ "10 mx01.hornetsecurity.com." = 365 Total Protection (Gateway)

SPF-Signatur. Das Vorhandensein eines include:spf.hornetsecurity.com (oder include:spf.pp-tp.com in Nordamerika) im TXT-Eintrag der Domain bestätigt, dass Hornetsecurity die ausgehende Post relayt.

# Hornetsecurity über das SPF erkennen
dig TXT captaindns.com +short | grep spf
# Vorhandensein von "include:spf.hornetsecurity.com" = ausgehendes Relay Hornetsecurity

DKIM- und Autodiscover-Signaturen. Die CNAME hse1._domainkey / hse2._domainkey zu hornetsecurity.com und ein eventueller CNAME autodiscover zu autodiscover.hornetsecurity.com ergänzen das Indizienbündel und bestätigen die Delegation der Signatur.

# Die DKIM-Delegation an Hornetsecurity erkennen
dig CNAME hse1._domainkey.captaindns.com +short
# Antwort "hse1._domainkey.hornetsecurity.com." = DKIM an Hornetsecurity delegiert

Für eine vollständige und lesbare Analyse der Einträge einer Domain, ohne dig zu bemühen, verwenden Sie das DNS-Lookup-Tool von CaptainDNS, das die MX, TXT und CNAME auf einen Blick anzeigt. MX, SPF und DKIM-CNAME zu kreuzen beseitigt jede Mehrdeutigkeit über den Gateway-Modus.

Der entscheidende Punkt: Vade for M365 ist DNS-seitig nicht erkennbar. Da es per Microsoft-365-Journaling bereitgestellt wird, ohne die MX oder das eingehende SPF anzutasten, weist eine durch Vade for M365 geschützte Domain keinerlei DNS-Signatur von Hornetsecurity auf. Das ist eine strukturelle Grenze jedes externen Audits: Das Fehlen einer DNS-Signatur beweist nicht das Fehlen von Schutz. Für diese Deployments lässt nur eine Inspektion der internen Tenant-Konfiguration (Journaling-Regeln, verbundene Anwendungen) eine Aussage zu.

🔄 Vergleich mit proofpoint, barracuda, mimecast und microsoft

Hornetsecurity zeichnet sich durch seine KMU- und europäische MSP-Positionierung aus, inzwischen an Proofpoint angebunden. Die folgende Tabelle vergleicht die Kriterien, die bei einer Wahl wirklich ins Gewicht fallen. Die Zeile "Proofpoint" ist mit der Nuance zu lesen, die die Übernahme aufzwingt: Hornetsecurity ist inzwischen ein Teil von Proofpoint, doch die beiden Produkte behalten ihre eigene Positionierung (SMB/MSP für Hornetsecurity, Enterprise für das historische Proofpoint).

Proofpoint, der eigentümer und der enterprise-wettbewerber

Der Fall Proofpoint ist besonders, denn seit Dezember 2025 gehört Hornetsecurity ihm. Doch die beiden Produkte bleiben getrennt: Das historische Proofpoint zielt auf den sehr großen Konzern, mit seiner erstklassigen Threat Intelligence und seinem People-Centric-Ansatz, zu Kosten und einer Komplexität, die die Bedürfnisse eines KMU weit übersteigen. Hornetsecurity schließt das SMB/MSP-Segment, das Proofpoint schlecht bediente. Für einen Käufer lautet die Wahl also nicht "Hornetsecurity oder Proofpoint" im Absoluten, sondern "welches Produkt aus dem Proofpoint-Portfolio passt zu meiner Größe". Unser vollständiger Leitfaden zu Proofpoint beschreibt detailliert das Enterprise-Angebot und seine DNS-Konfiguration.

Barracuda, der direkte wettbewerber im selben segment

Im KMU- und MSP-Segment ist Barracuda Email Gateway Defense der frontalste Wettbewerber von Hornetsecurity. Gleiches Gateway/MX-Modell, gleiches Kernziel, gleiches Multi-Tenant-Argument für MSP. Der Unterschied liegt im Detail: Barracuda lässt einen TXT-DKIM-Schlüssel veröffentlichen, wo Hornetsecurity per CNAME delegiert, sein MX enthält eine eindeutige Kontokennung, und seine regionale Abdeckung (sechs Regionen) unterscheidet sich vom eher europäischen Fußabdruck von Hornetsecurity. Unser vollständiger Leitfaden zu Barracuda beschreibt detailliert seine Architektur und seine DNS-Konfiguration für den feinen Vergleich.

Mimecast, abnormal und microsoft defender

Im Mittelstand mit vielfältigem Bedarf bietet Mimecast eine breitere Suite nativ (Langzeit-Archivierung, Kontinuität, DMARC Analyzer), zum Preis einer komplexeren Konsole. Bei der reinen verhaltensbasierten Erkennung und API-nativ glänzt Abnormal Security bei BEC und VEC und wird oft als Ergänzung zu einem SEG statt als Ersatz genutzt (siehe unseren vollständigen Leitfaden zu Abnormal Security); sein API-Ansatz erinnert im Übrigen an den von Vade for M365. Schließlich, wenn Sie voll auf Microsoft 365 setzen mit Standardbedarf, bleibt Defender for Office 365 beim Preis-Abdeckungs-Verhältnis unschlagbar (nativer Schutz ohne MX-Änderung, oft in der E5-Lizenz enthalten). Hornetsecurity behält den Vorteil bei der Produktunabhängigkeit und beim MSP-Modell, doch die Entscheidung hängt von Ihrer Größe, Ihrem Kanal und Ihrer Anforderung an den Datenstandort ab.

🖥️ Migration und deployment

Das Deployment im Gateway-Modus erfolgt unterbrechungsfrei, wenn man die Reihenfolge einhält: DNS-Inventur, Wahl des Modells, Konfiguration der Konsole, MX-Umschaltung, dann Authentifizierung und Überwachung. Die folgende Sequenz beschreibt die fünf Schritte.

⚠️ Grenzen und punkte zur wachsamkeit

Hornetsecurity ist solide in seinem Segment, doch einige Punkte verdienen eine ehrliche Wachsamkeit, besonders im Kontext nach der Übernahme.

Unsicherheit nach der Proofpoint-Übernahme. Die Übernahme ist jung (Dezember 2025) und die Integration steht noch aus. Produkt-Roadmap, Erhalt der beiden Modelle (Gateway und Vade for M365), eventuelle Konvergenz mit den Proofpoint-Bausteinen, Preisentwicklung, Zukunft der Marke Hornetsecurity in Europa: lauter Unbekannte in diesem Stadium. Niemand kann heute die Stabilität des Ganzen garantieren, und das sollte man wissen. Für eine mehrjährige Bindung stellen Sie diese Fragen dem Anbieter ausdrücklich und lassen Sie die Garantien vertraglich festhalten.

Regionale Abdeckung und Markenumstellung. Der Fußabdruck ist deutlich europäisch. In Nordamerika läuft das Angebot unter Proofpoint Total Protection mit einer eigenen Infrastruktur (pp-tp.com), was die DNS-Werte ändert und ein Multi-Regionen-Deployment unter einer einzigen Marke erschweren kann. Überprüfen Sie, dass Ihre Anforderung an den Datenstandort tatsächlich einer verfügbaren Region entspricht.

False Positives und Quarantäne. Wie jedes SEG kann Hornetsecurity legitime Absender in die Quarantäne stellen, besonders in den ersten Wochen. Planen Sie eine Einstellphase ein: aktive Überwachung der Quarantäne, Zulassungslisten, Anpassung der Richtlinien. Das ist klassische Betriebsarbeit, aber reale, die man zu Beginn nicht unterschätzen sollte.

Abhängigkeit von der DKIM-CNAME-Kette. Der Komfort des DKIM per CNAME hat seinen Preis: Ihre Signatur hängt vollständig von der Delegation zu hornetsecurity.com ab. Ein versehentliches Löschen eines CNAME, eine schlecht editierte Zone oder ein Problem auf der Zielseite, und Ihr DKIM fällt, was DMARC-Fehlschläge bei eigentlich legitimer Post nach sich zieht. Überwachen Sie die Auflösung dieser CNAME, wie Sie einen TXT-Schlüssel überwachen würden, und dokumentieren Sie sie, damit eine "DNS-Bereinigung" sie nicht mitreißt.

📋 Empfohlener aktionsplan

Vom ersten Audit bis zur strikten DMARC-Richtlinie, hier die vollständige Sequenz, um Hornetsecurity zu evaluieren und dann bereitzustellen.

1. Auditieren Sie Ihre aktuelle E-Mail-Sicherheitslage (MX, SPF, DKIM, DMARC) mit den CaptainDNS-Tools.
2. Die Produktidentität klären: Sie evaluieren Hornetsecurity 365 Total Protection (und/oder Vade for M365), inzwischen Eigentum von Proofpoint, und nicht das historische Enterprise-Angebot Proofpoint.
3. Das Modell wählen: Gateway (365 Total Protection, MX), um vor dem Postfach abzufangen, oder API (Vade for M365, Journaling) für ein Deployment ohne DNS-Änderung.
4. Vergleichen Sie mit Barracuda (direkter KMU/MSP-Wettbewerber), Mimecast, Abnormal und Microsoft Defender je nach Ihrer Größe, Ihrem Kanal und Ihrer Anforderung an den Datenstandort.
5. Ihre Region identifizieren (Europa hornetsecurity.com vs. Nordamerika pp-tp.com), die die exakten DNS-Werte bestimmt.
6. Die Konsole konfigurieren (Control Panel), die Domain hinzufügen, die Eigentümerschaft verifizieren und das Verzeichnis synchronisieren.
7. Die MX umschalten (mx01 bis mx04, Prioritäten 10/20/30/40) außerhalb der Stoßzeiten und alle alten MX entfernen, oder das Journaling im API-Modus aktivieren.
8. Den Connector verriegeln Microsoft 365, sodass er nur den Hornetsecurity-Verkehr annimmt, und die Hintertür des Rest-MX schließen.
9. SPF einrichten (Include, unter 10 Lookups), DKIM (zwei CNAME hse1/hse2) und DMARC (p=none dann Verschärfung), unter Überwachung der DKIM-CNAME-Kette.
10. Überwachen Sie die Quarantäne und die DMARC-Berichte, steigen Sie dann nach 4 bis 8 Wochen sauberer Überwachung auf p=reject.

📚 E-Mail-Gateway-Leitfäden

Diese Analyse ist Teil unserer Serie über E-Mail-Sicherheitslösungen für Unternehmen:

• Mimecast Secure Email Gateway: Funktionsweise, DNS-Konfiguration, Vergleich und Aktionsplan
• Proofpoint Secure Email Gateway: Nexus AI, TAP, DNS-Konfiguration und der neue Eigentümer von Hornetsecurity
• Cisco Secure Email Cloud Gateway (CES): SaaS-Architektur, DNS iphmx.com und Migration von der ESA
• Abnormal Security: verhaltensbasierte KI und API-Deployment, vergleichbar mit dem Modell Vade for M365
• Cloudflare Email Service: Email Routing, Security und DMARC Management erklärt
• Barracuda Email Gateway Defense: direkter Wettbewerber im KMU/MSP-Segment, Architektur und DNS-Konfiguration
• Hornetsecurity Secure Email Gateway: 365 Total Protection, ex-Vade, inzwischen Proofpoint (dieser Artikel)

Glossar

• SEG (Secure Email Gateway): E-Mail-Sicherheitsgateway, das den eingehenden (und mitunter ausgehenden) Verkehr zwischen Internet und Mailserver filtert und jede Nachricht (Spam, Malware, Phishing) analysiert, bevor sie an den Empfänger übermittelt wird.

• 365 Total Protection: die Cloud-E-Mail-Sicherheitssuite von Hornetsecurity, aufgebaut um ein SEG im Gateway-Modus (MX-Umleitung) zum Schutz von Microsoft 365. Hauptthema dieses Artikels.

• Vade for M365: vom Anbieter Vade ererbtes Produkt, ein API-nativer E-Mail-Schutz, der per Microsoft-365-Journaling aktiviert wird, ohne MX-Änderung. Analysiert eine Kopie der Nachrichten nach Empfang, mit nachträglicher Remediation.

• MX (Mail Exchanger): DNS-Eintrag, der die für den Empfang der E-Mails einer Domain zuständigen Server angibt. 365 Total Protection im Gateway-Modus bereitzustellen bedeutet, die MX zu mx01.hornetsecurity.com bis mx04 umzuleiten.

• SPF (Sender Policy Framework): Authentifizierungsprotokoll, das die zum Versand von E-Mails für eine Domain autorisierten Server auflistet. TXT-Eintrag, begrenzt auf 10 rekursive Lookups (RFC 7208). Hornetsecurity verwendet include:spf.hornetsecurity.com (oder spf.pp-tp.com in Nordamerika).

• DKIM per CNAME: Methode, bei der der Kunde keinen öffentlichen TXT-Schlüssel veröffentlicht, sondern die Signatur per CNAME-Einträgen delegiert (hse1._domainkey, hse2._domainkey zu hornetsecurity.com). Die Schlüsselrotation erfolgt auf Anbieterseite, transparent. Das ist das entscheidende Unterscheidungsmerkmal von Hornetsecurity gegenüber Barracuda oder Mimecast.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): Protokoll, das das Alignment zwischen der From-Domain und den durch SPF oder DKIM authentifizierten Domains überprüft und die im Fehlerfall anzuwendende Richtlinie festlegt (none, quarantine, reject).

• Journaling: Microsoft-365-Funktion, die eine Kopie der Nachrichten an ein Drittziel sendet. Das ist der Deployment-Mechanismus von Vade for M365, der den Schutz DNS-seitig unsichtbar macht.

• MSP (Managed Service Provider): Dienstleister, der die IT-Infrastruktur mehrerer Kunden verwaltet. Das Multi-Tenant Control Panel von Hornetsecurity ist für dieses Modell gedacht, das sein Kernmarkt ist.

• BEC (Business Email Compromise): E-Mail-Betrug, bei dem sich der Angreifer als Geschäftsführer oder vertrauenswürdiger Partner ausgibt, um eine Überweisung oder sensible Daten zu erlangen. Oft ohne Link und ohne Anhang, also unsichtbar für signaturbasierte Filter, daher das Interesse an verhaltensbasierter Erkennung.

• API-nativ vs. Gateway: zwei Modelle des E-Mail-Schutzes. Das Gateway schaltet sich per MX-Umleitung in den SMTP-Verkehr und blockiert vor der Zustellung; das API-native klinkt sich in den Tenant ein (Journaling oder API), analysiert nach Empfang und behebt nachträglich, ohne das DNS anzutasten.

Quellen

• Proofpoint Newsroom: Proofpoint Completes Acquisition of Hornetsecurity (1,8 Mrd. $, 8. Dezember 2025)
• Hornetsecurity: Onboarding Information (Europa), MX, SPF-Include, 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 und Pläne)
• Proofpoint: Launches Dedicated MSP Business Unit and Introduces 365 Total Protection for North America