Die DMARC-Enforcement-Lücke: Warum p=none nicht reicht

Der Rauchmelder ohne Batterie

Stell dir vor, du installierst in jedem Raum deines Büros einen Rauchmelder — aber legst nie die Batterien ein. Du hast den Aufwand betrieben. Du hast den Haken gesetzt. Aber wenn es brennt, passiert nichts.

Genau das machen die meisten Organisationen mit DMARC.

Ein neuer Report von PowerDMARC hat 555 kanadische Domains aus sieben Branchen analysiert. Die Schlagzahlen klingen ermutigend: 88,7 % haben einen DMARC-Record in ihrem DNS veröffentlicht. Aber schaut man genauer hin, ändert sich das Bild dramatisch: Nur 28,1 % erzwingen ihn mit einer Policy von p=reject.

Das bedeutet: 7 von 10 Organisationen mit DMARC laufen im Monitoring-Modus. Sie können sehen, dass jemand ihre Domain spooft. Sie haben sich nur entschieden, nichts dagegen zu tun.

Was Monitoring-Modus tatsächlich bedeutet

Wenn du einen DMARC-Record mit p=none veröffentlichst, sagst du empfangenden Mailservern: „Wenn eine E-Mail die Authentifizierung nicht besteht, stell sie trotzdem zu — aber schick mir einen Report darüber.”

Das ist als erster Schritt nützlich. Es gibt dir Einblick, wer E-Mails im Namen deiner Domain versendet. Aber es bietet keinerlei Schutz. Gefälschte E-Mails landen weiterhin im Posteingang deiner Empfänger — mit deinem Markennamen.

Eine Policy von p=quarantine verschiebt fehlgeschlagene E-Mails in den Spam-Ordner. Eine Policy von p=reject weist Empfänger an, sie komplett abzulehnen. Erst bei p=reject ist deine Domain vollständig gegen Identitätsmissbrauch geschützt.

Warum Organisationen steckenbleiben

Wenn Enforcement so viel besser ist, warum kommen die meisten Domains nie dort an? Die Antwort lautet fast immer: Angst, legitime E-Mails zu blockieren.

Moderne Organisationen versenden E-Mails über Dutzende von Quellen: Marketing-Plattformen, CRM-Systeme, Ticketing-Tools, Abrechnungsdienste, HR-Software, Monitoring-Alerts. Jeder dieser Dienste muss über SPF oder DKIM korrekt autorisiert sein. Fehlt auch nur eine legitime Quelle, werden diese E-Mails bei p=reject blockiert.

Also bleiben Teams im Monitoring-Modus — „nur bis wir alles sortiert haben.” Aus Wochen werden Monate. Aus Monaten werden Jahre. Und das Problem wird mit der Zeit nur schwieriger:

• Neue Dienste werden hinzugefügt, ohne SPF oder DKIM zu aktualisieren
• Schatten-IT versendet E-Mails über deine Domain, ohne dass es jemand weiß
• SPF-Records wachsen, bis sie das Limit von 10 DNS-Lookups erreichen und stille Fehler verursachen
• Personalwechsel bedeuten, dass die Person, die das DMARC-Projekt gestartet hat, längst weitergezogen ist

Die Ironie: Je länger du wartest, desto komplexer wird die Migration.

Die Zahlen sind deutlich

Der kanadische Report ist kein Einzelfall. Ähnliche Muster zeigen sich weltweit:

• Die MTA-STS-Adoption bei denselben kanadischen Domains liegt bei nur 3,2 % — das heißt, 96,8 % der Domains haben keinen Schutz gegen TLS-Downgrade-Angriffe bei eingehenden E-Mails
• Die DNSSEC-Adoption liegt bei 9,4 % — über 90 % der Domains bleiben anfällig für DNS-Hijacking
• Laut Cloudflares Threat Report 2026 scheitern 46 % aller E-Mails weltweit an der DMARC-Validierung

Die Lücke zwischen „DMARC haben” und „DMARC erzwingen” ist einer der größten blinden Flecken in der E-Mail-Sicherheit heute.

Wie du die Lücke schließt

Der Weg von p=none zu p=reject ist nicht kompliziert. Er ist methodisch. So gehst du vor:

1. Lies deine DMARC-Reports tatsächlich

DMARC-Aggregate-Reports sind XML-Dateien, die empfangende Mailserver dir täglich senden. Sie enthalten Daten über jede E-Mail, die von deiner Domain gesendet wurde: welche Quellen SPF und DKIM bestanden haben, welche durchgefallen sind und warum.

Die meisten Organisationen sammeln diese Reports, analysieren sie aber nie. Das ist, als hättest du Überwachungskameras, aber schaust dir die Aufnahmen nie an.

2. Identifiziere jede legitime Sendequelle

Gehe deine Reports durch und katalogisiere jeden Dienst, der E-Mails im Namen deiner Domain versendet. Häufige Quellen sind:

• Dein primärer E-Mail-Provider (Google Workspace, Microsoft 365)
• Marketing-Tools (Mailchimp, HubSpot, Brevo)
• Transaktionale E-Mail-Dienste (SendGrid, Amazon SES, Postmark)
• Ticketing-Systeme (Zendesk, Freshdesk)
• CRM-Plattformen (Salesforce, Pipedrive)
• Interne Anwendungen und Monitoring-Tools

3. Behebe SPF und DKIM für jede Quelle

Stelle für jede legitime Quelle sicher, dass sie in deinem SPF-Record enthalten ist und DKIM-Signierung korrekt konfiguriert ist. Hier passiert der Großteil der Arbeit — und hier machen spezifische, umsetzbare Empfehlungen den entscheidenden Unterschied.

Statt einem generischen „SPF fehlgeschlagen für Quelle X” brauchst du die exakte Information, welchen include:-Eintrag du hinzufügen oder welchen DKIM-Selektor du konfigurieren musst.

4. Wechsle zu Quarantine, dann Reject

Sobald deine Authentifizierungs-Passraten konstant hoch sind (über 95 %), wechsle deine Policy auf p=quarantine. Beobachte einige Wochen, um verbleibende Probleme zu erkennen. Dann wechsle zu p=reject.

Dieser schrittweise Ansatz minimiert das Risiko und erhöht gleichzeitig stetig den Schutz.

Lass deinen DMARC-Record keine Dekoration sein

Ein DMARC-Record mit p=none ist ein Startpunkt, kein Ziel. Die Daten, die er sammelt, sind wertvoll — aber nur, wenn du darauf reagierst. Jeder Tag, an dem deine Domain im Monitoring-Modus bleibt, ist ein Tag, an dem Angreifer gefälschte E-Mails in deinem Namen senden können, ohne dass deine Empfänger geschützt sind.

Die Lösung besteht nicht darin, mehr Tools zu kaufen oder mehr Leute einzustellen. Es geht darum, die Daten, die du bereits hast, in konkrete Handlungen umzuwandeln: welche DNS-Records zu ändern sind, welche Dienste zu konfigurieren sind, welche Lücken zu schließen sind.

Genau dafür wurde DMARCPulse entwickelt. Statt generischer Warnungen wie „SPF fehlgeschlagen” liefert DMARCPulse umsetzbare Empfehlungen — spezifische DNS-Werte, die du kopieren und einfügen kannst. Es analysiert deine DMARC-Reports, identifiziert deine Sendequellen und sagt dir genau, was zu beheben ist. Starte deine kostenlose 7-Tage-Testphase und wechsle vom Monitoring zum Enforcement.

Zusammenfassung

• 88,7 % der kanadischen Domains haben DMARC — aber nur 28,1 % erzwingen es mit p=reject
• Monitoring-Modus (p=none) bietet Einblick, aber keinerlei Schutz gegen Spoofing
• Organisationen bleiben stecken, weil sie befürchten, legitime E-Mails von Drittanbietern zu blockieren
• Die Lösung ist methodisch: Reports analysieren, Quellen identifizieren, Authentifizierung beheben, dann erzwingen
• Je länger du wartest, desto schwieriger wird Enforcement — fang jetzt an