ARC & SEG für All-Inkl — SpamAssassin und optionales SEG

All-Inkl ist ein eigenständiger DACH-Webhoster (Neue Medien Münnich GmbH) — der E-Mail-Schutz für All-Inkl-Postfächer wird im KAS (Kunden-Administrations-System) konfiguriert. Wie für Managed-Mail-Hosting typisch dokumentiert All-Inkl keine eigene ARC-Signierung; die ARC-Validierung übernimmt der empfangende Provider. SpamAssassin und der Virenfilter bilden die Basis-Inhaltsfilter-Schicht — kein Enterprise-SEG. Diese Anleitung zeigt Spam-Konfiguration, ARC-Strategie, optionales dediziertes SEG und Verifikation.

All-Inkl · Schritt für Schritt

ARC und SEG für All-Inkl-Postfächer

All-Inkl wird betrieben von der Neue Medien Münnich GmbH mit Hauptverwaltung in Friedersdorf und Rechenzentrum in Dresden — eigenständig, ohne Konzern-Bindung an United Internet oder IONOS Group SE. Für ARC gilt das, was für Managed-Mail-Hosting typisch ist: All-Inkl dokumentiert keine eigene ARC-Signierung beim Weiterleiten von Nachrichten. Die ARC-Validierung — das Auswerten einer ARC-Kette — findet beim empfangenden Provider statt, etwa bei Gmail oder Microsoft 365. Als Inhaltsfilter-Schicht bringt All-Inkl SpamAssassin (bewusst rudimentär konfiguriert) sowie einen Virenfilter mit.

Der integrierte Schutz von All-Inkl ist die Basis-Inhaltsfilter-Schicht, kein Enterprise Secure Email Gateway: Funktionen wie Multi-Engine-Sandboxing, URL-Rewriting mit Time-of-Click-Prüfung oder Impersonation Protection sind dort nicht enthalten. Dass All-Inkl SpamAssassin bewusst rudimentär konfiguriert ausliefert, verlagert die Schwellen-Feinjustage zum Kunden. Wer höheren Schutz benötigt, schaltet ein dediziertes SEG per MX-Umstellung vor — der MX-Record zeigt dann auf das Gateway statt auf w0XX[NODE].kasserver.com. Die offizielle All-Inkl-Anleitungen-Seite (all-inkl.com/wichtig/anleitungen, Abruf 2026-05-21) listet die E-Mail- und SpamAssassin-Anleitungen.

Hardening-Pfad: MX-RecordSPFDKIMDMARCDMARC-EnforcementMTA-STSDNS-Sicherheit → ARC & SEG (dieser Guide). Bedrohungs-Cluster: Ein SEG ist die zentrale technische Abwehr gegen Phishing, Business Email Compromise und gefährliche Anhänge.

ARC ist ein Experimental-Protokoll am Ende seines Lebenszyklus

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 (Stand 22. April 2026) empfiehlt, RFC 8617 als Historic einzustufen und von neuen Deployments abzuraten; als Nachfolger zeichnet sich DKIM2 ab. Für All-Inkl-Kunden ist das praktisch entspannt: Da All-Inkl ohnehin keine eigene ARC-Signierung anbietet, entstehen keine Migrationskosten. Wichtig bleibt eine saubere DMARC-Konfiguration — sie ist Voraussetzung sowohl für jede ARC-Auswertung beim Empfänger als auch für ein SEG.

1 Schritt 1 von 4

ARC- und SEG-Ausgangslage der All-Inkl-Domain prüfen

Bevor Sie etwas ändern, erheben Sie den Ist-Zustand: das MX-Pattern für die Stack-Detection, die DMARC-Policy als Voraussetzung der gesamten Authentifizierungs- und ARC-Kette und das ARC-Ergebnis im Header einer weitergeleiteten Test-Mail. Zeigt der MX-Record auf w0XX[NODE].kasserver.com, bedient All-Inkl Ihre Postfächer und es ist kein dediziertes SEG vorgeschaltet.

Terminal — MX, DMARC, ARC-Header Bestandsaufnahme
# All-Inkl-Mail-MX-Pattern prüfen (Stack-Detection)
dig MX ihre-domain.de +short
# Erwartet bei All-Inkl-Mail: 10 w0XX[NODE].kasserver.com.

# DMARC-Policy der eigenen Domain (Voraussetzung der gesamten Kette)
dig TXT _dmarc.ihre-domain.de +short
# Erwartet: v=DMARC1; p=quarantine; ... oder v=DMARC1; p=reject; ...

# ARC-Ergebnis im Header einer eingehenden, weitergeleiteten Mail
# (Webmail: Mail öffnen -> Quelltext anzeigen)
# Hinweis: ARC-Header werden vom EMPFANGENDEN Provider ausgewertet -
# All-Inkl dokumentiert keine eigene ARC-Signierung beim Weiterleiten.
grep -i "^Authentication-Results:" empfangene-mail.eml
# Erwartet bei intakter Kette: ...; arc=pass ...
Wo ARC wirklich geprüft wird

ARC ist ein Feature des E-Mail-Transports. Ein Managed-Hoster wie All-Inkl dokumentiert keine eigene ARC-Signierung beim Weiterleiten — relevant ist ARC daher dort, wo Ihre Mail ankommt. Senden Sie eine Test-Mail über eine Mailingliste an ein Gmail- oder Microsoft-365-Postfach, sehen Sie im Authentication-Results-Header, ob die empfangende Plattform arc=pass setzt. Für eine All-Inkl-Domain bedeutet das: Eine korrekte DMARC-Policy und sauberes SPF/DKIM sind die Stellschrauben, die Sie kontrollieren — ARC selbst läuft serverseitig beim Empfänger.

2 Schritt 2 von 4

Integrierten SpamAssassin- und Virenfilter im KAS konfigurieren

Den E-Mail-Schutz für All-Inkl-Postfächer konfigurieren Sie im KAS (kas.all-inkl.com). Öffnen Sie den Bereich E-Mail, wählen Sie das E-Mail-Postfach und aktivieren Sie dort SpamAssassin samt Score-Schwelle sowie den Virenfilter. Da All-Inkl SpamAssassin bewusst rudimentär ausliefert, justieren Sie die Schwelle selbst.

KAS — SpamAssassin + Virenfilter Konfiguration
# All-Inkl SpamAssassin und Virenfilter konfigurieren
# KAS (kas.all-inkl.com):
#   Menü "E-Mail" -> E-Mail-Postfach auswählen
#   -> "SpamAssassin" aktivieren / Schwelle (Score) einstellen
#   -> "Virenfilter" pro Postfach aktivieren
#
# Hinweis: All-Inkl liefert SpamAssassin bewusst rudimentär
# konfiguriert aus - die Schwellen-Feinjustage liegt beim Kunden.
#
# WICHTIG: SpamAssassin + Virenfilter sind die Basis-Inhaltsfilter-
# Schicht - kein Enterprise-SEG mit Sandboxing/URL-Rewriting.
SpamAssassin-Schwelle und Erwartungshaltung

SpamAssassin vergibt pro Mail einen Score; ab der eingestellten Schwelle gilt eine Nachricht als Spam. Eine niedrige Schwelle filtert aggressiver, riskiert aber False Positives — kalibrieren Sie sie anhand der real eingehenden Mail. Verstehen Sie diese Schicht aber realistisch: SpamAssassin ist ein regelbasiertes Filtersystem und bei All-Inkl bewusst rudimentär vorkonfiguriert. Gegen gezieltes Spear-Phishing oder Zero-Day-Anhänge braucht es Sandboxing und URL-Rewriting — Funktionen, die erst ein dediziertes Gateway liefert (Schritt 3).

3 Schritt 3 von 4

ARC-Strategie klären und optionales dediziertes SEG vorschalten

Hier wird ehrlich getrennt: All-Inkl signiert nicht ARC. Wenn Sie selbst Mail über Aliase oder Mailinglisten weiterleiten und diese ARC-versiegelt sein soll, brauchen Sie ARC-fähige Infrastruktur — einen eigenen MTA mit OpenARC oder eine Plattform wie Microsoft 365 beziehungsweise Google Workspace, die ARC nativ signiert. Für inhaltlichen Advanced-Threat-Schutz schalten Sie ein dediziertes SEG per MX-Umstellung vor.

Dediziertes SEG per MX-Umstellung — die Architektur

Ein SEG sitzt im Mailfluss vor dem Postfach: Der MX-Record zeigt auf das Gateway, das saubere Mail an All-Inkl weiterreicht und Bedrohungen in Quarantäne hält. Im DACH-Raum kommen dafür Hornetsecurity (Hannover, seit 8. Dezember 2025 Business Unit von Proofpoint), NoSpamProxy von Net at Work (Paderborn, inhabergeführt und unabhängig) oder Retarus (München, inhabergeführtes Familienunternehmen) infrage. Für die typische All-Inkl-Klientel mit Datensouveränitäts-Fokus ist die Eigentümerstruktur des SEG-Anbieters ein bewusstes Auswahlkriterium. Praktisch bedeutet die Umstellung: MX-Record im KAS-DNS-Editor auf das SEG ändern, im SEG den All-Inkl-Mailserver als Ziel-Relay hinterlegen. ARC bleibt davon unberührt — ein SEG filtert Inhalt, es signiert keine Weiterleitungskette.

Information-Gain: KAS-Panel SEG-Bypass-Risiken und Submission-Hardening

All-Inkls KAS-Panel (Konfigurations-Administrations-System) ist in der DACH-Szene wegen seiner Bedienungsfreundlichkeit beliebt — aber es erlaubt eine konkrete SEG-Bypass-Lücke, die wenig dokumentiert ist: Auch wenn der MX-Record per KAS auf ein dediziertes SEG zeigt, bleibt die SMTP-Submission über den Mailserver-Hostname w0XX[NODE].kasserver.com direkt erreichbar. Ein Angreifer, der die Postfach-Zugangsdaten kennt (Phishing-Beute oder Credential-Stuffing aus einem Datenleck), kann darüber Mails versenden, die ARC- und SEG-Validierung am Inbound vorbei umgehen — die ausgehende Submission läuft am SEG vorbei direkt aus All-Inkls Mailservern. Konkretes Hardening: (1) Im KAS unter E-Mail → Schutz alle ungenutzten POP3/IMAP-Zugänge deaktivieren — auch SMTP-Submission ist ein Login-Vektor. (2) 2FA für Webmail aktivieren (KAS unterstützt seit 2024 TOTP-basierte 2FA für Postfach-Zugänge). (3) Wo möglich: SMTP-Submission-Port (587) per iptables/Provider-Firewall auf das eigene Office-Netz beschränken — All-Inkl bietet das in den höheren Tarifen via dediziertem Server. (4) Audit-Log: Login-Versuche regelmäßig im KAS-Log prüfen, oder Mailserver-Logs per Wolf-Agents Email Security Monitoring 6-stündlich tracken. All-Inkl-Konzern: Neue Medien Münnich GmbH (Friedersdorf + Dresden), inhabergeführt — die direkte Erreichbarkeit für DACH-DE-souveräne Kunden ist ein bewusstes Auswahlkriterium.

4 Schritt 4 von 4

Verifikation per dig, Header-Analyse und Wolf-Agents Email Security Check

Prüfen Sie zuerst MX und DMARC erneut per dig. Senden Sie dann eine Test-Mail über eine Mailingliste an Ihr All-Inkl-Postfach und öffnen Sie den Quelltext: Der Authentication-Results-Header zeigt das ARC-Ergebnis des empfangenden Systems, die X-Spam-Header das SpamAssassin-Verdikt. Haben Sie ein SEG vorgeschaltet, muss der MX-Record auf das Gateway zeigen.

Verifikation — MX, DMARC, ARC-Header, SEG-MX Verifikation
# 1. MX- und DMARC-Status erneut bestätigen
dig MX ihre-domain.de +short
dig TXT _dmarc.ihre-domain.de +short

# 2. Test-Mail über eine Mailingliste / Weiterleitung an ein
#    All-Inkl-Postfach senden und den Quelltext öffnen.
# 3. Prüfen:
#    Authentication-Results: ...; arc=pass ...   (falls weitergeleitet)
#    X-Spam-Status / X-Spam-Score   (SpamAssassin-Verdikt)

# 4. Bei vorgeschaltetem dediziertem SEG: MX zeigt auf das SEG,
#    nicht mehr auf w0XX[NODE].kasserver.com.

# Wolf-Agents Email Security Check: erkennt das *.kasserver.com-MX-
# Pattern automatisch und prüft ARC-Detection plus SEG-Status.

Ergänzend prüfen Sie mit dem Wolf-Agents Email Security Check — dieser erkennt All-Inkl-Mail-Domains automatisch über das MX-Pattern *.kasserver.com, bewertet die ARC-Detection und gleicht die MX-Records gegen die SEG-Provider-Datenbank ab. Das Monitoring überwacht die E-Mail-Sicherheit alle 6 Stunden.

Häufige Fehler bei ARC & SEG für All-Inkl

SpamAssassin im KAS gar nicht aktiviert

Problem: Ein All-Inkl-Postfach erhält viel Spam, obwohl SpamAssassin verfügbar wäre. Ursache: SpamAssassin ist im KAS pro Postfach optional und nicht automatisch aktiv — All-Inkl liefert es zudem bewusst rudimentär konfiguriert aus. Lösung: Im KAS unter E-Mail SpamAssassin für das Postfach aktivieren und die Score-Schwelle anhand der real eingehenden Mail einstellen.

SpamAssassin mit einem SEG verwechselt

Problem: SpamAssassin wird als vollwertiges Secure Email Gateway betrachtet. Ursache: SpamAssassin ist ein regelbasierter Inhaltsfilter — ihm fehlen Sandboxing, URL-Rewriting und Impersonation Protection eines Enterprise-SEG. Lösung: SpamAssassin als Basis-Schicht verstehen und bei erhöhtem Schutzbedarf ein dediziertes SEG per MX-Umstellung vorschalten.

ARC-Signierung im KAS gesucht

Problem: Im KAS wird eine Einstellung für ARC-Signierung gesucht. Ursache: ARC ist ein Feature des Mail-Transfer-Agents — All-Inkl dokumentiert als Managed-Hoster keine eigene ARC-Signierung. Lösung: Akzeptieren, dass die ARC-Validierung beim Empfänger läuft; für eigene ARC-Signierung beim Weiterleiten einen MTA mit OpenARC oder eine ARC-fähige Plattform nutzen.

MX-Record nach SEG-Vorschaltung nicht auf das Gateway umgestellt

Problem: Ein SEG ist gebucht, der MX-Record zeigt aber weiterhin auf w0XX[NODE].kasserver.com — eingehende Mail erreicht das Gateway nie. Ursache: Vergessene MX-Umstellung im KAS-DNS-Editor. Lösung: Den MX-Record auf den vom SEG vorgegebenen Hostnamen ändern und All-Inkl als Ziel-Relay im SEG hinterlegen; mit dig MX ihre-domain.de +short verifizieren.

Compliance · NIS2 · BSI · DSGVO

Compliance: NIS2 lit. a + lit. d, BSI APP.5.3.A4, DSGVO mit Neue Medien Münnich GmbH

Ein vorgeschaltetes 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 — die Prüfung eingehender und ausgehender E-Mails samt Anhängen auf Spam-Merkmale und schädliche Inhalte. ARC sichert die Authentifizierungskette über Weiterleitungen ab und unterstützt damit lit. d (Sicherheit der Lieferkette); bei einer All-Inkl-Domain läuft diese Validierung beim empfangenden Provider. Die Neue Medien Münnich GmbH ist DSGVO-konform mit deutscher Datensouveränität (Friedersdorf + Dresden), ohne Konzern-Bindung an US-Provider.

All-Inkl-ARC-SEG-Compliance-Stack: NIS2 lit. a (SEG als Defense-in-Depth-Schicht) + NIS2 lit. d (ARC sichert die Forwarding-Lieferkette) + BSI IT-Grundschutz APP.5.3.A4 (Spam-/Schadsoftware-Prüfung) + DSGVO Art. 32 (Schutz personenbezogener Daten) + Neue Medien Münnich GmbH DE-Datensouveränität (Friedersdorf + Dresden). Wolf-Agents-USP: Der Email Security Check erkennt All-Inkl-Mail-Domains automatisch über das Pattern *.kasserver.com, bewertet ARC-Detection und SEG-Status im 165-Punkte-Scanner (ARC und SEG als je 5 Bonuspunkte) und weist transparent aus, dass API-basierte ICES-Lösungen für MX-basierte Erkennung unsichtbar bleiben. Cross-Verweis: Phishing, Business Email Compromise und gefährliche Anhänge.

Wie steht Ihre Domain bei ARC & SEG · All-Inkl?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.