ARC & SEG für Netcup — SpamAssassin und optionales SEG
Die Netcup GmbH ist ein eigenständiger DACH-Hoster mit Hauptsitz Nürnberg und Rechenzentren in Nürnberg und Wien — der E-Mail-Schutz wird im CCP (Customer Control Panel) und im WCP (Plesk) konfiguriert. Wie für Managed-Mail-Hosting typisch dokumentiert Netcup keine eigene ARC-Signierung; die ARC-Validierung übernimmt der empfangende Provider. Plesk-SpamAssassin und der netcup-eigene Spam-Filter bilden die Basis-Inhaltsfilter-Schicht — kein Enterprise-SEG. Diese Anleitung zeigt Spam-Konfiguration, ARC-Strategie, optionales dediziertes SEG und Verifikation.
ARC und SEG für Netcup-Postfächer
Die Netcup GmbH (Sitz Nürnberg) betreibt Rechenzentren in Nürnberg und Wien, DSGVO-konform mit deutscher/österreichischer Datensouveränität und ohne Konzern-Bindung an United Internet oder IONOS Group SE. Für ARC gilt das, was für Managed-Mail-Hosting typisch ist: Netcup 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 Netcup zwei Ebenen mit: Plesk-SpamAssassin pro E-Mail-Adresse im WCP und einen netcup-eigenen Spam-Filter pro Domain im CCP — Spam wird 30 Tage im Spam-Ordner aufbewahrt.
Der integrierte Schutz von Netcup 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. Wer höheren Schutz benötigt, schaltet ein dediziertes SEG per MX-Umstellung vor — der MX-Record zeigt dann auf das Gateway statt auf mx2[NODE].netcup.net. Die offizielle Netcup-Dokumentation (netcup-wiki.de, Abruf 2026-05-21) führt durch CCP-Bedienung, WCP-Plesk und die Spam-Einstellungen.
Hardening-Pfad: MX-Record → SPF → DKIM → DMARC → DMARC-Enforcement → MTA-STS → DNS-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 (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 Netcup-Kunden ist das praktisch entspannt: Da Netcup 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.
ARC- und SEG-Ausgangslage der Netcup-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 mx2[NODE].netcup.net, bedient Netcup Ihre Postfächer und es ist kein dediziertes SEG vorgeschaltet.
# Netcup-Mail-MX-Pattern prüfen (Stack-Detection)
dig MX ihre-domain.de +short
# Erwartet bei Netcup-Mail: 10 mx2[NODE].netcup.net.
# 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 -
# Netcup dokumentiert keine eigene ARC-Signierung beim Weiterleiten.
grep -i "^Authentication-Results:" empfangene-mail.eml
# Erwartet bei intakter Kette: ...; arc=pass ... ARC ist ein Feature des E-Mail-Transports. Ein Managed-Hoster wie Netcup 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 Netcup-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.
Plesk-SpamAssassin im WCP und den netcup-Spam-Filter im CCP konfigurieren
Netcup verteilt den Spam-Schutz auf zwei Panels. Im WCP (Plesk-basiert) aktivieren Sie pro E-Mail-Adresse SpamAssassin samt Score-Schwelle. Im CCP (ccp.netcup.net) aktivieren Sie zusätzlich den netcup-eigenen Spam-Filter pro Domain — erkannter Spam landet 30 Tage im Spam-Ordner.
# Netcup Spam-Schutz konfigurieren - zwei Ebenen
# 1) Plesk-SpamAssassin pro E-Mail-Adresse im WCP:
# WCP (Plesk) -> "E-Mail" -> Adresse -> Tab "Spam-Filter"
# -> SpamAssassin aktivieren / Score-Schwelle einstellen
#
# 2) netcup-eigener Spam-Filter pro Domain im CCP:
# CCP (ccp.netcup.net) -> Domain -> Mail-/Spam-Einstellungen
# -> domainweiten Spam-Filter aktivieren
# Spam landet im Spam-Ordner, Aufbewahrung 30 Tage.
#
# WICHTIG: SpamAssassin + netcup-Spam-Filter sind die Basis-
# Inhaltsfilter-Schicht - kein Enterprise-SEG mit Sandboxing. Die beiden Netcup-Ebenen ergänzen sich: Der CCP-Spam-Filter wirkt domainweit, der WCP-SpamAssassin pro Adresse mit individueller Score-Schwelle. Eine zu 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, der netcup-Spam-Filter eine Domain-Ebene davor. Gegen gezieltes Spear-Phishing oder Zero-Day-Anhänge braucht es Sandboxing und URL-Rewriting — Funktionen, die erst ein dediziertes Gateway liefert (Schritt 3).
ARC-Strategie klären und optionales dediziertes SEG vorschalten
Hier wird ehrlich getrennt: Netcup 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.
Ein SEG sitzt im Mailfluss vor dem Postfach: Der MX-Record zeigt auf das Gateway, das saubere Mail an Netcup 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. Wer mit Netcup auf DE-Datensouveränität setzt, prüft auch beim SEG-Anbieter die Eigentümerstruktur. Eine technische Alternative: Statt Netcup-Webhosting-Mail einen Netcup-vServer mit eigenem Mailserver betreiben — bei Mailcow übernimmt der mitgelieferte Rspamd-Container die ARC-Signierung (nicht OpenARC, siehe ARC & SEG für Mailcow); für einen reinen Postfix-Stack wird OpenARC als Milter ergänzt (siehe ARC & SEG für Postfix). Praktisch bedeutet die SEG-Umstellung: MX-Record im CCP-DNS-Tab auf das SEG ändern, im SEG den Netcup-Mailserver als Ziel-Relay hinterlegen. ARC bleibt davon unberührt — ein SEG filtert Inhalt, es signiert keine Weiterleitungskette.
Netcups CCP-Spam-Filter (sowie der Plesk-SpamAssassin im WCP) ist ein regelbasierter Basis-Inhaltsfilter: Bayessche Spam-Erkennung, RBL-Lookups gegen bekannte Spammer-Listen, Header-Heuristiken. Was er nicht hat: Multi-Engine-Anti-Malware-Scanning, KI-/ML-basierte Phishing-Analyse, Sandboxing von Anhängen, URL-Rewriting mit Time-of-Click-Prüfung, Impersonation Protection. Wann reicht der CCP-Spam-Filter: KMU unter ungefähr 50 Mitarbeitern ohne KRITIS-Status, ohne branchenspezifische Regulierung (BaFin/DORA, Heilberufe-Geheimnis, KRITIS-VO), ohne dokumentierten Phishing-Vorfall in den letzten 24 Monaten, mit korrekter DMARC-Enforcement-Policy (p=quarantine oder p=reject) und mit aktiver Mitarbeiter-Schulung sind in der Regel ausreichend geschützt. Wann braucht es ein dediziertes SEG: NIS2-Betroffenheit ab essential/important (in DE rund 30.000 Unternehmen seit dem NIS2UmsuCG, in AT ab 1. Oktober 2026 rund 4.000 Unternehmen via NISG 2026 BGBl. I Nr. 94/2025), branchenspezifische Compliance-Pflichten (BAIT/VAIT/DORA für Finanzbranche, KBV/KZBV-Anforderungen im Gesundheitswesen), hohes E-Mail-Volumen (> 10.000 ext. Mails/Tag), Multi-Cloud-Umgebungen oder ein nachweisliches Phishing-/BEC-Vorkommnis in der jüngeren Vergangenheit. NIS2-Kontext: Auch ohne formale NIS2-Pflicht ist ein dediziertes SEG die messbare Umsetzung der BSI-IT-Grundschutz-Anforderung APP.5.3.A4 („Spam- und Schadsoftware-Prüfung auf dem E-Mail-Server“) — eine zentrale Risikomanagement-Maßnahme nach NIS2 Art. 21 Abs. 2 lit. a.
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 Netcup-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.
# 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
# Netcup-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 mx2[NODE].netcup.net.
# Wolf-Agents Email Security Check: erkennt das *.netcup.net-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 Netcup-Mail-Domains automatisch über das MX-Pattern *.netcup.net, 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 Netcup
Spam-Schutz nur im CCP oder nur im WCP konfiguriert
Problem: SpamAssassin wird im WCP eingerichtet, der domainweite Filter im CCP bleibt aus — oder umgekehrt. Ursache: Netcup verteilt den Spam-Schutz auf zwei Panels (Plesk-SpamAssassin pro Adresse, netcup-Filter pro Domain). Lösung: Beide Ebenen aktivieren — den netcup-Spam-Filter im CCP pro Domain und SpamAssassin im WCP pro E-Mail-Adresse.
Netcup-Spam-Filter mit einem SEG verwechselt
Problem: Der integrierte Netcup-Spam-Schutz wird als vollwertiges Secure Email Gateway betrachtet. Ursache: SpamAssassin und der netcup-Filter sind regelbasierte Inhaltsfilter — ihnen fehlen Sandboxing, URL-Rewriting und Impersonation Protection eines Enterprise-SEG. Lösung: Den Netcup-Schutz als Basis-Schicht verstehen und bei erhöhtem Schutzbedarf ein dediziertes SEG per MX-Umstellung vorschalten.
ARC-Signierung im CCP oder WCP gesucht
Problem: In CCP oder WCP wird eine Einstellung für ARC-Signierung gesucht. Ursache: ARC ist ein Feature des Mail-Transfer-Agents — Netcup 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 einen Netcup-vServer mit MTA und 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 mx2[NODE].netcup.net — eingehende Mail erreicht das Gateway nie. Ursache: Vergessene MX-Umstellung im CCP-DNS-Tab. Lösung: Den MX-Record auf den vom SEG vorgegebenen Hostnamen ändern und Netcup als Ziel-Relay im SEG hinterlegen; mit dig MX ihre-domain.de +short verifizieren.
Compliance: NIS2 lit. a + lit. d, BSI APP.5.3.A4, DSGVO mit netcup 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 Netcup-Domain läuft diese Validierung beim empfangenden Provider. Die Netcup GmbH (Sitz Nürnberg) betreibt Rechenzentren in Nürnberg und Wien — DSGVO-konform mit deutscher/österreichischer Datensouveränität, ohne Konzern-Bindung an United Internet oder IONOS Group SE.
Netcup-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) + Netcup DE/AT-Datensouveränität (Nürnberg/Wien). Wolf-Agents-USP: Der Email Security Check erkennt Netcup-Mail-Domains automatisch über das Pattern *.netcup.net, 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.
ARC- und SEG-Anleitung für weitere Provider:
Wie steht Ihre Domain bei ARC & SEG · Netcup?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.