ARC & SEG: Authenticated Received Chain und Secure Email Gateway
Dieses Kapitel deckt zwei fortgeschrittene Bausteine der E-Mail-Sicherheit ab. ARC (Authenticated Received Chain, RFC 8617) hält die Authentifizierungskette bei Mailinglisten, Alias- und Forwarding-Szenarien intakt — damit eine DMARC-Policy mit p=reject keine legitimen weitergeleiteten E-Mails ablehnt. Ein Secure Email Gateway (SEG) ergänzt SPF/DKIM/DMARC um eine inhaltliche Filterschicht gegen Phishing, Malware und Zero-Day-Angriffe. Mit DACH-SEG-Marktüberblick 2026, OpenARC-Anleitung und Schritt-für-Schritt-Konfiguration für 16 Provider in 5 Kategorien.
ARC: Wie die Authentifizierungskette eine Weiterleitung überlebt
ARC (Authenticated Received Chain) ist ein in RFC 8617 definiertes Verfahren, das die ursprünglichen Authentifizierungsergebnisse einer E-Mail über jede Weiterleitung hinweg konserviert. Jeder weiterleitende Mailserver — ein sogenannter Intermediary — signiert und versiegelt die geprüften SPF-, DKIM- und DMARC-Ergebnisse, bevor er die Nachricht weitergibt. Der finale Empfänger kann der Kette vertrauen, selbst wenn SPF und DKIM durch die Weiterleitung gebrochen sind.
Das Problem, das ARC löst, kennt jeder Administrator mit konsequenter DMARC-Enforcement-Policy: Eine korrekt konfigurierte Domain mit p=reject lehnt plötzlich legitime E-Mails von Mailinglisten ab. SPF bricht bei jeder Weiterleitung, weil SPF die IP-Adresse des letzten sendenden Servers prüft — und der Mailinglisten-Server hat eine andere IP als die im SPF-Record autorisierten Server. DKIM bricht oft zusätzlich, wenn die Liste den Betreff verändert (etwa ein [Liste]-Präfix voranstellt) oder einen Footer anhängt. Wenn weder SPF noch DKIM aligned bestehen, scheitert DMARC — und p=reject verwirft die Nachricht.
Hardening-Pfad: MX-Records → SPF → DKIM → DMARC → DMARC-Enforcement → MTA-STS → DNS-Sicherheit → ARC & SEG (dieses Kapitel). Bedrohungs-Cluster: Ein SEG ist die zentrale technische Abwehr gegen Phishing, Business Email Compromise und gefährliche Anhänge.
Die drei ARC-Header und der Chain Validation Status
; Die drei ARC-Header (RFC 8617) in einer weitergeleiteten E-Mail
; gesetzt vom weiterleitenden Mailserver (Intermediary) — i=1 = erster Hop
ARC-Authentication-Results: i=1; mx.beispiel-liste.org;
spf=pass smtp.mailfrom=absender.de;
dkim=pass header.d=absender.de;
dmarc=pass header.from=absender.de
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=beispiel-liste.org; s=arc2026; t=1747800000;
h=from:to:subject:date:message-id; bh=BASE64_BODY_HASH;
b=BASE64_SIGNATURE
ARC-Seal: i=1; a=rsa-sha256; cv=none;
d=beispiel-liste.org; s=arc2026; t=1747800000; b=BASE64_SEAL
; AAR ARC-Authentication-Results — speichert SPF/DKIM/DMARC-Ergebnis
; AMS ARC-Message-Signature — signiert die Nachricht (DKIM-ähnlich)
; AS ARC-Seal — versiegelt AAR + AMS + bisherige Kette
;
; cv=none erster Hop, keine vorherige Kette
; cv=pass alle vorherigen ARC-Sets gültig
; cv=fail Kette gebrochen — ARC-Ergebnis wird verworfen
Jeder Intermediary fügt ein vollständiges ARC-Set aus drei Headern hinzu. Die Instance-Nummer i= ist eine Ganzzahl, beginnt bei 1 und wird pro Station inkrementiert — RFC 8617 erlaubt Werte von 1 bis 50. Der ARC-Seal trägt das entscheidende cv=-Feld (Chain Validation): cv=none markiert den ersten Hop, cv=pass bestätigt eine intakte Kette, cv=fail bedeutet einen Bruch — danach verwirft der empfangende Server die gesamte ARC-Kette und fällt auf das reguläre DMARC-Ergebnis zurück. Wichtig: ARC-Vertrauen ist nicht transitiv — der Empfänger prüft nur, ob er dem direkten Sealer vertraut.
ARC-Zukunft: Experimental-Status, Reklassifizierung als Historic, Nachfolger DKIM2
ARC ist ehrlich einzuordnen: RFC 8617 trägt seit der Veröffentlichung im Juli 2019 den IETF-Status Experimental — kein Standards-Track-Dokument. Das Working-Group-Dokument draft-ietf-dmarc-arc-to-historic der IETF DMARC-Arbeitsgruppe (Stand 22. April 2026) empfiehlt, RFC 8617 als Historic einzustufen, „to conclude the experiment and discourage new deployments of it“ — das rund zehnjährige Experiment, ein Internet-weites Reputationssystem für Intermediäre zu etablieren, gilt als gescheitert. Als Nachfolger zeichnet sich DKIM2 ab, das die IETF DKIM-Arbeitsgruppe seit März 2026 bearbeitet und das die Weiterleitungsproblematik nativ im Signaturmodell adressiert. Praxis-Empfehlung: Bestehende ARC-Konfigurationen weiter betreiben — Google, Microsoft 365 und Yahoo werten ARC aktiv aus, und für laufende Forwarding-Szenarien gibt es derzeit keinen Ersatz. Aber keine umfangreichen Neuinvestitionen in ARC-Infrastruktur tätigen und die DKIM2-Entwicklung beobachten.
ARC-Standard-Lebenszyklus 2019–2027 und konkreter DKIM2-Migrationspfad
Wer 2026 in ARC investiert, sollte den vollständigen Standard-Lebenszyklus kennen — denn die Spannungslage zwischen produktivem Nutzen heute und Historic-Klassifizierung morgen ist Strategie-relevant. Der Werdegang im Detail: Juli 2019 Veröffentlichung von RFC 8617 als Experimental — kein Standards Track. 2020–2022 rollen Google (als Mitentwickler) und Microsoft 365 (seit 2019), gefolgt von Yahoo, eine native ARC-Validierung produktiv aus; Mailinglisten-Hoster und Forwarder beginnen mit Sealing. 2023–2025 reift die Self-Hosted-Welt nach: Exim 4.91+ bringt ARC nativ (Compile-Flag EXPERIMENTAL_ARC mit arc_sign/arc_verify), Mailcow integriert ARC im Rspamd-Container, der flowerysong/OpenARC-Fork v1.3.0 wird am 29. Oktober 2025 mit verbesserter Microsoft-Comment-Parser-Kompatibilität veröffentlicht.
2026 Q2 die Wende: Die IETF DMARC-Arbeitsgruppe veröffentlicht am 22. April 2026 draft-ietf-dmarc-arc-to-historic und konsolidiert vier Gründe für die Reklassifizierung — (1) das vorausgesetzte Internet-weite Reputationssystem für Intermediäre hat nicht skaliert (in der Praxis entstanden nur statische Allow-Lists einzelner ARC-Sealer wie bei Microsofts Trusted ARC Sealers), (2) der Betriebsaufwand für Reputationspflege ist zu hoch, (3) ARC erkennt nur, dass eine Nachricht verändert wurde — nicht welche Felder, und (4) die strukturelle Forwarding-Schwäche (IP-Wechsel bricht SPF) bleibt ungelöst. Parallel arbeitet die IETF DKIM-Arbeitsgruppe seit März 2026 an DKIM2: draft-ietf-dkim-dkim2-spec liegt am 17. Mai 2026 in Version 02 vor, Autoren sind Richard Clayton (Yahoo), Wei Chuang (Google) und Bron Gondwana (Fastmail). DKIM2 integriert „ARC's useful elements“ in ein moderneres Signatur-Modell mit „stronger binding of message context“ — und adressiert das Replay-Problem von DKIM gleich mit.
Migrationspfad mit konkretem Empfehlungs-Schema: (1) 2026 weiterhin ARC produktiv betreiben — für aktuelles Forwarding und für Microsoft 365 Trusted ARC Sealers gibt es keinen Ersatz. (2) Keine Neuinvestitionen in ARC-Infrastruktur (etwa Mailing-Listen-Migration zu eigenständigem ARC-Sealer ohne ICES-Vorhandensein). (3) DKIM2-Spec verfolgen — die Reife-Indikatoren sind: Standards Track (vs Experimental), Test-Implementierungen bei Google/Microsoft/Fastmail (Autoren-Affiliation lässt produktive Pilotierung in Q3/Q4 2026 erwarten), erste Library-Implementierungen. (4) Bestandsschutz dokumentieren: Im Risikomanagement nach NIS2 Art. 21 Abs. 2 lit. a sollten ARC-betreibende Organisationen den Standard-Lebenszyklus protokollieren — das ist Stand der Technik, nicht Software-Ende.
Quellen: datatracker.ietf.org/doc/draft-ietf-dmarc-arc-to-historic (Stand 22. April 2026), datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec (v02 vom 17. Mai 2026, Autoren Clayton/Chuang/Gondwana), github.com/flowerysong/OpenARC/releases (v1.3.0, 29. Oktober 2025). Alle drei Quellen am 23. Mai 2026 verifiziert.
Secure Email Gateway: Die Inhaltsfilter-Schicht vor dem Postfach
Ein Secure Email Gateway (SEG) ist eine dedizierte Sicherheitslösung, die dem eigentlichen Mailserver vorgeschaltet wird und den gesamten ein- und ausgehenden E-Mail-Verkehr inhaltlich filtert. Während SPF, DKIM und DMARC die Authentizität des Absenders prüfen, analysiert ein SEG den Inhalt — mit Anti-Phishing, Anti-Malware, Sandboxing, URL-Rewriting und Data Loss Prevention. Ein SEG ergänzt die Authentifizierung, es ersetzt sie nicht.
Architektonisch sitzt ein SEG im Mail-Fluss zwischen Internet und Mailserver: Der MX-Record der Domain zeigt auf das SEG, das saubere E-Mails an den eigentlichen Mailserver weiterreicht und Bedrohungen in Quarantäne verschiebt. Dieses Prinzip — mehrere unabhängige Schutzschichten statt einer einzigen — ist Defense-in-Depth. Das BSI fordert es im IT-Grundschutz-Baustein APP.5.3 als Basis-Anforderung. Ein SEG schützt vor Bedrohungsklassen, die reine Authentifizierung nicht abdeckt: Advanced Persistent Threats (APT), KI-generiertes Spear-Phishing und Zero-Day-Malware in Anhängen.
Kernfunktionen eines Secure Email Gateway
| Funktion | Aufgabe | Schutz gegen |
|---|---|---|
| Anti-Phishing | Analyse von Absender, URLs und Inhalt mit KI/ML | Credential-Diebstahl, BEC |
| Anti-Malware | Multi-Engine-Scanning mit mehreren AV-Engines | Viren, Trojaner, Ransomware |
| Sandboxing | Ausführung verdächtiger Anhänge in isolierter Umgebung | Zero-Day-Malware |
| URL-Rewriting | Ersetzt Links durch Proxy-URLs, prüft beim Klick erneut | Time-of-Click-Phishing |
| Data Loss Prevention | Erkennt sensible Daten in ausgehenden E-Mails | Datenlecks, Fehlversand |
| Impersonation Protection | Erkennt Domain-Lookalikes und Display-Name-Spoofing | CEO-Fraud, Lieferantenbetrug |
SEG, ICES oder nativer Schutz? Drei Architekturansätze stehen zur Wahl. Das klassische SEG erfordert eine MX-Record-Änderung und filtert inline vor der Zustellung. ICES (Integrated Cloud Email Security) bindet sich per API an Microsoft 365 oder Google Workspace an, ändert keine MX-Records und analysiert auch interne E-Mails nach der Zustellung — Anbieter wie Abnormal, Check Point Harmony Email (vormals Avanan), Ironscales und Material Security sind daher in MX-Records nicht sichtbar. Der native Schutz der Cloud-Plattformen ist bereits integriert. In der Praxis konvergieren die Modelle zunehmend — viele Anbieter bieten sowohl Inline- als auch API-Modi an.
DACH-SEG-Anbieter 2026: Konsolidierung und die Frage der Souveränität
Der DACH-Markt für Secure Email Gateways hat sich 2025 deutlich konsolidiert. Der in Hannover gegründete Marktführer Hornetsecurity wurde am 8. Dezember 2025 für 1,8 Milliarden US-Dollar vollständig von Proofpoint übernommen — der zuvor größte unabhängige deutsche SEG-Anbieter ist seitdem eine US-Konzern-Tochter. Genuin unabhängig und inhabergeführt sind 2026 noch Net at Work mit NoSpamProxy aus Paderborn und Retarus aus München.
Für Unternehmen mit strengen Datensouveränitäts-Anforderungen ist die Eigentümerstruktur relevant: Hornetsecurity gehört über die Kette Hornetsecurity GmbH → Proofpoint Inc. → Thoma Bravo zu einem US-Private-Equity-Konzern — die Datenhaltung kann damit potenziell dem US CLOUD Act unterliegen, unabhängig vom Rechenzentrumsstandort Hannover. Net at Work positioniert sich aktiv als unabhängige, ausschließlich in Deutschland entwickelte Alternative.
DACH-SEG-Anbieter und ihre Eigentümerstruktur (Stand 21. Mai 2026)
| Anbieter | Sitz | Eigentümerstruktur |
|---|---|---|
| Hornetsecurity (365 Total Protection) | Hannover | Seit 8. Dezember 2025 Business Unit von Proofpoint Inc. (USA); Proofpoint gehört Thoma Bravo |
| NoSpamProxy (Net at Work GmbH) | Paderborn | Inhabergeführt, ohne Investoren — nach eigener Angabe „IT-Sicherheit Made in Germany“ |
| Retarus (Email Security) | München | Inhabergeführtes Familienunternehmen, 1992 von Martin Hager gegründet |
| eXpurgate (vormals eleven) | Berlin | Seit 16. September 2025 als Halon Security GmbH Teil des schwedischen Anbieters Halon |
Hinweis: Das Berliner Unternehmen eleven (Produkt eXpurgate) durchlief mehrere Eigentümerwechsel — eleven (gegründet 2004) wurde 2014 zu Cyren, nach der Cyren-Insolvenz Anfang 2023 von der Content Services Group herausgekauft und im September 2025 vom schwedischen Anbieter Halon übernommen; es firmiert seitdem als Halon Security GmbH, die Marke „eleven“ wurde aufgelöst.
Marktführerschaft sachlich einordnen
Belastbare, DACH-spezifische Marktanteilsstudien für Secure Email Gateways sind öffentlich kaum verfügbar — eine dedizierte ISG Provider Lens oder Lünendonk-Studie nur für „Email Security DACH“ existiert nicht. Belegbar ist: Die Radicati-Analyse „Secure Email — Market Quadrant 2025“ (publiziert im März 2025) stuft Hornetsecurity global als „Top Player“ ein; das ist ein weltweiter, kein regionaler Report. Hornetsecurity galt vor der Übernahme als der reichweitenstärkste in Deutschland gegründete Cloud-E-Mail-Security-Anbieter. Eine konkrete DACH-Marktanteils-Prozentzahl lässt sich seriös nicht belegen — Wolf-Agents verzichtet bewusst auf erfundene Marktzahlen.
SEG-Auswahl-Matrix DACH-vs-International: vier Pfade mit Souveränitäts-Tag
Die SEG-Auswahl 2026 lässt sich auf vier Entscheidungspfade mit klarem Souveränitäts-Profil verdichten — und für DACH-Unternehmen mit datenschutzrechtlicher Sensibilität ist der ehemals naheliegende Pfad „Hornetsecurity als DACH-Marktführer“ seit der Proofpoint-Übernahme am 8. Dezember 2025 nicht mehr DACH-souverän. Wer einen MSP-/SMB-Fokus braucht und die US-Konzern-Anbindung akzeptiert, bleibt bei Hornetsecurity unter Proofpoint — Daniel Hofmann führt die Hornetsecurity-Business-Unit weiter als „executive vice president and general manager“ der MSP Platform bei Proofpoint (laut Proofpoint-Pressemitteilung vom 8. Dezember 2025). Wer Datenhaltung explizit außerhalb des US CLOUD Act will, wählt einen anderen Pfad.
| Pfad | Anbieter / Anlauf | Souveränitäts-Tag | Wann passend? |
|---|---|---|---|
| 1. DACH-inhabergeführt | NoSpamProxy (Net at Work, Paderborn) oder Retarus (München, seit 1992) | kein US-Konzern, kein US-PE, „IT-Security Made in Germany“ (NoSpamProxy) bzw. „Echt europäisch“ (Retarus) | KRITIS, BSI-Hochsensibel, BaFin/DORA, Schweizer Kunden mit Anti-CLOUD-Act-Mandat |
| 2. EU-Mutter mit DE-Tochter | Halon Security GmbH (Berlin, Friedrichstrasse 171, seit 16. September 2025) — Mutter Halon AB, Göteborg/Schweden | EU-Sitz Mutter und Tochter, kein US-CLOUD-Act | EU-Souveränität ohne strikte DACH-Bindung, MTA-Plattform mit Operator-Fokus |
| 3. US-Konzern mit DACH-Reichweite | Hornetsecurity (Hannover, seit 8.12.2025 Proofpoint-Business-Unit; 1,8 Mrd. USD) — bzw. Proofpoint/Mimecast direkt | US-Eigentümer, potenziell CLOUD-Act-betroffen — Datenhaltung in EU-Rechenzentren möglich, aber Konzern-Zugriff strukturell möglich | MSP/SMB-Fokus, breites Bundle (365 Total Protection), internationale Konzern-Integration |
| 4. Nativ statt SEG | Microsoft Defender for Office 365 (Plan 1/2) oder Google Workspace Security Sandbox + ggf. ICES-Aufsatz (Abnormal, Check Point Harmony Email, Material Security) | Cloud-Konzern (USA), aber ohne zusätzliche Drittlösung — EU Data Boundary (Microsoft) bzw. EU-Region (Google) | KMU mit M365/Google Workspace, regulatorisch ausreichend, kein dediziertes SEG verlangt |
Praxisregel: Wenn der CLOUD-Act-relevante Datenfluss (Mail-Inhalt, Header, Threat-Telemetrie) Vertragsgegenstand mit Kunden/Auftraggebern ist — etwa bei Berufsgeheimnisträgern (Recht/Heilkunde/Steuer) oder im Behördenumfeld — fallen Pfad 3 und in vielen Fällen auch Pfad 4 aus, weil Microsoft Defender und Google Workspace Security trotz EU Data Boundary US-Konzern-Eigentum sind. Konkret übrig bleiben dann Pfad 1 (NoSpamProxy/Retarus) und Pfad 2 (Halon). Wolf-Agents wertet diese Eigentums-Struktur im Scanner-Bericht transparent aus — der Scanner-Analyzer (siehe Plattform-Komponente src/lib/email-security/analyzers/seg.ts) führt Hornetsecurity nach der Proofpoint-Übernahme nicht mehr als „Made in Germany - BSI-zertifiziert“, sondern als „Proofpoint-Tochter seit 8. Dezember 2025“.
Quellen: proofpoint.com/us/newsroom/press-releases (Closing 8.12.2025), nospamproxy.de/produkt, retarus.com/de/services/secure-email-platform, halon.io/about. Alle vier Quellen am 23. Mai 2026 verifiziert.
DACH-SEG-Anbieter-Konzern-Mapping (Stand Mai 2026)
Vergleichs-Matrix der 4 DACH-SEG-Anbieter mit Eigentums-Tags und CLOUD-Act-Indikator. Hornetsecurity ist seit 8.12.2025 Proofpoint-Business-Unit (Thoma Bravo via Proofpoint seit 2021, 1,8 Mrd. USD Closing). NoSpamProxy + Retarus inhabergeführt. Halon Security GmbH unter Schweden-Mutter seit 16.9.2025.
Internationale SEG-Anbieter und der Gartner Magic Quadrant 2025
Der internationale Markt für Secure Email Gateways wird von acht großen Anbietern dominiert: Microsoft Defender for Office 365, Google Workspace, Proofpoint, Mimecast, Cisco, Barracuda, Sophos, Trend Micro und Fortinet. Auffällig ist die Eigentümerkonzentration — fast alle dieser Anbieter befinden sich im Besitz von Private-Equity-Häusern. Der Wolf-Scanner erkennt diese Gateways automatisch an charakteristischen Mustern in den MX-Records.
Internationale SEG-Anbieter — Konzern und MX-Muster
| Anbieter | Konzern / Eigentümer | MX-Muster |
|---|---|---|
| Microsoft Defender for Office 365 | Microsoft Corporation (USA) | *.mail.protection.outlook.com |
| Google Workspace | Google LLC / Alphabet Inc. (USA) | smtp.google.com, aspmx.l.google.com |
| Proofpoint | Thoma Bravo (US-Private-Equity, seit August 2021) | *.pphosted.com |
| Mimecast | Permira (Private Equity, seit Mai 2022) | *.mimecast.com |
| Cisco Secure Email | Cisco Systems Inc. (USA) | *.iphmx.com |
| Barracuda Networks | KKR (US-Private-Equity, seit August 2022) | *.barracudanetworks.com |
| Sophos | Thoma Bravo (US-Private-Equity, seit März 2020) | *.sophos.com |
| Trend Micro | Trend Micro Inc. (Japan, börsennotiert Tokio) | *.tmes.trendmicro.com |
| Fortinet FortiMail | Fortinet Inc. (USA, Sunnyvale) | kundenspezifisch |
Gartner Magic Quadrant for Email Security: Gartner veröffentlichte am 1. Dezember 2025 die aktuelle Ausgabe — und kürzte den Titel gegenüber 2024 von „Magic Quadrant for Email Security Platforms“ auf „Magic Quadrant for Email Security“. Die Verkürzung spiegelt die Konvergenz von klassischen SEGs und API-basierten ICES-Lösungen wider. Als Leader werden Proofpoint, Microsoft, Check Point, Abnormal AI und KnowBe4 geführt; Fortinet stieg zum Challenger auf. Sophos und Cisco befinden sich seit 2020 (Sophos: Thoma Bravo) beziehungsweise dauerhaft (Cisco) in einer Konsolidierungsdynamik, die den gesamten Markt prägt.
SEG-Wirksamkeit realistisch bewerten — keine Marketing-Prozentzahlen
Anbieter bewerben SEGs gern mit Abwehrquoten wie „99 Prozent aller Bedrohungen gestoppt“. Solche Zahlen sind irreführend: Sie beziehen sich meist auf Spam-Erkennung, wo hohe Raten trivial sind, nicht auf gezielte Angriffe wie Spear-Phishing oder Business Email Compromise. Eine neutrale, belastbare Branchenzahl für die SEG-Abwehrrate existiert nicht — die Wirksamkeit hängt stark vom Anbieter, der Konfiguration und dem Bedrohungstyp ab. Ein SEG ist eine sinnvolle zusätzliche Schutzschicht im Defense-in-Depth-Konzept, aber kein Allheilmittel. Wolf-Agents bewertet ein erkanntes SEG daher als Bonus, nicht als Ersatz für korrekte SPF/DKIM/DMARC-Konfiguration.
SEG-Marktstudien 2026: drei belastbare Quellen, zwei verbreitete Mythen, ein DACH-spezifischer Negativ-Befund
Wer den SEG-Markt 2026 für eine fundierte Entscheidung einordnen will, sollte drei belastbare Studien kennen — und zwei verbreitete Mythen aktiv vermeiden.
Belastbare Quellen sind:
- Gartner Magic Quadrant for Email Security — publiziert am 1. Dezember 2025 mit dem im Vergleich zu 2024 verkürzten Titel (zuvor „Magic Quadrant for Email Security Platforms“). Die Verkürzung spiegelt die Konvergenz von Inline-SEG und API-ICES wider. Leaders 2025: Proofpoint, Microsoft, Check Point, Abnormal AI, KnowBe4. Fortinet stieg zum Challenger auf.
- Radicati Secure Email Market Quadrant 2025 — publiziert im März 2025, vierteilige Anbieter-Klassifikation (Top Players / Trail Blazers / Mature Players / Specialists). Hornetsecurity wird vor der Proofpoint-Übernahme als „Top Player“ geführt.
- Forrester Wave: Enterprise Email Security — sofern aktuelle 2025/2026-Ausgabe verfügbar; ältere Ausgaben sind nicht für die aktuelle Marktdynamik aussagekräftig. Hier ist Stichtags-Hygiene Pflicht.
Verbreitete Mythen, die in Anbieter-Materialien gelegentlich begegnen:
- „SEGs stoppen 99 Prozent aller Bedrohungen“ — unbelegbar als Branchenzahl; bezieht sich meist auf trivial hohe Spam-Erkennung, nicht auf gezielte Angriffe.
- „Kosten erfolgreichen Phishings übersteigen SEG-Jahreskosten um das 10- bis 100-fache“ — als FBI-IC3- oder IBM-Mittelwert anhaltend zitiert, aber als pauschaler ROI-Faktor unbelegt. Realistische Schadensspannen variieren kontextabhängig stark.
DACH-spezifischer Negativ-Befund: Es existiert keine dedizierte Lünendonk-Studie und keine ISG Provider Lens nur für „Email Security DACH“ — das ist nicht ein Daten-Loch, sondern eine bewusste Lücke zwischen Lünendonk (DACH IT-Beratung/Outsourcing) und ISG (international, Cloud/Workplace). Wer in einem Vertrieb-Pitch eine „DACH-SEG-Lünendonk-Studie“ zitiert hört, sollte präzise nach der Original-URL fragen — sehr wahrscheinlich ist eine andere, sektorübergreifende Studie gemeint. Wolf-Agents zitiert in dieser Anleitung bewusst keine erfundene DACH-Marktanteilszahl und stützt die Anbieter-Empfehlung stattdessen auf live-verifizierte Eigentumsstruktur (siehe SEG-Auswahl-Matrix oben) und auf die Eigenangabe der Anbieter („Made in Germany“/„Echt europäisch“).
Quellen: Gartner Pressemitteilung Magic Quadrant for Email Security 1. Dezember 2025 (Titel-Umbenennung gegenüber 2024), Radicati Group „Secure Email — Market Quadrant 2025“ (März 2025). Beide Studien sind ohne Gartner-/Radicati-Subscription nicht im Volltext verfügbar, die Headline-Aussagen sind aber öffentlich zitiert. Eine Lünendonk- oder ISG-Studie speziell für „Email Security DACH“ existiert nach Live-Recherche am 23. Mai 2026 nicht.
OpenARC: ARC-Signierung für selbst gehostete Mailserver
Anders als BIMI ist ARC ein echtes MTA-Feature: Ein selbst gehosteter Mailserver, der E-Mails weiterleitet, signiert ARC-Ketten direkt im Mail-Transfer-Agent. Für Postfix übernimmt das OpenARC — eine Open-Source-Implementierung, die als Milter eingebunden wird. Exim bringt ARC ab Version 4.91 nativ mit. OpenARC läuft also tatsächlich in der Server-Konfiguration, nicht nur im DNS.
Wichtig bei der Quellenwahl: Das ursprüngliche OpenARC-Repository des Trusted Domain Project ist seit 2018 inaktiv und kam nie über einen Beta-Status hinaus. Aktiv gepflegt wird ausschließlich der Community-Fork flowerysong/OpenARC, aktuell in Version 1.3.0 (Oktober 2025). Dieser Fork wird aus dem Quellcode mit den GNU Autotools gebaut (autoreconf -fiv, ./configure, make). Ein stabiles Debian- oder Ubuntu-Paket existiert Stand Mai 2026 noch nicht — ein ITP-Bug für die Paketierung von OpenARC 1.3.0 ist eingereicht, apt-get install openarc funktioniert in den stabilen Releases aber noch nicht.
OpenARC als Milter — Grundkonfiguration
# OpenARC v1.3.0 (flowerysong-Fork) — /etc/openarc.conf
# ARC IST ein MTA-Feature: OpenARC läuft als Milter am Postfix.
Mode sv # s=sign, v=verify
Canonicalization relaxed/relaxed
Domain example.com
Selector arc2026
KeyFile /etc/openarc/keys/arc2026.private
SignHeaders from:to:subject:date:message-id
Socket inet:8893@localhost
Syslog yes
# Postfix-Anbindung in /etc/postfix/main.cf — nach OpenDKIM:
# smtpd_milters = inet:localhost:8891, inet:localhost:8893
OpenARC wird wie OpenDKIM als Milter über einen Socket an Postfix angebunden — die Reihenfolge in smtpd_milters ist entscheidend: erst OpenDKIM, dann OpenARC. Die vollständigen, copy-paste-fertigen Anleitungen für die drei Self-Hosted-Stacks finden Sie auf den Provider-Seiten: ARC & SEG für Postfix (OpenARC-Milter, flowerysong-Fork), ARC & SEG für Exim (natives arc_sign ab 4.91) und ARC & SEG für Mailcow (Rspamd-Container, nicht OpenARC).
NIS2- und BSI-Konformität durch ARC und ein SEG
Ein Secure Email Gateway zahlt direkt auf NIS2 Art. 21 Abs. 2 lit. a ein — die Richtlinie verlangt dort wörtlich „Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme“. Eine vorgeschaltete Inhaltsfilter-Schicht ist die klassische Defense-in-Depth-Umsetzung dieses Konzepts. ARC sichert zusätzlich die Authentifizierungskette über Weiterleitungen und Drittanbieter ab und unterstützt damit lit. d (Sicherheit der Lieferkette).
ARC und SEG in regulatorischen Rahmenwerken
| Rahmenwerk | ARC-Bezug | SEG-Bezug |
|---|---|---|
| NIS2 Art. 21 Abs. 2 lit. a | Teil des Sicherheitskonzepts für E-Mail-Authentifizierung | Direkt — Defense-in-Depth-Schutzschicht im Sicherheitskonzept |
| NIS2 Art. 21 Abs. 2 lit. d | Sichert E-Mail-Ketten über Dritte (Lieferkette) | Filtert Vendor-Email-Compromise und Lieferanten-Betrug |
| BSI IT-Grundschutz APP.5.3.A4 | Nicht einschlägig (Transport- und Auth-Thema) | Direkt — Spam- und Schadsoftware-Prüfung auf dem E-Mail-Server (Basis-Anforderung) |
| DSGVO Art. 32 | Wahrt die Integrität der Verarbeitung bei Weiterleitung | Schützt personenbezogene Daten vor Phishing-bedingtem Abfluss |
| BAIT / DORA | Stützt die mehrschichtige E-Mail-Sicherheit | Finanzbranche: mehrschichtige E-Mail-Sicherheit gefordert |
Ehrliche Einordnung zum BSI: Die BSI-IT-Grundschutz-Anforderung APP.5.3.A4 fordert wörtlich, dass „auf E-Mail-Servern eingehende und ausgehende E-Mails, insbesondere deren Anhänge, auf Spam-Merkmale und schädliche Inhalte überprüft werden“ — das ist exakt die Aufgabe eines SEG und eine Basis-Anforderung im Baustein „Allgemeiner E-Mail-Client und -Server“. Die E-Mail-Authentifizierung normiert das BSI separat in der Technischen Richtlinie TR-03182 über SPF, DKIM und DMARC; ARC selbst ist als IETF-Experimental-Protokoll weder in TR-03182 noch in der Transport-Richtlinie TR-03108 erfasst. ARC sollte daher nicht als „BSI-empfohlen“ dargestellt werden — es ist eine sinnvolle, aber nicht normierte Ergänzung.
Wie Wolf-Agents ARC und SEG prüft
Der Wolf-Agents Email Security Check prüft eine Domain auf 165 Punkte — ARC und SEG zählen darin als reine Bonuspunkte: 5 Punkte für erkannte ARC-Unterstützung, 5 Punkte für ein erkanntes Secure Email Gateway. Fehlende ARC- oder SEG-Erkennung führt zu keinen Punktabzügen und beeinflusst keine Grade Caps — diese Punkte belohnen Organisationen, die über die Basis-Authentifizierung hinaus investieren.
Was der Scanner konkret erkennt: Die ARC-Detection prüft auf ARC-Signierung und ARC-Validierung in der E-Mail-Infrastruktur (Check arc-present). Die SEG-Stack-Detection gleicht die MX-Records gegen eine Datenbank bekannter SEG-Provider ab und erkennt charakteristische Muster wie *.pphosted.com (Proofpoint), *.iphmx.com (Cisco) oder *.mimecast.com (Mimecast) — unterschieden nach Enterprise- und Business-Tier (Check seg-detected). Ehrliche Grenze: API-basierte ICES-Lösungen erscheinen nicht in MX-Records und sind für jeden externen Scanner unsichtbar — Wolf-Agents weist diesen blinden Fleck im Befund transparent aus, statt einen falschen Eindruck zu erwecken. Prüfen Sie Ihre Domain im Email Security Check. Cross-Verweis: Phishing, Business Email Compromise, DMARC-Enforcement als Voraussetzung der gesamten Hardening-Kette und Alias-Strategie als Identitäts-Schutz pro externem Dienst (Cloudflare Email Routing als nachgewiesen ARC-Sealing-fähiger Forwarding-Dienst, SimpleLogin als Proton-Tochter-Privacy-Layer).
Häufig gestellte Fragen
Was ist ARC und welches Problem löst es?
ARC (Authenticated Received Chain) ist ein in RFC 8617 definiertes Verfahren, das die ursprünglichen Authentifizierungsergebnisse einer E-Mail bei einer Weiterleitung konserviert. Das Problem: SPF bricht bei jeder Weiterleitung, weil der weiterleitende Server eine andere IP hat; DKIM bricht, wenn eine Mailingliste Betreff oder Body verändert. Dann scheitert DMARC, und eine p=reject-Policy lehnt legitime E-Mails ab. Jeder weiterleitende Mailserver (Intermediary) signiert mit ARC die geprüften Originalergebnisse, sodass der Empfänger der Kette vertrauen kann.
Was ist ein Secure Email Gateway (SEG)?
Ein Secure Email Gateway ist eine Sicherheitslösung, die dem eigentlichen Mailserver vorgeschaltet wird und den gesamten E-Mail-Verkehr inhaltlich filtert. Während SPF, DKIM und DMARC die Authentizität des Absenders prüfen, analysiert ein SEG den Inhalt: Anti-Phishing, Anti-Malware mit mehreren Scan-Engines, Sandboxing verdächtiger Anhänge, URL-Rewriting und Data Loss Prevention. Ein SEG ist die technische Umsetzung des Defense-in-Depth-Konzepts, das das BSI im IT-Grundschutz-Baustein APP.5.3 fordert.
Brauche ich ARC und SEG, wenn ich Microsoft 365 oder Google Workspace nutze?
ARC ist bei Microsoft 365 und Google Workspace bereits nativ integriert — beide validieren eingehende ARC-Ketten und signieren weitergeleitete E-Mails automatisch. Für ein dediziertes SEG gilt: Der integrierte Schutz von Microsoft Defender for Office 365 oder Google Workspace ist für die meisten kleinen und mittleren Unternehmen ausreichend. Ein zusätzliches dediziertes SEG lohnt sich vor allem bei KRITIS-Betreibern, in der Finanz- und Gesundheitsbranche sowie bei sehr hohem E-Mail-Volumen.
Wird ARC noch weiterentwickelt — lohnt sich der Aufwand 2026 noch?
ARC (RFC 8617) trägt seit der Veröffentlichung im Juli 2019 den IETF-Status Experimental. Das Working-Group-Dokument draft-ietf-dmarc-arc-to-historic der IETF DMARC-Arbeitsgruppe (Stand 22. April 2026) empfiehlt, RFC 8617 als Historic einzustufen und von neuen Internet-weiten Deployments abzuraten. Als Nachfolger zeichnet sich DKIM2 ab (IETF-Arbeitsgegenstand seit März 2026). Praxis-Empfehlung: Bestehende ARC-Konfigurationen weiter betreiben, da Google, Microsoft und Yahoo ARC aktiv auswerten — aber keine umfangreichen Neuinvestitionen mehr tätigen.
Welche Secure-Email-Gateway-Anbieter gibt es 2026 im DACH-Raum?
Der in Hannover gegründete Anbieter Hornetsecurity (Produkt 365 Total Protection) wurde am 8. Dezember 2025 vollständig von Proofpoint übernommen und ist seitdem eine US-Konzern-Tochter. Genuin unabhängig und inhabergeführt sind 2026 noch Net at Work mit NoSpamProxy (Paderborn) und Retarus (München). Das Berliner Unternehmen eleven (Produkt eXpurgate) gehört seit September 2025 zum schwedischen Anbieter Halon. International führend sind Proofpoint, Microsoft, Mimecast, Cisco, Barracuda, Sophos, Trend Micro und Fortinet.
Braucht jedes Unternehmen ein dediziertes SEG?
Nein. Für kleine und mittlere Unternehmen mit Microsoft 365 oder Google Workspace ist der integrierte Schutz in der Regel ausreichend — wichtiger ist zuerst eine korrekte SPF-, DKIM- und DMARC-Konfiguration mit Enforcement-Policy. Ein dediziertes SEG empfiehlt sich bei KRITIS-Betreibern (NIS2, BSI-KRITIS-Verordnung), in der BaFin-regulierten Finanzbranche (DORA), im Gesundheitswesen, bei hohem E-Mail-Volumen, in Multi-Cloud-Umgebungen oder nach vorangegangenen Phishing-Vorfällen.
Erfüllen ARC und ein SEG Anforderungen aus NIS2 und dem BSI-Grundschutz?
Ein Secure Email Gateway zahlt direkt auf NIS2 Art. 21 Abs. 2 lit. a ein (Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme) und setzt die BSI-IT-Grundschutz-Basis-Anforderung APP.5.3.A4 um (Spam- und Schadsoftware-Prüfung auf dem E-Mail-Server). ARC sichert die Authentifizierungskette über Weiterleitungen und Drittanbieter ab und unterstützt damit zusätzlich lit. d (Sicherheit der Lieferkette). ARC selbst ist ein IETF-Experimental-Protokoll und in den BSI-Richtlinien TR-03108 und TR-03182 nicht normiert.
ARC- und SEG-Anleitung für Ihren Provider:
Wie steht Ihre Domain bei ARC & SEG — erweiterte E-Mail-Sicherheit?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.