DMARC Enforcement für Proton Mail
Schritt-für-Schritt-Roadmap: vom Beobachtungs-Modus (p=none) über die Proton-Empfehlung Quarantäne (p=quarantine) zu Reject (p=reject) — mit sp=reject Subdomain-Override und Hinweisen zur DKIM-Schlüssel-Rotation.
DMARC Enforcement bei Proton Mail (Schweiz, E2EE mit Custom Domain)
Proton empfiehlt explizit p=quarantine als Sicherheits-Upgrade gegenüber dem Default p=none — Wolf-Agents geht einen Schritt weiter und empfiehlt p=reject als End-Ziel der 4-Phasen-Roadmap. Proton 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.
Proton Mail Custom Domain nutzt zentrale Mail-Server mit dem dokumentierten Default-SPF v=spf1 include:_spf.protonmail.ch -all und drei DKIM-CNAMEs für automatische Schlüssel-Rotation. 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 Proton Mail.
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 DKIM-CNAME-Drift, wenn einer der drei Proton-Selektoren 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 Proton-Mail-Infrastruktur ist selbst p=quarantine noch keine maximale 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). Schweizer Datenschutzrecht: revDSG Art. 8 (Datensicherheit/TOM). Bei NIS2 Art. 23 Meldepflichten (24h-Frühwarnung, 72h-Vorfallsmeldung, 1-Monats-Abschlussbericht) sind DMARC-Aggregate-Reports forensisch verwertbar.
Beobachtungsphase bei Proton Mail
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, welche Sender Ihre Domain im Header-From verwenden. Sie identifizieren so vergessene Marketing-Tools, externe Transactional-Mail-Provider oder Cron-Skripte.
Hostname: _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 Proton Account das Postfach
dmarc-reports@ihre-domain.chanlegen — sonst bouncen alle Reports - Beim externen DNS-Provider den TXT-Record mit Hostname
_dmarcanlegen - Mit
dig _dmarc.ihre-domain.ch TXT +shortnach 10-30 Min verifizieren - Über 2-4 Wochen tägliche XML-Reports parsen — manuell mit
dmarc-parseroder via dmarcian
Quarantäne-Phase (Proton-Empfehlung)
Nach 2-4 Wochen sauberer Reports (alle Sender identifiziert, alle drei DKIM-CNAMEs auflösen) wechseln Sie auf p=quarantine; pct=10 — dies ist die Proton-Empfehlung. 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.
# 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 (Proton-Empfehlung erreicht)
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. Setzen Sie sp=quarantine oder direkt sp=reject früh, da Subdomains seltener von legitimen Sendern verwendet werden und das Risiko minimal ist. Guardio Labs hat 2024 über 8.000 Marken-Subdomains aufgedeckt, die für SubdoMailing missbraucht wurden.
Reject-Phase und Full-Enforcement
Nach 2-4 Wochen p=quarantine; pct=100 (Proton-Empfehlung erreicht) 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. Wolf-Agents empfiehlt diesen Schritt über Proton's Empfehlung hinaus für maximalen Schutz.
# 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 (Maximum Enforcement)
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 maximal geschützt. Proton's Server bleiben weiterhin alignment-konform (drei rotierende DKIM-CNAMEs + SPF-Include).
Monitoring etablieren
DMARC-Enforcement ist kein „set and forget“. Nach Erreichen von p=reject; pct=100 bleibt das kontinuierliche Monitoring nötig — neue Sender (externe Transactional-Mail-Provider, Cron-Skripte, vergessene Mail-Skripte) können DMARC fehlschlagen lassen, und ein Tarif-Downgrade von Proton auf Kostenlos macht Custom Domain unmöglich.
Monatliche Monitoring-Aufgaben
- Aggregate-Reports auswerten: Anteil der Mails mit
dmarc=passvs.dmarc=failtrenden. Neue Sender imsource_ip-Feld identifizieren - Alle drei DKIM-CNAMEs prüfen: Mit
dig CNAME <selector>._domainkey.ihre-domain.ch +shortalle drei einzeln testen — Proton-Schlüsselrotation kann jeden aktivieren - Proton-Tarif prüfen: Mail Plus / Business / Visionary muss aktiv bleiben — bei Downgrade auf Kostenlos bricht Custom Domain
- 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 die Aggregate-Reports der letzten 30 Tage als NIS2-Art.-23-Meldung-Belege aufbereiten
Proton bietet keinen direkten SMTP-AUTH für Custom Domain — automatisierte Server-Mails (WordPress, Cron-Jobs) müssen entweder über die Proton Bridge (lokal installiert) oder über einen externen Transactional-Mail-Provider (Sendgrid, Postmark, Mailgun) laufen. Bei p=reject bouncen alle Server-Mails sofort, die nicht authentifiziert sind. Externe Transactional-Provider müssen mit eigenen Includes im SPF-Record stehen, damit DMARC nicht bricht.
Proton Bridge ist eine lokale Anwendung auf Ihrem Gerät (Windows/macOS/Linux), die als Localhost-Proxy zwischen Mail-Clients und Proton's E2EE-Backend vermittelt. Funktionsweise: Bridge präsentiert IMAP auf 127.0.0.1:1143 und SMTP auf 127.0.0.1:1025 — Mail-Clients wie Thunderbird oder Outlook verbinden sich zu diesen lokalen Endpunkten, als wäre Bridge ein normaler Mail-Server. Bridge entschlüsselt eingehende Proton-Mails on-the-fly und übergibt Klartext an den lokalen Client. Bei ausgehenden Mails empfängt Bridge unverschlüsselten Inhalt vom Client, verschlüsselt zu E2EE und reicht an Proton's MTA weiter. Bridge ist Voraussetzung für Desktop-Mail-Clients nur lesen-seitig — DKIM/SPF/DMARC für Custom-Domain-Versand laufen ohne Bridge auf den Proton-Servern. Quelle: proton.me/mail/bridge (abgerufen 2026-05-14).
Proton Bridge wurde 2026 substanziell überarbeitet: v3.24.0 (30. März 2026) integrierte FIDO2-Unterstützung für Hardware-Token (YubiKey, NitroKey) als zweiten Faktor, ergänzt um IMAP-Verbindungs-Begrenzung und Buffer-Pooling für Message-Building. v3.24.2 (20. April 2026) ist die aktuelle Stable. Performance-Sprung im Jahr 2026 laut Proton-Roadmap: bis zu 10x schnellere Inbox-Sync und bis zu 3x schnelleres Versenden großer Anhänge; macOS-Bridge läuft jetzt nativ auf Apple Silicon. Für NIS2-pflichtige Unternehmen mit Custom-Domain + Bridge auf einem zentralen Server (z.B. für transaktionale Mails) sind diese Performance- und Sicherheits-Updates messbar — FIDO2 erfüllt die NIS2 Art. 21 Abs. 2 lit. j (Multi-Faktor-Authentifizierung) Anforderung. Quelle: github.com/ProtonMail/proton-bridge/releases (abgerufen 2026-05-14).
Häufige Fehler beim Proton-Mail-Enforcement
Diese drei Fehler treten bei der Proton-Mail-spezifischen DMARC-Enforcement-Roadmap besonders häufig auf — jeder einzelne kann Enforcement aushebeln oder legitime Sender unbeabsichtigt blockieren.
Server-Cron-Jobs ohne SMTP-Relay
Problem: Bei p=reject bouncen alle Server-Mails (WordPress-PHP-Mail, Cron-Skripte, automatische Reports), die nicht über Proton signiert sind. Proton bietet keinen direkten SMTP-AUTH für Custom Domain — der Server kann die Mails nicht authentifizieren. SPF schlägt fehl, DKIM fehlt, DMARC ergibt fail.
Lösung: Externe Transactional-Mail-Provider (Sendgrid, Postmark, Mailgun) nutzen und deren Includes im SPF-Record ergänzen: v=spf1 include:_spf.protonmail.ch include:sendgrid.net -all. Alternativ Proton Bridge auf dem Server installieren (technisch möglich, aber für reine Server-Mails ungewöhnlich).
DKIM-CNAME-Rotation bricht bei zwei fehlenden Records
Problem: Bei einer DNS-Migration werden nur einer oder zwei der drei Proton-DKIM-CNAMEs übernommen. Proton rotiert die Schlüssel automatisch — sobald der aktuell aktive Selector über einen nicht existierenden CNAME ausgeliefert wird, schlägt DKIM fehl. Bei p=reject bouncen alle Mails sofort. Die Reports zeigen ein verwirrendes Bild: Manche Tage funktionieren, manche nicht.
Lösung: Alle drei DKIM-CNAMEs (aus dem Proton Account → Domain names → Review → DKIM) dauerhaft in der DNS-Zone behalten. Bei jeder DNS-Provider-Migration alle drei mit übernehmen. Im Proton Account muss der DKIM-Tab grünes Häkchen zeigen.
Tarif-Downgrade auf Kostenlos — Custom Domain bricht
Problem: Proton Mail Plus wird gekündigt oder auf Kostenlos heruntergestuft. Custom Domain ist im Kostenlos-Tarif nicht verfügbar — Proton stellt die Mail-Annahme ein und entfernt im Hintergrund die DKIM-Schlüssel. Bei p=reject bouncen alle Mails sofort. SPF/DKIM/DMARC-Records stehen noch in der DNS-Zone, aber tatsächlich kommt nichts mehr durch.
Lösung: Bei Tarif-Downgrade entscheiden: a) Custom Domain bleibt nötig → Tarif wieder auf Plus erhöhen oder b) Mail-Anbieter wechseln → MX/SPF/DKIM/DMARC-Records auf den neuen Anbieter umstellen, NICHT „verwaisen“ lassen. Wolf-Agents Email Monitoring erkennt diesen Drift in 6-Stunden-Intervallen und alarmiert proaktiv.
NIS2, BSI TR-03108, DSGVO Art. 32 und Schweizer DSG: Enforcement bei Proton Mail
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). BSI TR-03108 empfiehlt p=reject als Mindeststandard — über Proton's p=quarantine-Empfehlung hinaus. DSGVO Art. 32 fordert technische Maßnahmen zur Sicherheit der Verarbeitung. Schweizer Datenschutz: revDSG Art. 8 (Datensicherheit/TOM) analog DSGVO Art. 32. Schweizer Datensouveränität (kein US-CLOUD-Act-Zugriff) plus End-to-End-Verschlüsselung mit Zero-Access ist Proton's spezifischer USP. NIS2 Art. 23 schreibt 24h-Frühwarnung, 72h-Vorfallsmeldung und 1-Monats-Abschlussbericht vor — DMARC-Aggregate-Reports liefern die Forensik-Datenbasis. 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.