DMARCPulse
Start free trial
All posts Cloudflare 2026 Threat Report: 46% of emails fail DMARC validation

Why 46% of All Emails Fail DMARC — And Why Much of It Is Friendly Fire

DMARCPulse Team
Email SecurityDMARCSPFDKIM

The headline number: 46%

In early March, Cloudflare’s in-house threat research unit Cloudforce One published its inaugural 2026 Threat Report. Buried in a section about phishing-as-a-service was a number that deserves more attention than it got:

Nearly 46% of the 450 million emails Cloudflare analyzed failed DMARC validation.

43% failed SPF. 44% lacked a valid DKIM signature. In a world where Google and Yahoo have made authentication a hard delivery requirement, where CISA has mandated DMARC for US federal agencies since 2017, and where the protocol itself is now more than a decade old — almost half of global email traffic still fails the basic identity check.

The intuitive reading is that attackers are winning. And they are — Cloudflare’s report details how phishing-as-a-service (PhaaS) bots exploit exactly these gaps. But there is a second reading, less obvious and more useful:

A large share of those 46% aren’t phishing attempts at all. They are legitimate messages, sent by legitimate senders, broken somewhere between outbox and inbox.

Email is a relay race with a tamper-evident seal

It helps to picture email authentication as shipping a sealed container across a multi-stop logistics chain.

  • SPF is the manifest at the gate: “this truck is authorized to carry this cargo.”
  • DKIM is the tamper-evident seal on the container itself: “this content hasn’t been modified in transit.”
  • DMARC is the instruction sheet at the destination: “here’s what to do if the manifest is missing or the seal is broken.”

Email rarely travels directly from sender to recipient. It passes through forwarders, mailing list servers, security gateways, backup MX hosts, and relay services. Every one of those is a point where the manifest or the seal can fail — even when nothing malicious is happening.

When Cloudflare talks about “relay blind spots” in the 2026 report, this is what they mean: intermediate mail servers that don’t re-verify sender identity. For attackers, that blind spot is an opportunity. For legitimate senders, it’s a source of routine, invisible breakage.

Five everyday reasons your mail fails DMARC

From customer deployments and the aggregate reports we process, these five causes appear over and over.

1. Forwarding destroys SPF

A user sets up a .forward rule on their corporate mailbox to a personal Gmail address. Every message gets relayed. It arrives at Gmail with the original From: domain intact — but the connecting IP is now the corporate mail server, not the original sender’s.

SPF checks the connecting IP against the original sender’s domain. It fails. Every time.

This is the single most common cause of SPF failures for legitimate traffic.

2. Mailing lists and relays break DKIM

Mailing list software rewrites subject lines ([list-name] Original Subject), appends unsubscribe footers, and sometimes re-encodes the body. Any of those modifications invalidates the DKIM signature attached by the original sender.

ARC (Authenticated Received Chain) was designed to solve this by letting intermediaries vouch for the earlier authentication result. Adoption is still patchy. In practice, the moment your message enters a list server, you should expect DKIM to break.

3. Alignment mismatches from third-party senders

This is the silent killer. Your marketing team signs up for a new email tool. The tool sends campaigns with your domain in the visible From: header — but the envelope sender (MAIL FROM) is the tool’s own bounce domain, and the DKIM signature is keyed to the tool’s domain, not yours.

SPF passes. DKIM passes. But neither aligns with the header From: — which is what DMARC actually checks.

Every unreviewed integration — help desks, HR platforms, invoicing tools, transactional email services — is a candidate for this failure mode.

4. SPF’s 10-lookup limit

SPF allows a maximum of 10 DNS lookups per evaluation. Each include: mechanism counts. Each nested include: counts too.

Domains using five or more SaaS senders routinely hit this limit without realizing it. The result is permerror, which most receivers treat as an SPF failure. Your record technically exists. It just doesn’t resolve.

5. p=none: DMARC exists, but it’s on mute

And this is where the global picture connects back to our own research. We recently analyzed 503 domains across Germany, Austria, and Switzerland. 87.3% had a DMARC record published. Only 56.3% actually enforced it — the rest were sitting at p=none.

p=none tells receivers: “send me reports, but don’t actually block or quarantine anything that fails.” It’s a valid starting point for a DMARC rollout. It’s a terrible end state. A p=none domain sees the same 46% failure rate that Cloudflare sees — and does nothing about it.

What the 46% actually tells you

Taken together, the Cloudflare number is not a single problem. It’s at least three overlapping realities happening at the same time:

  1. Attackers. PhaaS bots spraying spoofed messages through domains with weak or permissive authentication.
  2. Legitimate mail that breaks in transit. Forwarded, listed, relayed.
  3. Legitimate mail that breaks at origin. Third-party senders without alignment, SPF records too long to resolve, DMARC stuck at monitoring.

The uncomfortable consequence: if your domain is at p=none, you cannot tell these three apart. You are seeing roughly the same aggregate failure rate that Cloudflare does — and you have no mechanism to stop any of it.

What to actually do

If you publish DMARC, the question isn’t whether to move off p=none. It’s how fast you can do it safely. A workable sequence:

  1. Turn on aggregate DMARC reporting. Every domain you own — including the ones you don’t send from. Parked domains are actively exploited.
  2. Inventory every legitimate sender. Not just Microsoft 365 or Google Workspace. All of them: marketing platform, HR system, CRM, help desk, invoicing tool, transactional service. If it sends mail as you, it goes on the list.
  3. Fix alignment for each one. Usually a branded subdomain, properly delegated DKIM keys, and an SPF include: chain that stays under the 10-lookup ceiling.
  4. Move to p=quarantine with a staged rollout. Start at pct=10, watch the reports, scale up.
  5. End at p=reject. Anything less means you’ve bought a smoke detector and left it unplugged.

Why the 46% matters for you

Google and Yahoo’s 2024 sender requirements, CISA’s BOD 18-01, and the EU’s DORA all push in the same direction: email authentication isn’t a nice-to-have, it’s a compliance floor. A 46% failure rate across global traffic tells us that floor still sits well below where regulators — and increasingly, mailbox providers — expect senders to stand.

Visibility is the part that’s missing. If you don’t know which of your senders are passing and which are failing, you can’t fix the legitimate flows, and you can’t safely enforce against the malicious ones.

At DMARCPulse, we built our monitoring platform around exactly that visibility — per source, per authentication result, per day. If you want to see what your domain looks like from the receiver’s perspective, start a free 14-day trial. No credit card required.

The 46% number is not going away on its own. But most of it is fixable, once you can see it.