Im Verkaufsgespräch klingt alles klar und einfach:
Eine moderne E-Mail-Security-Suite, Cloud-basiert, KI-gestützt, sofort einsatzbereit.
„Sie müssen nur die MX-Einträge anpassen – den Rest übernehmen wir.“
So oder so ähnlich beginnt fast jedes Einführungsprojekt.
Und tatsächlich: Die Testlizenz ist schnell aktiviert, die Konnektoren werden automatisch erstellt,
die ersten Mails laufen über das neue Gateway.
Ein beruhigendes Gefühl – die Security-Suite ist aktiv.
Aber ist es wirklich so einfach?
Leider nicht, die eigentliche Schutzwirkung entsteht erst durch eine präzise, verantwortungsvoll gesteuerte Einführung – nicht durch die Lizenz, sondern durch die Umsetzung im Detail.
Aus Führungssicht muss klar sein:
E-Mail-Security ist kein Produkt, das man kauft, sondern ein Prozess, der gesteuert werden muss.
Jemand muss die Verantwortung dafür tragen, dass alle sicherheitsrelevanten Maßnahmen wirklich umgesetzt, geprüft und dokumentiert sind.
Diese Verantwortung sollte vertraglich geregelt und operativ zugewiesen sein –
nicht implizit beim Lizenzanbieter vermutet werden.
Die folgenden Punkte bilden die Mindestanforderung an eine sichere E-Mail-Security-Implementierung.
Sie sind die Grundlage, um ein Projekt fachlich zu bewerten und Verantwortlichkeiten abzugleichen.
In der Praxis sind sie nur der Anfang – je nach Branche, Compliance-Vorgaben und Bedrohungslage
müssen oft weit umfangreichere Schutzmaßnahmen umgesetzt werden, die über die reine E-Mail-Security hinausgehen.
> Handlungsempfehlung:
Fragen Sie aktiv nach, wer in Ihrem Projekt die Verantwortung für die Umsetzung der folgenden Maßnahmen trägt
– und ob diese vertraglich, technisch und organisatorisch klar geregelt ist.
Nur dann ist die Lösung nicht nur implementiert, sondern wirklich sicher.
Standardkonfiguration: schnell eingerichtet, aber wirkungslos
Nach der Aktivierung sind Spam- und Virenscanner oft sofort aktiv.
Doch moderne Angriffe umgehen einfache Filter mühelos.
„Minimal Setup“ klingt nach Effizienz, bedeutet aber in Wahrheit minimale Sicherheit.
Ein sicherer E-Mail-Betrieb erfordert granulare Einstellungen und eine klare Einführungsstrategie.
Erst dann entfaltet eine Security-Suite ihre volle Wirkung.
Advanced Threat Protection (ATP): mehr als nur ein Häkchen
Wer glaubt, „ATP aktivieren“ reiche aus, unterschätzt heutige Angriffstaktiken.
Moderne Bedrohungen arbeiten mit zeitverzögerten Links, bösartigen Makros und gezieltem Social Engineering.
Darum müssen ATP-Funktionen bewusst und unternehmensspezifisch konfiguriert werden:
URL-Rewriting (Safe Links):
Links müssen beim Klick des Benutzers in Echtzeit überprüft werden („Time-of-Click“).
Eine einmalige Analyse beim Eingang ist wertlos, wenn die Zielseite erst später kompromittiert wird.
Sandboxing:
Anhänge sollten in einer sicheren Umgebung ausgeführt werden – bevor sie den Posteingang erreichen.
Risikogruppen (VAPs):
Geschäftsführung, Buchhaltung, Personalwesen – diese „Very Attacked Persons“ brauchen eigene, verschärfte Richtlinien.
Standard-Policies reichen hier nicht.
Inhalts- und Dateifilter:
Hochrisiko-Dateitypen müssen proaktiv blockiert werden insbesondere Office-Dokumente mit Makros und ausführbare Dateien sind beliebte Einfallstore.
Ein in der Praxis erprobte Sperrliste ist z.B.:
.appx, .appxbundle, .bat, .cmd, .com, .docm, .dotm, .exe, .hta, .htm, .html, .img, .iso, .jar, .js, .lnk, .msi, .msix, .msixbundle, .pif, .pptm, .ps1, .scr, .svg, .vbs, .vhd, .vmdk, .xlsm, .xltm
Nur wenn diese Dateien betrieblich erforderlich sind, dürfen sie zugelassen werden, in der Regel haben solche Dateien in E-Mailanhängen aber nichts zu suchen.
SPF, DKIM, DMARC: drei Einträge, nur alle zusammen bieten Schutz
Jede Domain, die E-Mails versendet, braucht korrekt konfigurierte Authentifizierungsmechanismen:
SPF: Listet alle Systeme auf, die im Namen der Domain senden dürfen – inklusive externer Tools wie Newsletter-Systeme, CRM oder HR-Plattformen.
DKIM: Signiert jede ausgehende Mail kryptografisch, stellt Integrität sicher.
DMARC: Verknüpft SPF und DKIM und gibt an, wie Empfänger mit Mails umgehen sollen, die diese Prüfungen nicht bestehen.
Wer DMARC weglässt, verliert doppelt, fehlendes DMARC bedeutet in Regel immer verborgene Fehler in der SPF und DKIM Konfiguration und noch schlimmer, es ist wie die Vergabe von Schlüsseln ohne Schloss, ohne DMARC wird ihre Domain von Betrügern genutzt, also warten sie nicht bis ihre Kunde reinfallen und eine gefälschte Rechnung bezahlen, sparen sie sich einen irrwitzigen Rechtsstreit in dem sich alle als Opfer fühlen und sie am Ende die Schuld bekommen.
Die Einführung von DMARC erfolgt schrittweise so dass der E-Mail betrieb nicht gestört wird:
p=none (Monitoring) → p=quarantine → p=reject.
Wer zu schnell auf „reject“ umstellt, riskiert legitime Mailverluste, je nach umfang der IT und Schatten IT kann eine Phase zu Sicherheit einige Monate laufen so dass jedes System zeit bekommt eine E-Mail korrekt konfiguriert zu senden bevor das Regelset scharf geschaltet wird.
Transportverschlüsselung mit MTA-STS
Auch wenn TLS Verschlüsslung bei E-Mails der Standard ist, ist es aus historischen Gründen optional. (In Fachsprache sagt man dazu STARTTLS ist opportunistisch und anfällig für Downgrade-Angriffe)
Erst MTA-STS (Mail Transfer Agent Strict Transport Security) erzwingt die Verschlüsslung und erlaubt nur authentifizierte TLS-Verbindungen (TLS ≥1.2), andernfalls wird die Zustellung verweigert.
Das schützt zuverlässig vor Man-in-the-Middle-Angriffen im Mailtransport.
Integration mit Microsoft 365 und Hornetsecurity
Die häufigste Fehlerquelle bei hybriden Umgebungen ist nicht die Lizenz, sondern die Kommunikation zwischen Gateway und Cloud.
Die Konnektoren zwischen Microsoft 365 und Hornetsecurity müssen über das automatische Setup hinaus konfiguriert werden. Dazu gehört im Defender die Einstellung dem Eingehenden Connector zu vertrauen und die IP für den SPF zu überspringen.
Falsch gesetzte Routingregeln führen dazu, dass Security-Policies umgangen oder doppelt angewendet werden.
Awareness-Trainings, Phishing-Simulationen oder Security-Kampagnen funktionieren nur, wenn Microsoft die Trainingsmails nicht als verdächtig markiert.
Dafür müssen auf der M365-Seite Vertrauensregeln (Safe Senders, Header-Ausnahmen, Transportregeln) gesetzt werden. Erst so erkennt Exchange Online Protection (EOP) die Simulationen als gewollt – statt sie zu blocken. Wer dies versäumt bekommt am Ende nur die Hälfte der Trainings-E-Mails und merkt vielleicht nicht mal das die Statistik ein falsches Bild zeichnet.
Compliance beginnt beim Routing
Archivierung bedeutet nicht automatisch Konformität. Nur wenn alle Kommunikationspfade – extern wie intern – durch den Security-Proxy laufen, kann eine lückenlose und revisionssichere Speicherung nach GoBD oder ISO 27001 erfolgen.
Falsch gesetzte Konnektoren führen dazu, dass ein Teil der Mails niemals im Archiv ankommt – und das fällt oft erst beim Audit auf. Daher wird im Folgenden auf das Routing eingegangen.
Interner Mailverkehr: Routing, Signatur und rechtssichere Archivierung
Ein häufig übersehener Punkt in Microsoft 365/Hornetsecurity-Umgebungen ist der interne Mailverkehr.
Viele gehen davon aus, dass interne Nachrichten weder durch das Gateway laufen noch archiviert werden müssen. Das ist falsch – und risikoreich.
Damit sowohl S/MIME-Signaturen oder Verschlüsselung als auch eine vollständige, rechtssichere Archivierung greifen, muss der interne Verkehr gezielt über den Security-Proxy geleitet werden. Dazu wird ein dedizierter Routing-Connector im Exchange-Transport eingerichtet, der alle internen Nachrichten (z. B. zwischen Mitarbeiterpostfächern) an das Gateway weiterleitet.
Der Proxy kann dort:
- fehlende S/MIME-Signaturen ergänzen oder prüfen,
- Verschlüsselung erzwingen,
- und die Nachrichten gleichzeitig in das Archivsystem übernehmen.
So entsteht ein vollständiges, nachvollziehbares E-Mail-Journal – auch für interne Kommunikation. Damit diese Verarbeitung fehlerfrei funktioniert, muss in Microsoft 365 bzw. im Exchange-Transport TNEF (Transport Neutral Encapsulation Format) deaktiviert werden.
Der folgende Powershell-Befehl deaktiviert TNEF in der ganzen Domain
Set-RemoteDomain -Identity Default -TnefEnabled $false
TNEF (oft auch unter „winmail.dat“ bekannt) kapselt E-Mail-Inhalte in ein proprietäres Format, das die Gateways nicht korrekt parsen oder signieren können.
Nur mit Routing des internen Verkehrs und der TNEF-Deaktivierung ist eine durchgängige Signatur-Policy und eine revisionssichere Archivierung garantiert.
Backup & Recovery
Viele moderne Suiten bieten Backup-Module für Microsoft 365, Teams, OneDrive und SharePoint.
Aber auch hier gilt: Aktivieren heißt nicht sichern.
Jede Datenquelle muss explizit eingebunden, die Wiederherstellung regelmäßig getestet und der Geltungsbereich dokumentiert werden.
Verantwortung klären – bevor etwas passiert
Technische Fehler sind selten – Prozessfehler sind die Regel. Wer ist verantwortlich für die Konfiguration? Wer prüft die Logs, wer reagiert auf DMARC-Reports, wer passt Richtlinien an?
Diese Punkte müssen vertraglich und organisatorisch geklärt werden. Sonst ist am Ende niemand zuständig, wenn etwas schiefgeht.
Awareness ist kein Selbstzweck
Phishing-Simulationen, Trainingsmodule, Klickstatistiken – all das bringt gar nichts, wenn der eigentliche Bedarf nicht verstanden wird. Mitarbeitende klicken nicht weniger, nur weil sie trainiert werden, sondern weil sie verstehen, warum ihr Handeln entscheidend ist.
Echte Risiko-Sensibilisierung entsteht erst, wenn klar ist, welche konkreten Folgen ein Angriff für das eigene Unternehmen hätte.
Trainings müssen technisch korrekt aufgesetzt sein – etwa durch Whitelisting der Awareness-Mails und Eintrag der Header-Regeln in Microsoft 365, damit die Nachrichten nicht von den eigenen Filtern blockiert werden. Nur so ist das Ergebnis realistisch – und das Lernen sinnvoll.
Fazit
Eine E-Mail-Security-Suite ist kein Plug-and-Play-Produkt. Sie ist ein System, das verstanden und richtig eingeführt werden muss, bevor es schützt. MX-Einträge und Lizenzen sind nur der Anfang.
Der Unterschied zwischen „installiert“ und „sicher“ liegt in der Erstkonfiguration – technisch präzise, organisatorisch sauber, mit klarem Verantwortungsbewusstsein.