Why your DMARC report shows 46% fail — and why only 3% of it matters

Red report, green delivery — how does that add up?

You open your DMARC aggregate report and see 46% SPF fail. First instinct: something is broken, or someone is spoofing your domain. Second look: emails are landing fine, bounce rate is normal, no complaints.

So what’s going on?

In most cases we see, the answer is straightforward: you’re using an ESP like Brevo, Mailgun, SendGrid, or Mailchimp — specifically their free tier.

Why shared ESP free tiers produce SPF fails

Every email has two sender addresses: the visible From address (e.g. [email protected]) and the technical envelope sender, also called the Return-Path or MAIL FROM. The latter controls where bounces go — and it’s the address that matters for SPF alignment.

On free tiers, all customers of an ESP share the same bounce infrastructure. With Brevo, for example, it looks like this:

• Return-Path: [email protected]
• From: [email protected]

SPF checks the domain in the Return-Path — so sender-sib.com. That domain is listed in Brevo’s SPF record, not yours. But for DMARC alignment, the SPF domain must match your From domain. It doesn’t. Result: SPF fail, even though the email is completely legitimate.

This isn’t a bug. It’s the design of shared bounce infrastructure.

Custom Return-Path — a subdomain like bounce.yourcompany.com that you control — is tied to paid plans at every major ESP. Only then can SPF alignment work.

Why this is (usually) not a deliverability problem

DMARC requires that either SPF or DKIM is aligned — not both. If your ESP signs with DKIM using your own domain (which all the providers mentioned do, even on free tiers, once you’ve set up the DKIM record), then DKIM carries the alignment on its own.

Emails pass DMARC despite the SPF fail because DKIM alignment is satisfied. Receiving mail servers see it the same way. Deliverability: fine.

The red bar in your report isn’t an alarm — it’s an information problem. Without context, it leads to bad decisions.

A common mistake: IT admins or marketing managers see 46% fail, interpret it as an attack or misconfiguration, and roll back the DMARC policy from p=quarantine to p=none. Real protection gets dropped — because of a phantom problem.

Why it still matters before you hit p=reject

As long as DKIM is clean, SPF fail isn’t a deliverability issue. But SPF is a second safety net — and that net has value.

Imagine your DKIM key gets compromised, or an attacker finds a way to bypass DKIM. In that scenario, SPF alignment would be the last line of defense. If you move to p=reject while SPF for your ESP traffic is permanently unaligned, you never had that net in place.

Also worth noting: some receiving systems — especially older or heavily hardened mail gateways — weight SPF fail more heavily than DMARC alignment. That’s not RFC-compliant behavior, but it happens.

Bottom line: SPF fail on ESP traffic is tolerable, but not ideal.

Decision tree: what should you actually do?

Step 1 — Check DKIM alignment. Look at your DMARC report and confirm whether the affected messages show DKIM pass with your domain. If yes: no immediate problem. If no: fix your DKIM setup with the ESP right away.

Step 2 — Assess volume and risk. What share of your total sending volume comes from the free-tier ESP? If it’s a small slice and DKIM is aligned, you can document it and keep monitoring.

Step 3 — Add a custom Return-Path. If you want to reach p=reject or close the second safety net: upgrade to a paid plan, configure a subdomain like bounce.yourcompany.com, and add it to your SPF record. That establishes SPF alignment.

Step 4 — Don’t stop monitoring. The most common mistake after this realization: people think everything is explained and stop paying attention. Real spoofing traffic looks different in the report — unfamiliar source IPs, no DKIM pass, unexpected geographies. That’s exactly what needs to stay on your radar.

Seeing the difference before it gets expensive

The SPF fail effect on shared ESP free tiers is one of the most common misreadings of DMARC reports. It causes false alarms, bad decisions, and — worse — lets actual spoofing traffic hide in the noise.

Reading your report correctly means better decisions: no premature policy rollback, no unnecessary tier upgrades, and real protection stays intact.

Check how your DMARC report looks right now and whether your ESP traffic is classified correctly: Free domain check at DMARCPulse