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-Policy prüfen Plattform entdecken
Proton Mail · Enforcement-Roadmap
Von Wolf-Agents Security Team · Aktualisiert: 14. Mai 2026

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, eine report-gestützte Stufung der Policy (none → quarantine → reject) 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, erkennt einen veralteten pct-Teil-Rollout und bewertet ihn als Schwächung, 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 gehört die DMARC-Policy in das Risikomanagement. NIS2 verlangt Maßnahmen zur Bewältigung von Sicherheitsvorfällen sowie Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung — in Deutschland umgesetzt in § 30 BSIG. Eine bestimmte DMARC-Policy-Stufe nennt der Gesetzestext nicht; Enforcement ist für diese Maßnahmenbereiche eine etablierte technische Maßnahme: DMARC-Reports zeigen den Spoofing-Vorfall, p=reject beendet ihn. 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.

Ausführliche DMARC Enforcement Roadmap

1 Phase 1 von 4

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.

DMARC-Record Phase 1 (externer DNS-Provider) Phase 1 
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

Setup-Schritte

  1. Im Proton Account das Postfach dmarc-reports@ihre-domain.ch anlegen — sonst bouncen alle Reports
  2. Beim externen DNS-Provider den TXT-Record mit Hostname _dmarc anlegen
  3. Mit dig _dmarc.ihre-domain.ch TXT +short nach 10-30 Min verifizieren
  4. Über 2-4 Wochen tägliche XML-Reports parsen — manuell mit dmarc-parser oder via dmarcian
2 Phase 2 von 4

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 — dies ist die Proton-Empfehlung. Nicht-konforme Mails landen dann im Spam-Ordner der Empfänger. Beobachten Sie die Aggregate-Reports 1-2 Wochen weiter — bleibt die Pass-Rate legitimer Sender stabil bei rund 100 %, gehen Sie eine Stufe weiter. Ergänzen Sie den sp=quarantine-Tag (oder direkt sp=reject).

DMARC-Record Phase 2 (Proton-Empfehlung) Phase 2 
# Quarantäne aktivieren, dann die rua-Reports beobachten
Wert: v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1

# Optional als vorsichtiger Start: t=y behandelt Fehler eine Stufe milder (wie p=none),
# die Aggregate-Reports laufen dabei normal weiter
Wert: v=DMARC1; p=quarantine; sp=quarantine; t=y; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1
sp=-Tag explizit anlegen

Ohne 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.

3 Phase 3 von 4

Reject-Phase und Full-Enforcement

Nach 2-4 Wochen p=quarantine (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. Wollen Sie die schärfste Stufe zunächst testen, setzen Sie p=reject; t=y — Fehler werden dann eine Stufe milder (wie Quarantäne) behandelt, während die Reports die reale Wirkung zeigen; nach stabiler Beobachtung entfernen Sie t=y.

DMARC-Record Phase 3 (Full Enforcement) Phase 3 
# Reject aktivieren (volle Durchsetzung)
Wert: v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1; ri=86400

# Optional vorsichtiger Start: t=y behandelt Fehler eine Stufe milder (wie Quarantäne),
# nach stabiler Beobachtung t=y wieder entfernen
Wert: v=DMARC1; p=reject; sp=reject; t=y; rua=mailto:dmarc-reports@ihre-domain.ch; fo=1; ri=86400

Mit p=reject; sp=reject ist Ihre Domain auf die strengste DMARC-Policy gestellt: nicht authentifizierte E-Mails in Ihrem Namen sollen von empfangenden Servern abgewiesen werden. Proton's Server bleiben weiterhin alignment-konform (drei rotierende DKIM-CNAMEs + SPF-Include).

4 Phase 4 von 4

Monitoring etablieren

DMARC-Enforcement ist kein „set and forget“. Nach Erreichen von p=reject 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

  1. Aggregate-Reports auswerten: Anteil der Mails mit dmarc=pass vs. dmarc=fail trenden. Neue Sender im source_ip-Feld identifizieren
  2. Alle drei DKIM-CNAMEs prüfen: Mit dig CNAME <selector>._domainkey.ihre-domain.ch +short alle drei einzeln testen — Proton-Schlüsselrotation kann jeden aktivieren
  3. Proton-Tarif prüfen: Mail Plus / Business / Visionary muss aktiv bleiben — bei Downgrade auf Kostenlos bricht Custom Domain
  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 die Aggregate-Reports der letzten 30 Tage als NIS2-Art.-23-Meldung-Belege aufbereiten
Bridge-Limitationen bei Server-Versand (Information-Gain)

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.

Bridge-Architektur im Detail (Information-Gain)

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).

Bridge 2026: FIDO2-Support + 10x schnellerer Sync (Information-Gain-Welle 2)

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 ist eine Umsetzung des Maßnahmenbereichs Multi-Faktor-Authentifizierung (NIS2 Art. 21 Abs. 2 lit. j). 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 verlangt Maßnahmen zur Bewältigung von Sicherheitsvorfällen sowie Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung; in Deutschland umgesetzt in § 30 BSIG. Eine bestimmte DMARC-Policy-Stufe nennt der Gesetzestext nicht — Enforcement ist für diese Maßnahmenbereiche eine etablierte technische Maßnahme gegen laufende Spoofing-Vorfälle. 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:

Microsoft 365 Google Workspace IONOS Strato All-Inkl Hetzner Netcup Hostpoint Infomaniak World4You Postfix Exim Mailcow Generisch

Wie steht Ihre Domain bei DMARC Enforcement?

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

E-Mail Security Check starten