Ein DMARC-Eintrag kann nach Fortschritt bei email security aussehen und trotzdem fast nichts blockieren. Genau das zeigen die neuen Zahlen von CipherCue: In einem Datensatz von 67,336 company domains, geprüft zwischen dem 14. April und dem 28. Juli 2026, hatten 68.4% entweder keinen DMARC record oder standen noch auf p=none.

DMARC email policy von monitoring zu quarantine und reject gates

Das ist keine neue Schwachstelle. Es ist ein nicht fertiggestellter Kontrollmechanismus. DMARC ist seit 2012 öffentlich, und im Mai 2026 ersetzte die IETF RFC 7489 durch RFC 9989, RFC 9990 und RFC 9991. Das Kernprotokoll ist nun Standards Track Proposed Standard. Das Problem liegt im letzten Schritt: von “wir sammeln Reports” zu “wir bitten Empfänger, gefälschte Nutzung unserer Domain abzuweisen”.

DMARC ist nützlich, aber kein Anti-Phishing-Zauber. Es hilft gegen exact-domain spoofing im sichtbaren From. Es stoppt keine lookalike domains, kein display-name spoofing, keine kompromittierten echten Accounts und keine Phishing-Mails von großen Plattformen mit gültiger Authentifizierung.

DMARC baut auf SPF und DKIM auf. SPF sagt, welche Server für eine Domain senden dürfen. DKIM signiert Mail mit einem Domain-Schlüssel. DMARC prüft, ob eine authentifizierte Identität zur sichtbaren From-Domain passt, und teilt Empfängern mit, was bei einem Fehlschlag passieren soll.

Die drei üblichen Policies sind p=none, p=quarantine und p=reject. p=none überwacht und erzeugt reports. p=quarantine bittet um eine verdächtige Behandlung, oft Spam. p=reject bittet um Ablehnung. Empfänger behalten Spielraum, doch praktisch ist p=none nur eine Alarmanlage mit Logbuch.

Im CipherCue-Snapshot hatten 30,362 domains, also 45.1%, keinen DMARC record. Von den Domains mit Record standen 15,709 auf p=none, 10,258 auf p=quarantine und 10,963 auf p=reject. CipherCue zählt enforcement als p=quarantine oder p=reject; damit waren 46,071 domains im Sample non-enforcing.

Diese Zahlen brauchen Kontext. CipherCue beschreibt den Datensatz als tracked entity set, nicht als repräsentative Stichprobe aller Firmen weltweit. Hacker-News-Kommentare stellten außerdem eine berechtigte Frage: Wie viele Domains waren parked, inactive, send-only oder ohne normale MX records? Das ändert nicht die Grundfrage, aber es verhindert übertriebene globale Behauptungen.

Die Lücke bleibt, weil p=reject kein reiner DNS-Schalter ist. Es ist Inventararbeit.

Eine Organisation muss alle legitimen Sender kennen: Microsoft 365 oder Google Workspace, CRM, marketing automation, billing, helpdesk, HR tools, ticketing, alte Server, Scanner, Dienstleister und vergessene Apps. Jeder Strom braucht SPF oder DKIM alignment. Unknown senders müssen repariert, auf Subdomains verschoben oder abgeschaltet werden.

Die Reports sind ebenfalls mühsam. DMARC aggregate reports, nun in RFC 9990 beschrieben, sind maschinenlesbares XML. Für kleine Organisationen, die nur ein DNS-Beispiel kopiert haben, ist das schnell ein Stapel Dateien ohne klare Aktion.

Die Angst vor kaputter legitimer Mail ist real. Wenn das Rechnungssystem DKIM alignment verfehlt, kann p=reject Rechnungen verschwinden lassen. Wenn eine Support-Plattform über eine falsch konfigurierte Route sendet, erzeugt enforcement Kundenbeschwerden. Niemand will “Sicherheit verbessern” und password resets brechen.

Microsoft beschrieb im Januar 2026 Phishing über complex routing und misconfigured spoof protections. Der praktische Punkt: routing, connectors, forwarding und Gateways verändern, wie authentication beim Empfänger aussieht.

Der sichere Weg ist schrittweise. Zuerst Domain-Inventar: primary sending domains, marketing subdomains, transactional subdomains, parked domains und Domains, die nie Mail senden sollen. Für no-send domains schließen SPF v=spf1 -all und DMARC p=reject; sp=reject oft einen einfachen Missbrauchspfad.

Für active domains sollte p=none nur eine temporäre Monitoring-Phase sein. Nutzen Sie eine Reporting-Adresse, die wirklich gelesen wird, und ein Tool, das XML in Entscheidungen übersetzt. Korrigieren Sie danach alignment, besonders DKIM bei Drittanbietern und weitergeleiteter Mail.

Dann folgen die Stufen: p=none, p=quarantine, p=reject. Beobachten Sie helpdesk tickets, bounce logs, deliverability dashboards und DMARC reports. Dokumentieren Sie für jeden sender owner, platform, domain/subdomain, authentication method und rollback contact.

DMARC beseitigt Phishing nicht. Enforcement beseitigt aber den billigen Trick, Mail direkt von Ihrer Domain erscheinen zu lassen, obwohl authentication fehlschlägt. p=none ist als Lernphase sinnvoll; als Dauerzustand ist es ein Kontrollmechanismus, der nur zusieht.