Warum 46 % aller E-Mails an DMARC scheitern — und warum vieles davon Friendly Fire ist
Die Schlagzeilenzahl: 46 %
Anfang März hat Cloudflares hauseigene Threat-Research-Einheit Cloudforce One den 2026 Threat Report veröffentlicht — den ersten ihrer Art. Versteckt in einem Abschnitt über Phishing-as-a-Service steht eine Zahl, die mehr Aufmerksamkeit verdient hätte:
Knapp 46 % der 450 Millionen von Cloudflare analysierten E-Mails sind an der DMARC-Validierung gescheitert.
43 % sind an SPF gescheitert. 44 % hatten keine gültige DKIM-Signatur. In einer Welt, in der Google und Yahoo Authentifizierung zur harten Zustellvoraussetzung gemacht haben, in der CISA DMARC für US-Bundesbehörden seit 2017 vorschreibt und in der das Protokoll selbst über ein Jahrzehnt alt ist — scheitert damit fast jede zweite E-Mail weltweit an der grundlegenden Identitätsprüfung.
Die naheliegende Lesart lautet: Angreifer gewinnen. Und das stimmt — Cloudflares Report beschreibt im Detail, wie Phishing-as-a-Service-Bots (PhaaS) genau diese Lücken ausnutzen. Aber es gibt eine zweite Lesart, die weniger offensichtlich und praktisch wertvoller ist:
Ein großer Teil dieser 46 % sind überhaupt keine Phishing-Versuche. Es sind legitime Nachrichten, von legitimen Absendern, die irgendwo zwischen Postausgang und Posteingang zerbrechen.
E-Mail ist ein Staffellauf mit Sicherheitssiegel
Man kann sich E-Mail-Authentifizierung wie den Versand eines versiegelten Containers in einer mehrstufigen Logistikkette vorstellen.
- SPF ist der Frachtbrief an der Einfahrt: „Dieser LKW ist autorisiert, diese Ladung zu transportieren.”
- DKIM ist das Sicherheitssiegel am Container selbst: „Der Inhalt wurde unterwegs nicht verändert.”
- DMARC ist die Anweisung am Zielort: „Hier steht, was zu tun ist, wenn Frachtbrief oder Siegel nicht in Ordnung sind.”
E-Mails werden selten direkt vom Absender zum Empfänger transportiert. Sie laufen durch Weiterleitungen, Mailinglisten-Server, Security-Gateways, Backup-MX-Hosts und Relay-Dienste. Jeder dieser Punkte ist eine Stelle, an der Frachtbrief oder Siegel versagen können — selbst wenn nichts Bösartiges passiert.
Wenn Cloudflare im 2026 Threat Report von „relay blind spots” spricht, ist genau das gemeint: zwischengeschaltete Mailserver, die die Absender-Identität nicht erneut prüfen. Für Angreifer ist dieser blinde Fleck eine Einladung. Für legitime Absender ist er die Quelle routinemäßiger, unsichtbarer Fehlzustellungen.
Fünf alltägliche Gründe, warum eure E-Mails an DMARC scheitern
Aus Kunden-Deployments und den Aggregate-Reports, die wir verarbeiten, tauchen diese fünf Ursachen immer wieder auf.
1. Weiterleitung zerstört SPF
Ein Nutzer richtet auf dem Firmenpostfach eine .forward-Regel zu seiner privaten Gmail-Adresse ein. Jede Nachricht wird weitergeleitet. Sie kommt bei Gmail mit der ursprünglichen From:-Domain an — aber die verbindende IP ist jetzt der Firmenmailserver, nicht mehr die des ursprünglichen Absenders.
SPF prüft die verbindende IP gegen die Domain des ursprünglichen Absenders. Das schlägt fehl. Jedes Mal.
Das ist mit Abstand die häufigste Ursache für SPF-Fehler bei legitimem Traffic.
2. Mailinglisten und Relays zerstören DKIM
Mailinglisten-Software schreibt Betreffzeilen um ([Listenname] Originalbetreff), hängt Abmelde-Footer an und encodiert manchmal den Body neu. Jede dieser Änderungen macht die DKIM-Signatur des ursprünglichen Absenders ungültig.
ARC (Authenticated Received Chain) wurde entwickelt, um genau dieses Problem zu lösen, indem zwischengeschaltete Server für das frühere Authentifizierungsergebnis bürgen können. Die Verbreitung ist aber noch lückenhaft. In der Praxis gilt: Sobald eine Nachricht einen Listen-Server durchläuft, müsst ihr davon ausgehen, dass DKIM bricht.
3. Alignment-Mismatches bei Third-Party-Sendern
Das ist der leise Killer. Das Marketing-Team meldet sich bei einem neuen E-Mail-Tool an. Das Tool versendet Kampagnen mit eurer Domain im sichtbaren From:-Header — aber der Envelope-Sender (MAIL FROM) ist die eigene Bounce-Domain des Tools, und die DKIM-Signatur ist auf die Tool-Domain ausgestellt, nicht auf eure.
SPF besteht. DKIM besteht. Aber keines davon alignt mit dem From:-Header — und genau das prüft DMARC.
Jede unreviewte Integration — Ticketsysteme, HR-Plattformen, Rechnungstools, Transaktionsmail-Dienste — ist ein Kandidat für diesen Fehlermodus.
4. Das 10-Lookup-Limit von SPF
SPF erlaubt maximal 10 DNS-Lookups pro Auswertung. Jedes include:-Mechanism zählt. Jedes verschachtelte include: innerhalb dieser Includes zählt ebenfalls.
Domains, die fünf oder mehr SaaS-Sender einsetzen, stoßen regelmäßig an dieses Limit, ohne es zu bemerken. Das Ergebnis ist permerror, was die meisten Empfänger als SPF-Fehler behandeln. Euer Record existiert technisch. Er lässt sich nur nicht auflösen.
5. p=none: DMARC ist da, aber stumm geschaltet
Und hier schließt das globale Bild an unsere eigene Forschung an. Wir haben kürzlich 503 Domains aus Deutschland, Österreich und der Schweiz analysiert. 87,3 % hatten einen DMARC-Record veröffentlicht. Nur 56,3 % haben ihn tatsächlich durchgesetzt — der Rest stand auf p=none.
p=none sagt Empfängern: „Schickt mir Reports, aber blockiert oder quarantäniert nichts, was fehlschlägt.” Das ist ein sinnvoller Ausgangspunkt für ein DMARC-Rollout. Es ist ein katastrophaler Endzustand. Eine p=none-Domain sieht dieselbe 46-%-Fehlerrate, die auch Cloudflare sieht — und tut nichts dagegen.
Was die 46 % wirklich bedeuten
Zusammengenommen ist die Cloudflare-Zahl nicht ein einzelnes Problem. Sie ist mindestens drei überlappende Realitäten, die gleichzeitig ablaufen:
- Angreifer. PhaaS-Bots, die gefälschte Nachrichten durch Domains mit schwacher oder permissiver Authentifizierung sprühen.
- Legitimer Mailverkehr, der unterwegs bricht. Weitergeleitet, über Listen verschickt, relaiert.
- Legitimer Mailverkehr, der am Ursprung bricht. Third-Party-Sender ohne Alignment, zu lange SPF-Records, DMARC, das im Monitoring-Modus steckenbleibt.
Die unbequeme Konsequenz: Wenn eure Domain auf p=none steht, könnt ihr diese drei nicht auseinanderhalten. Ihr seht ungefähr dieselbe aggregierte Fehlerquote wie Cloudflare — und habt keinen Hebel, irgendetwas davon zu stoppen.
Was konkret zu tun ist
Wer DMARC veröffentlicht, dem stellt sich nicht die Frage, ob man von p=none weggeht — sondern wie schnell man es sicher schafft. Eine praktikable Reihenfolge:
- Aggregate-DMARC-Reports aktivieren. Für jede Domain, die euch gehört — auch die, von denen ihr nicht versendet. Parked Domains werden aktiv ausgenutzt.
- Jeden legitimen Sender inventarisieren. Nicht nur Microsoft 365 oder Google Workspace. Alle: Marketing-Plattform, HR-System, CRM, Ticketsystem, Rechnungstool, Transaktionsmail-Dienst. Was in eurem Namen versendet, gehört auf die Liste.
- Alignment für jeden fixen. Meist heißt das: gebrandete Subdomain, sauber delegierte DKIM-Keys und eine SPF-
include:-Kette, die unter der 10-Lookup-Grenze bleibt. - Auf
p=quarantinemit gestaffeltem Rollout umstellen. Beipct=10starten, Reports beobachten, hochskalieren. - Bei
p=rejectenden. Alles andere heißt: Rauchmelder gekauft, Batterie nicht eingelegt.
Warum die 46 % für euch relevant sind
Die 2024er Sender-Requirements von Google und Yahoo, CISAs BOD 18-01 und DORA in der EU ziehen alle in dieselbe Richtung: E-Mail-Authentifizierung ist kein Nice-to-have mehr, sondern ein Compliance-Boden. Eine globale Fehlerquote von 46 % zeigt, dass dieser Boden noch deutlich unter dem Niveau liegt, das Regulatoren — und zunehmend auch Mailbox-Provider — von Absendern erwarten.
Sichtbarkeit ist der fehlende Teil. Wenn ihr nicht wisst, welche eurer Sender bestehen und welche scheitern, könnt ihr die legitimen Flows nicht reparieren und die bösartigen nicht sicher abwehren.
Bei DMARCPulse haben wir unsere Monitoring-Plattform genau um diese Sichtbarkeit herum gebaut — pro Quelle, pro Authentifizierungsergebnis, pro Tag. Wenn ihr sehen wollt, wie eure Domain aus Empfängersicht wirklich aussieht, startet einen kostenlosen 14-tägigen Trial. Ohne Kreditkarte.
Die 46 % verschwinden nicht von allein. Aber das meiste davon ist reparierbar — sobald man es sieht.