DMARC Enforcement für Hostpoint
Schritt-für-Schritt-Roadmap: vom Beobachtungs-Modus (p=none) über Quarantäne (p=quarantine) zu Reject (p=reject) — mit sp=reject Subdomain-Override, Hostpoint-spezifischen Hinweisen zur Auto-Aktivierung ab August 2024, externem DMARC-Reporting und NIS2 Art. 23 Belegbarkeit.
DMARC Enforcement bei Hostpoint (Schweiz Managed Webhosting)
Hostpoint aktiviert DMARC seit August 2024 für neue Webhosting- und Cloud-Office-Domains automatisch — mit einer Start-Policy. Die Verschärfung auf p=quarantine und p=reject bleibt jedoch in Ihrer Verantwortung. Hostpoint bietet kein natives DMARC-Reporting-Dashboard — Sie müssen entweder ein Postfach für die rua-Reports anlegen oder ein externes Tool (dmarcian, Postmark DMARC, EasyDMARC) einbinden. Disziplinierte Beobachtung der Reports, schrittweise pct-Erhöhung und ein separater sp=-Tag für Subdomains sind Pflicht.
Hostpoint-Webhosting nutzt zentral verwaltete Mail-Server mit dem dokumentierten Default-SPF v=spf1 redirect=spf.mail.hostpoint.ch und automatisch rotierenden DKIM-Schlüsseln. 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 Hostpoint.
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, wenn der redirect=-Mechanismus nach einer Migration nicht mehr auflöst. 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 Hostpoint-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. Schweizer Datenschutzrecht: revDSG Art. 8 fordert geeignete technische Maßnahmen zur Datensicherheit. Bei NIS2 Art. 23 Meldepflichten (24h-Frühwarnung, 72h-Vorfallsmeldung, 1-Monats-Abschlussbericht) sind DMARC-Aggregate-Reports forensisch verwertbar — auch für Schweizer Unternehmen mit EU-Geschäft.
Schweizer revDSG Art. 8 + EU DSGVO Art. 32 + NIS2 — Doppel-Compliance für CH-Provider
Drei-Lanes-Compliance-Diagramm: Lane 1 Schweizer revDSG (in Kraft 1.9.2023, Art. 8 TOM, Art. 9 Auftragsbearbeitung, Schweizer Datensouveränität ohne CLOUD-Act), Lane 2 EU DSGVO (in Kraft 25.5.2018, Art. 32 Sicherheit der Verarbeitung, Art. 28 Auftragsverarbeiter, Art. 33/34 Meldepflichten), Lane 3 NIS2 (Pflicht 18.10.2024 in DE, Art. 21 Abs. 2 lit. h Kryptografie + lit. b Vorfallsbewältigung, Art. 23 Meldefristen). Überschneidungs-Zone: TOM-Pflichten fachlich gleichwertig. Provider-Anker: Hostpoint AG Rapperswil-Jona + Infomaniak Network SA Genf + Proton AG Genf Plan-les-Ouates.
Beobachtungsphase bei Hostpoint
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.
Host: _dmarc
Typ: TXT
Wert: v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.ch; ruf=mailto:dmarc-reports@ihre-domain.ch; fo=1; pct=100Setup-Schritte im Hostpoint Control Panel
- Im HCP Mail-Panel das Postfach
dmarc-reports@ihre-domain.chanlegen — sonst bouncen alle Reports - Im HCP unter Domains → ihre-domain.ch → DNS-Zone bearbeiten den TXT-Record mit Host
_dmarcanlegen - DNS-Records speichern und nach 10 Min mit
dig _dmarc.ihre-domain.ch TXT +shortverifizieren - Über 2-4 Wochen tägliche XML-Reports parsen — entweder manuell mit
dmarc-parseroder über ein Tool wie dmarcian
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.
# Tag 1 — pct=10
Wert: v=DMARC1; p=quarantine; sp=quarantine; pct=10; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1
# Tag 7 — pct=25
Wert: v=DMARC1; p=quarantine; sp=quarantine; pct=25; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1
# Tag 14 — pct=50
Wert: v=DMARC1; p=quarantine; sp=quarantine; pct=50; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1
# Tag 21 — pct=100
Wert: v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1Ohne 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.
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.
# Tag 1 — pct=10
Wert: v=DMARC1; p=reject; sp=reject; pct=10; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1
# Tag 14 — pct=50
Wert: v=DMARC1; p=reject; sp=reject; pct=50; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1
# Tag 28 — Final
Wert: v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@ihre-domain.ch; 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).
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 eine Migration zwischen Hostpoint-Diensten kann den SPF-Redirect überschreiben.
Monatliche Monitoring-Aufgaben
- Aggregate-Reports auswerten: Anteil der Mails mit
dmarc=passvs.dmarc=failtrenden. Neue Sender imsource_ip-Feld identifizieren - SPF-Drift prüfen: Mit
dig TXT ihre-domain.ch +short | grep "v=spf1"auf doppelte Records prüfen. Den Redirectspf.mail.hostpoint.chrekursiv auflösen lassen - DKIM-Status: Bei DNS-Provider-Wechsel sicherstellen, dass der Hostpoint-DKIM-Eintrag noch in der DNS-Zone steht
- Wolf-Agents Scanner monatlich: 165-Punkte-Analyse inklusive DMARC-Policy,
sp=-Tag, BIMI-Bereitschaft und Stack-Detection für externe Versender - 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
Wenn die DNS-Zone bei einem externen Provider (Cloudflare, Gandi) liegt, kann Hostpoint Änderungen an SPF/DKIM/DMARC nicht selbst durchführen. Bei jedem Hostpoint-Update (z.B. neuer DKIM-Selector, neue SPF-Policy-Server) zeigt Hostpoint den neuen Wert im HCP an — Sie müssen ihn manuell beim externen DNS-Provider eintragen. Wer das vergisst, verliert SPF/DKIM-Pass und damit DMARC-Alignment. Quelle: support.hostpoint.ch/.../dkim-fuer-externe-domains-aktivieren (abgerufen 2026-05-14).
Hostpoint unterstützt DNSSEC für selbst gehostete DNS-Zonen — die Aktivierung erfolgt im HCP im DNS-Editor. 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. Die Änderung kann bis zu 48 Stunden weltweit propagieren.
Hostpoint bietet kein eigenes DMARC-Dashboard — die XML-Aggregate-Reports landen als gewöhnliche E-Mails im rua-Postfach und sind ohne Parser kaum lesbar. Drei Workflow-Optionen für die Auswertung: (1) Eigener Parser: dmarc-parser CLI (Python-Tool, OSS) oder parsedmarc + Elasticsearch + Kibana für Self-Hosting — komplette DSGVO-/revDSG-Konformität, weil die Aggregat-Daten on-prem bleiben. (2) dmarcian: kommerzielles DMARC-Management mit Domain-Übersicht und 30-Tage-Trial, Quelle dmarcian.com (abgerufen 2026-05-14). (3) Postmark DMARC: kostenfreies Monitoring, gut für Single-Domain-Setups. Wolf-Agents-Empfehlung für Hostpoint-Kunden mit NIS2-Pflicht: kombiniertes Setup — parsedmarc für Compliance-Belegbarkeit + dmarcian für Daily-Ops-Übersicht.
Häufige Fehler beim Hostpoint-Enforcement
Diese drei Fehler treten bei der Hostpoint-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 Hostpoint kommt hinzu, dass nach Domain-Migrationen auf einen externen Mail-Server (Microsoft 365, Proton Mail) die SPF-Redirect-Auflösung den falschen Server adressiert.
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 Hostpoint-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.ch für Marketing), legen Sie auf der Subdomain einen eigenen DMARC-Record an mit eigener Policy.
SPF-Redirect bricht nach Provider-Wechsel
Problem: Eine Domain mit Hostpoint-SPF-Redirect (v=spf1 redirect=spf.mail.hostpoint.ch) wird auf einen externen Mail-Provider (Microsoft 365) migriert, ohne den SPF-Record anzupassen. Hostpoint signiert nicht mehr, der Microsoft-365-Versender ist nicht in spf.mail.hostpoint.ch autorisiert — bei p=reject bouncen alle Mails sofort.
Lösung: Vor jeder Mail-Provider-Migration den SPF-Record anpassen — bei vollständigem Wechsel zu Microsoft 365: v=spf1 include:spf.protection.outlook.com -all (kein Hostpoint-Redirect mehr). Bei paralleler Nutzung das Hostpoint-Pattern: v=spf1 include:spf.protection.outlook.com redirect=spf.mail.hostpoint.ch. Nach der Migration die DMARC-Reports auf neue Anomalien überwachen und ggf. von p=reject kurzfristig auf p=quarantine zurück.
NIS2, BSI TR-03108, DSGVO Art. 32 und Schweizer DSG: Enforcement bei Hostpoint
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. Schweizer Datenschutz: revDSG Art. 8 (Datensicherheit/TOM) analog DSGVO Art. 32. 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:
Wie steht Ihre Domain bei DMARC Enforcement?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.