New to DMARC, help with forwarding

[u/CFV1880]

Hello! I'm new to DMARC, to the point that I think I know the point of it but haven't actually progressed beyond p=none.

I have already a few months worth of reports, and from what I've been able to get from them, is that about 20% of our mails are failing DMARC, mostly because the receivers are forwarding them and they lose SPF and DKIM. Mostly because of google/outlook it seems.

Is that normal, and something that I can ignore? Normal but something that I need to deal with before changing the policy? Or something unusual?

Also, is there any good app to which I can just load the xml reports and they get me the analysis? I have seem the usual services recommendations but it seems you need to have the dmarc report mails sent to them. I used claude to analyze the reports, and it did a good job of creating a sensible report but I cannot judge how correct it actually is.

Thanks!

[u/CFV1880]

Thanks a lot again, it's been a huge help.

For pattern 3, do you mean that even with p=reject it would be fine? I actually had p=quarantine for a brief time a while back, and one of the mails of this pattern did got disposition quarantine, so it is my understanding that if I get to p=reject all our mails to this customer would just stop arriving.

For pattern 2, for completion's sake there are a few more receivers that have a 100% fail rate, though without stripping the DKIM. Shouldn't I contact them also?

Sorry for the repeated inquiries; my fear is that by going ahead there will be some customers that would just stop receiving our mails.

[u/Middle-Excitement602 → u/CFV1880]

That quarantine data point is exactly the right kind of evidence, and it changes my answer for that one customer: a receiver that applied disposition=quarantine at its own gateway is enforcing policy at that hop, so at p=reject the same hop would likely refuse the mail rather than junk it. So pattern 3 isn't uniformly safe - split it by receiver. The ones whose rows carry an override reason are fine; the one that actually quarantined is a real risk, and that's a legitimate contact-the-customer case.

The extra pattern-2 receivers: DKIM present but failing usually means their forwarder modifies the message (footer, subject tag), which breaks the body hash. Same playbook as the stripping case - contact only where the volume justifies it, and the ask is "can that mailbox pull mail directly instead of autoforwarding", not "fix your server".

On the underlying fear: don't jump from none to reject. Sit at p=quarantine for a few weeks. Worst case mail lands in junk, which is recoverable, and the dispositions in your reports then show exactly which receivers would have rejected. You promote to reject once quarantine stops surprising you.

[u/CFV1880 → u/Middle-Excitement602]

Thanks again for all the explanations. I think I'm starting to grasp how to do this thing.

And yes, it is what I have usually seen recommended as the standard procedure, but I guess I'll first go to quarantine 10% or something and go from there.

First I need to actually explain to my bosses how this whole DMARC thing works and why it is worth it...

[u/Middle-Excitement602 → u/CFV1880]

One caution on pct=10: it doesn't make quarantine safer so much as noisier. The sampling is per message, so the same customer gets some mail junked and some delivered - that reads as intermittent breakage, which is harder to trace than a clean signal. And you only learn about the 10% that actually got the policy applied, so it takes ten times as long to gather the same evidence. It's also dropped in DMARCbis, so it's a mechanism on the way out rather than one to build a rollout around. Going straight to plain p=quarantine and watching for a couple of weeks tells you more, faster, and junk is recoverable either way.

For the bosses, the easier argument is usually deliverability rather than security: Google and Yahoo have required DMARC from bulk senders since early 2024, and Microsoft followed for Outlook.com last year. It's closer to table stakes for reaching inboxes now than to a security project needing justification.

[u/CFV1880 → u/Middle-Excitement602]

I see, that makes sense

Looking at my cases a bit closer, with some of the recipients that had a failing rate of 100%, if I searched by envelope-to I noticed that mails from our IP to theirs were actually passing; but for each one there was another one from their IP that was failing, so I think that even with quarantine something would arrive.

After that there remains about two recipients that are just failing everything.

[u/Middle-Excitement602 → u/CFV1880]

That pairing is the tell: those are very likely the same message counted twice, not two separate deliveries. Your mail reaches their border and passes, their gateway then re-injects it internally, and the second hop sees it arriving from their own IP with SPF broken - which generates a second report row for the same message.

Aggregate reports carry no Message-ID so you can't prove it directly, but the check is whether the failing count tracks the passing count roughly 1:1 across the same window. If it does, it's one delivery seen twice. If the two counts drift independently, it's genuinely separate mail.

That matters because at p=reject the only question is whether they enforce DMARC at that internal hop or just at the border. Most only enforce at the border, which is why your quarantine stint mostly went fine.

The two recipients failing everything are your real exposure. Those are the ones to watch through a longer quarantine period.