Your DMARC Pass Rate Says 41%. Nothing Is Broken. Here's Why.

I build a DMARC monitoring platform for a living. Last week, my own dashboard fooled me.

Scanning down my domains list, one client jumped out: a small Australian auto-electrical business, sitting at p=reject, showing a 41% pass rate in angry red, on a couple of hundred emails a week. Every other domain on the page was green.

My first theory came fast and felt right: their mail must be going out without DKIM. It's failing authentication and bouncing at the reject wall. We have a problem.

I was wrong. And the way I found out is worth sharing, because if the person who built the dashboard can misread it, so can you — and this exact false alarm is probably the most common panic in DMARC monitoring.

The Tell I Should Have Noticed Immediately

Here's the thing about a domain at p=reject: it has no quiet failure mode.

If a business's legitimate email genuinely stops authenticating — DKIM key missing, SPF record wrong — their mail doesn't slip silently into spam. Receivers bounce it. Invoices don't arrive. Customers reply to nothing. The phone rings within a day.

The phone was not ringing. This client had been at reject for months, sending happily the entire time. A 41% pass rate alongside total silence isn't evidence of breakage — it's evidence that the failing 59% was never their real mail in the first place.

That's rule one: at p=reject, the absence of screaming is data.

The Five-Minute Test That Settles It

Arguing with a dashboard is pointless when you can ask a mail receiver directly. I sent a test email from the client's mailbox to a Gmail address, opened Show original, and read Google's verdict:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=default header.b=Xy12abcd;
       spf=pass (google.com: domain of [email protected] designates 203.0.113.10 as permitted sender) [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com.au

Pass, pass, pass — at full reject. DKIM signing was alive and well. The domain's actual sending path (webmail → cPanel → an outbound relay) was perfectly healthy, and Gmail said so in writing.

So if their real mail authenticates flawlessly... what was the 59% that failed?

The Twist: My Test Email Answered That Too

Here's where it gets good. The Gmail account I'd sent the test to had auto-forwarding switched on. So after Google verified the email and filed it, Google re-sent it to another mailbox.

I pulled the headers on that forwarded copy. Look at what happened to it:

• It now arrived from a Google IP address — not from the client's mail server.
• The envelope sender had been rewritten to the Gmail account (that's how forwarding works), so SPF no longer aligned with the client's domain.
• The only thing keeping DMARC alive was the DKIM signature riding inside the message — which happened to survive because Gmail didn't modify the body.

One email, one journey, both halves of the story: authenticated cleanly at the front door, then transformed by forwarding into exactly the kind of "suspicious" traffic that tanks a pass rate.

And if that forwarder had modified the message — added a footer, rewritten links the way security gateways like Mimecast routinely do — the DKIM signature would have died in transit, the forwarded copy would have failed everything, and a receiver enforcing my client's reject policy would have binned it. Correctly. That bounce then shows up in DMARC reports as a "failure" against the domain.

What a Low Pass Rate Actually Measures at p=reject

Multiply that forwarded email by every staff member who auto-forwards work mail to a personal account, every recipient whose company routes inbound mail through a rewriting security gateway, every mailing list that stamps a footer — and you get this client's real 30-day picture:

• 1,122 emails reported against the domain
• 663 failed both SPF and DKIM — almost all of them the client's own legitimate mail, re-sent by recipients' forwarders and gateways, arriving at the next hop with broken authentication
• A residue of about a dozen genuinely unauthenticated messages from unknown infrastructure — the actual spoofing attempts, correctly rejected

Their pass rate for authorized senders — mail leaving their real infrastructure — was 100%.

This is the counterintuitive core of it: once you reach p=reject, your raw pass rate stops measuring your email health and starts measuring how much of your mail gets forwarded. A popular domain whose recipients forward heavily will show a worse raw pass rate than a dead domain nobody emails. The number goes red precisely because people find your email worth passing along.

How to Tell a False Alarm From a Real Fire

Next time a DMARC pass rate makes your stomach drop, run this checklist before you touch a DNS record:

1. Is anyone actually complaining? At p=reject, real breakage bounces real mail. Silence strongly suggests forwarding noise.
2. Check the pass rate for authorized senders only. If your known infrastructure (your mail host, your CRM, your invoicing tool) is passing at ~100%, your sending is healthy regardless of the headline number.
3. Look at where the failures come from. Failures from Google, Outlook.com, and security-gateway IP ranges are almost always your own mail being re-sent. Failures from infrastructure nobody recognises are the real spoofing.
4. Look for the DKIM-survivor pattern. Forwarded mail that arrives with SPF failed but DKIM still aligned is the signature of benign forwarding — the message travelled, but nobody tampered with it.
5. Send the five-minute test. Email a Gmail account you control, open Show original, and read the Authentication-Results block (or paste the headers into our free Email Header Analyzer and let it read them for you). dkim=pass with your domain ends the argument.

The Fix I Actually Made

The client needed nothing fixed. The product did.

The dashboard's security analysis had already classified those 663 failures correctly — the detail view plainly said most were the client's own mail re-sent through recipient gateways, not an attack. But the list view, the page you scan across fifty domains at breakfast, led with the raw pass rate. The truthful number was one click deep; the misleading one was in red at the top.

So that's changing. The domains list is moving to lead with authorized-sender pass rate, with forwarding losses reported separately instead of blended into a single scary figure. If a metric can spook the person who built it, it's the metric that's broken.

Test Your Own Domain Right Now

Want Gmail's verdict on your email in the next five minutes? Send a message through our free Email Authentication Tester — it reads the headers for you and tells you exactly what SPF, DKIM, and DMARC saw, in plain English.

And if you're staring at a scary pass rate across a whole portfolio of domains, DMARC Busta separates your real senders from forwarding noise and only worries you when something is genuinely on fire. Your first domain is free, no card required.

Gary Hanley runs DMARC Busta from Perth, Western Australia, and has been keeping small-business email alive for nearly twenty years.

References and Further Reading

• RFC 7960 — Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows: the IETF's own account of why forwarding, mailing lists and gateways break DMARC
• RFC 8617 — The Authenticated Received Chain (ARC) Protocol: how cooperating forwarders preserve upstream authentication results
• RFC 7489 — Domain-based Message Authentication, Reporting and Conformance (DMARC)
• DMARC Busta — Securing email forwarding scenarios
• DMARC Busta — Understanding DMARC reports: a practical guide
• DMARC Busta — free Email Authentication Tester and Email Header Analyzer

The report figures in this article come from one client domain's DMARC aggregate reports over a single 30-day window and are point-in-time. The Gmail Authentication-Results block is reproduced with placeholder domain and IP values; your own headers will carry additional fields.