DMARC Enforcement für Netcup

Schritt-für-Schritt-Roadmap: vom Beobachtungs-Modus (p=none) über Quarantäne (p=quarantine) zu Reject (p=reject) — mit sp=reject Subdomain-Override und Netcup-spezifischen Hinweisen zu Tarif-Drift und externem DMARC-Reporting.

DMARC-Policy prüfen Plattform entdecken
Netcup · Enforcement-Roadmap
Von Wolf-Agents Security Team · Aktualisiert: 13. Mai 2026

DMARC Enforcement bei Netcup (DACH-DE Managed Webhosting)

Netcup bietet kein natives DMARC-Dashboard — Sie müssen entweder ein Postfach für die rua-Reports anlegen oder ein externes Tool (dmarcian, Postmark DMARC, EasyDMARC) einbinden. Die DMARC-Policy-Verschärfung von p=none auf p=reject erfordert disziplinierte Beobachtung der Reports, eine schrittweise pct-Erhöhung und einen separaten sp=-Tag für Subdomains, weil sonst Subdomain-Spoofing als Angriffsweg offen bleibt.

Netcup-Webhosting nutzt zentrale Mail-Server (Hostname-Pattern mxXXXX.netcup.net) mit dem dokumentierten Default-SPF v=spf1 mx a include:_spf.webhosting.systems ~all und automatisch rotierenden DKIM-CNAMEs auf webhosting.systems. Beide sind alignment-konform mit der Header-From-Domain — DMARC kann darauf aufbauen. Falls Sie DMARC noch nicht aktiviert haben, starten Sie mit der DMARC-Anleitung für Netcup.

Der Wolf-Agents Email Security Scanner prüft Ihre aktuelle DMARC-Policy-Stufe, validiert den pct-Wert gegen die p=-Policy, markiert den fehlenden sp=-Subdomain-Override explizit als Risiko-Punkt und erkennt SPF-Drift nach Netcup-Tarif-Wechseln. Wolf-Agents Stack Detection findet außerdem Provider-Wechsel beim Lieferanten oder bei eigenen Sub-Diensten — verlinkt zu VEC (Vendor Email Compromise) und SubdoMailing.

Für NIS2-pflichtige Unternehmen mit Netcup-Infrastruktur ist p=none keine ausreichende Compliance. NIS2 Art. 21 Abs. 2 lit. b (Bewältigung von Sicherheitsvorfällen) bindet Enforcement direkt an aktive Spoofing-Vorfälle — DMARC-Reports zeigen den Vorfall, p=reject beendet ihn. Zusätzlich NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung): Die kryptografische Authentifizierung der SPF-/DKIM-Infrastruktur wird durch p=reject erst durchsetzbar. Das BSI empfiehlt p=reject in der TR-03108. Bei NIS2 Art. 23 Meldepflichten (24h-Frühwarnung, 72h-Vorfallsmeldung, 1-Monats-Abschlussbericht) sind DMARC-Aggregate-Reports forensisch verwertbar.

Ausführliche DMARC Enforcement Roadmap

1 Phase 1 von 4

Beobachtungsphase bei Netcup

Beginnen Sie mit p=none — das blockiert nichts, aber empfangende Server senden täglich XML-Aggregate-Reports an Ihre rua-Adresse. 2-4 Wochen Reports zeigen Ihnen, welche Sender Ihre Domain im Header-From verwenden. Sie identifizieren so vergessene Marketing-Tools, Cron-Skripte oder externe Anwendungen.

DMARC-Record Phase 1 (Netcup CCP DNS) Phase 1 
Host:        _dmarc
Typ:         TXT
Destination: v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de; ruf=mailto:dmarc-reports@ihre-domain.de; fo=1; pct=100

Setup-Schritte im Netcup CCP

  1. Im Netcup Mail-Panel das Postfach dmarc-reports@ihre-domain.de anlegen — sonst bouncen alle Reports
  2. Im CCP unter Domains → Lupe → DNS den TXT-Record mit Host _dmarc erstellen
  3. DNS Records speichern und nach 10 Min mit dig _dmarc.ihre-domain.de TXT +short verifizieren
  4. Über 2-4 Wochen tägliche XML-Reports parsen — entweder manuell mit dmarc-parser oder über ein Tool wie dmarcian
2 Phase 2 von 4

Quarantäne-Phase mit pct-Erhöhung

Nach 2-4 Wochen sauberer Reports (alle Sender identifiziert, alle DKIM-Signaturen valide) wechseln Sie auf p=quarantine; pct=10. Das bedeutet: Empfänger verschieben 10% der nicht-konformen Mails in den Spam-Ordner. Über 1-2 Wochen erhöhen Sie schrittweise auf pct=100. Ergänzen Sie den sp=quarantine-Tag — sonst gilt die Policy nur für die Hauptdomain, Subdomains bleiben offen für Spoofing.

DMARC-Record Phase 2 (Netcup CCP DNS) Phase 2 
# Tag 1 — pct=10
Destination: v=DMARC1; p=quarantine; sp=quarantine; pct=10; rua=mailto:dmarc-reports@ihre-domain.de; fo=1

# Tag 7 — pct=25
Destination: v=DMARC1; p=quarantine; sp=quarantine; pct=25; rua=mailto:dmarc-reports@ihre-domain.de; fo=1

# Tag 14 — pct=50
Destination: v=DMARC1; p=quarantine; sp=quarantine; pct=50; rua=mailto:dmarc-reports@ihre-domain.de; fo=1

# Tag 21 — pct=100
Destination: v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc-reports@ihre-domain.de; fo=1
sp=-Tag explizit anlegen

Ohne sp=-Tag fällt die Subdomain-Policy auf p= zurück — bis Sie p=quarantine setzen, bleibt die Subdomain offen für Direct-Subdomain-Spoofing wie SubdoMailing. Setzen Sie sp=quarantine oder direkt sp=reject früh, da Subdomains seltener von legitimen Sendern verwendet werden und das Risiko minimal ist.

3 Phase 3 von 4

Reject-Phase und Full-Enforcement

Nach 2-4 Wochen p=quarantine; pct=100 ohne neue Anomalien wechseln Sie auf p=reject. Empfänger lehnen nicht-konforme Mails dann direkt mit SMTP-Status 550 DMARC policy ab — die Zustellung wird verhindert, der Spam-Ordner umgangen. Starten Sie wieder mit pct=10 und erhöhen Sie schrittweise.

DMARC-Record Phase 3 (Netcup CCP DNS) Phase 3 
# Tag 1 — pct=10
Destination: v=DMARC1; p=reject; sp=reject; pct=10; rua=mailto:dmarc-reports@ihre-domain.de; fo=1

# Tag 14 — pct=50
Destination: v=DMARC1; p=reject; sp=reject; pct=50; rua=mailto:dmarc-reports@ihre-domain.de; fo=1

# Tag 28 — Final
Destination: v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@ihre-domain.de; fo=1; ri=86400

Mit p=reject; sp=reject; pct=100 ist Ihre Domain DMARC-konform nach BSI TR-03108 und NIS2-Stand-der-Technik geschützt. Der ri=86400-Tag setzt das Reporting-Intervall auf 24 Stunden (Default ist ri=86400, explizit ist klarer).

4 Phase 4 von 4

Monitoring etablieren

DMARC-Enforcement ist kein „set and forget“. Nach Erreichen von p=reject; pct=100 bleibt das kontinuierliche Monitoring nötig — neue Sender (Marketing-Kampagnen, Cron-Skripte, vergessene Mail-Skripte) können DMARC fehlschlagen, und ein Tarif-Wechsel bei Netcup kann den SPF-Default überschreiben.

Monatliche Monitoring-Aufgaben

  1. Aggregate-Reports auswerten: Anteil der Mails mit dmarc=pass vs. dmarc=fail trenden. Neue Sender im source_ip-Feld identifizieren
  2. SPF-Drift prüfen: Nach Netcup-Tarif-Wechseln (Webhosting → vServer) ändert sich der korrekte SPF-Record fundamental. Mit dig TXT ihre-domain.de +short | grep "v=spf1" auf doppelte Records prüfen
  3. DKIM-CNAME-Status: Bei DNS-Provider-Wechsel sicherstellen, dass key1._domainkey und key2._domainkey CNAMEs aktiv bleiben
  4. Wolf-Agents Scanner monatlich: 165-Punkte-Analyse inklusive DMARC-Policy, sp=-Tag, BIMI-Bereitschaft und Stack-Detection für externe Versender
  5. Forensik bei Vorfall: Bei einem aktiven Spoofing-Vorfall (BEC, CEO-Phishing) die Aggregate-Reports der letzten 30 Tage als NIS2-Art.-23-Meldung-Belege aufbereiten
Standard-DNS-Einstellung als laufende Vorbedingung (Information-Gain)

Die Netcup-Doku warnt explizit, dass das Standard-DNS-Setup für SPF/DKIM-Auflösung über _spf.webhosting.systems und key1/key2._domainkey.webhosting.systems nur funktioniert, „when default DNS settings are used and emails are sent exclusively via the product's mail server.“ Ein Wechsel von Standard-DNS auf eigene Records (z.B. nach DNS-Provider-Migration zu Cloudflare) kann SPF/DKIM-Drift auslösen — dann schlägt DMARC mit p=reject sofort fehl. Bei jedem DNS-Provider-Wechsel den Default-Status im CCP prüfen oder die SPF/DKIM-Records explizit auf den neuen DNS-Provider migrieren. Quelle: netcup.com/en/helpcenter/documentation/web-hosting/webhosting-dns (abgerufen 2026-05-13).

DNSSEC im CCP aktivieren (Information-Gain Welle 2)

Netcup unterstützt DNSSEC für alle Tarife — die Aktivierung erfolgt im Customer Control Panel über das Kontrollkästchen „DNSSEC Status“ im DNS-Tab der Domain. DNSSEC bringt für DMARC keinen direkten Mehrwert (die DMARC-Validierung läuft über den Header-From-Domain-Lookup), aber sie ist die Voraussetzung für DANE/TLSA (RFC 7672) bei künftigen Transport-Hardenings (z.B. wenn Sie zu vServer/Root-Server mit eigenem Mailserver migrieren). Die Änderung kann bis zu 48 Stunden weltweit propagieren. Quelle: netcup.com/en/helpcenter/documentation/domain/dnssec (abgerufen 2026-05-13).

Häufige Fehler beim Netcup-Enforcement

Diese drei Fehler treten bei der Netcup-spezifischen DMARC-Enforcement-Roadmap besonders häufig auf — jeder einzelne kann Enforcement aushebeln oder legitime Sender unbeabsichtigt blockieren.

Direkt p=reject ohne Beobachtungsphase

Problem: „Ich kenne meine Sender, ich starte direkt mit p=reject“ führt regelmäßig dazu, dass legitime Mails (Cron-Skripte, alte Marketing-Tools, Helpdesk-Systeme) sofort bei allen Empfängern bouncen — bevor die Reports überhaupt einlaufen, sind Mails verloren. Bei Netcup kommt hinzu, dass der Standard-SPF nur ~all (SoftFail) hat, was Empfänger toleranter macht — bei direktem p=reject kollidiert das Setup.

Lösung: Strikt die 4-Phasen-Roadmap einhalten. Phase 1 (p=none) mindestens 2 Wochen, Phase 2 (p=quarantine) schrittweise von pct=10 auf pct=100, dann Phase 3 (p=reject) ebenfalls schrittweise. Insgesamt 6-8 Wochen für sichere Umstellung.

sp=-Tag vergessen — Subdomain bleibt offen

Problem: Der DMARC-Record enthält p=reject, aber kein sp=. Standardmäßig fällt die Subdomain-Policy bei nicht existierendem sp= auf p= zurück — das wäre korrekt. Bei Netcup-Webhosting werden aber häufig nur eine handvoll Subdomains tatsächlich für E-Mail genutzt — alle anderen sind für Spoofing-Angriffe wie SubdoMailing offen. Guardio Labs hat 2024 über 8.000 Marken-Subdomains aufgedeckt, die für solche Angriffe missbraucht wurden.

Lösung: sp=reject explizit setzen — die Subdomain ist dann ohne eigene SPF/DKIM-Konfiguration komplett für Spoofing geschützt. Falls Sie tatsächlich Sub-Sender brauchen (z.B. news.ihre-domain.de für Marketing), legen Sie auf der Subdomain einen eigenen DMARC-Record an mit eigener Policy.

SPF-Default ~all nicht auf -all gehärtet

Problem: Der Netcup-Webhosting-Default-SPF endet auf ~all (SoftFail) — Empfänger tolerieren bei ~all auch nicht-autorisierte Sender und markieren die Mail nur als verdächtig. Bei p=reject ist der DMARC-Schutz aber an die SPF/DKIM-Auswertung gebunden — eine SoftFail-Bewertung führt häufig zu dmarc=fail mit spf=softfail, was inkonsistent ist und manche Empfänger irritiert.

Lösung: Nach 2 Wochen sauberer DMARC-Reports den SPF von ~all auf -all härten: v=spf1 mx a include:_spf.webhosting.systems -all. Erst dann ist die SPF/DKIM/DMARC-Kette vollständig kompatibel mit p=reject.

NIS2, BSI TR-03108 und DSGVO Art. 32: Enforcement bei Netcup

DMARC-Enforcement schließt den Sender-Authentifizierungs-Kreislauf — ohne p=reject liefert SPF/DKIM nur eine technische Information, die der Empfänger ignorieren darf. NIS2 Art. 21 Abs. 2 lit. b (Bewältigung von Sicherheitsvorfällen) bindet Enforcement direkt an laufende Spoofing-Vorfälle als reaktive Schutzmaßnahme. NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung) macht die Authentifizierungs-Infrastruktur überhaupt erst durchsetzbar. BSI TR-03108 empfiehlt p=reject als Mindeststandard. DSGVO Art. 32 fordert technische Maßnahmen zur Sicherheit der Verarbeitung — eine durchsetzbare Policy verhindert Identitätsmissbrauch der Domain für Daten-Phishing oder BEC-Angriffe. NIS2 Art. 23 schreibt 24h-Frühwarnung, 72h-Vorfallsmeldung und 1-Monats-Abschlussbericht vor — DMARC-Aggregate-Reports liefern die Forensik-Datenbasis für alle drei Fristen. Wolf-Agents prüft explizit den sp=-Tag der DMARC-Policy — fehlender Subdomain-Override = Risiko-Punkt-Markierung im 165-Punkte-Scan, verlinkt zu SubdoMailing.

DMARC-Enforcement-Roadmap auch für:

Microsoft 365Google WorkspaceIONOSStratoAll-InklHetznerPostfixEximMailcowGenerisch

Wie steht Ihre Domain bei DMARC Enforcement?

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

E-Mail Security Check starten