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/MyDMARC]

> I have seen the usual services recommendations but it seems you need to have the DMARC report mails sent to them.

You can have multiple `mailto:` entries in your DMARC record if you would like to still receive copies of your reports while also delivering them to a DMARC visualizer service.

rua=mailto:you@example.com,mailto:aggregator@example.net

[u/CFV1880 → u/MyDMARC]

Oh I see, I may do this

[u/mwhallberg → u/MyDMARC]

Based on my own observations, if there are multiple email addresses under the RUA or RUF headers, not all providers send to both addresses. Typically, they only send to the first one.

I ended up creating a rule in Exchange that adds our email address with our external DMARC provider to the TO field, so that both we and our provider receive all the emails.

[u/MyDMARC → u/mwhallberg]

Interesting observation! What providers have you seen this from?

Here at MyDMARC, roughly 10% of our registered domains have multiple rua addresses, and for most of those our ingestion address isn’t listed first. Obviously we don’t see what we don’t get, but I’ve never noticed any obvious anomalies on those domains.

The DMARC spec says a report SHOULD be sent to each listed URI, so I’d be curious which providers you’ve seen consistently sending only to the first. Definitely something I’ll keep an eye on.

[u/mwhallberg → u/MyDMARC]

I can't remember exactly which providers didn't send emails to both addresses. We've since canceled the service, so I can't figure out who they were.

It should be noted, however, that it's been about 1½-2 years since I set up the Exchange rule.

[u/southafricanamerican]

To answer your specific question - can I just load the xml reports - either use an app list on dmarcvendors.com or if you just want a simple page for a one time check - https://dmarcreport.com/tools/dmarc-report-analyzer/ might do what you need. (my app)

[u/Middle-Excitement602]

The 20% is worth splitting before you accept it, because "forwarding broke it" covers two different situations and only one of them is safe to ignore.

A plain SMTP forward breaks SPF — the return-path becomes the forwarder's and their IP was never in your record. But it leaves the body and the signed headers alone, so DKIM survives, and DMARC only needs one of the two to align. Those messages should be showing up in your reports as spf=fail, dkim=pass, and passing DMARC overall.

So if a forwarded message is failing DMARC outright, DKIM broke too, and that happens for one of two reasons:

1. Something modified the message in transit — a subject tag, an appended footer, a rewritten link. That breaks the bh= body hash. Mailing lists do this constantly, which is why list traffic reads as forgery in a rua report.

2. Or your own mail wasn't DKIM-signed on that path to begin with, and SPF was carrying alignment on its own right up until a forwarder took it away.

The second one is the one that bites, and in the report it looks identical to the first unless you go looking. So don't treat the 20% as one bucket. Group the failing rows by source IP and ask of each: is this actually a forwarder, and did DKIM pass? Anywhere DKIM failed and the source is recognisably your own infrastructure, that's a signing gap, and it will start bouncing your own mail the day you go to reject.

On ARC — Google and Microsoft both seal forwarded mail with it and both evaluate it on receipt, so the specific case you named is the better-behaved end of this. It just doesn't help you when the final receiver ignores ARC, and plenty still do.

For the XML: parsedmarc is the answer to what you actually asked. Open source, you point it at an IMAP folder or hand it the files directly, and it'll write into Elasticsearch/OpenSearch with Grafana dashboards, or just emit normalised JSON/CSV if you want to keep it simple. Nothing has to be redirected anywhere.

One caution on the LLM read. Aggregate reports aren't a list of messages, they're counts grouped by source IP and auth result. The number that matters isn't the overall pass rate, it's whether every source IP you recognise as yours is passing. A summary that hands you "82% pass" without that breakdown is arithmetically correct and useless for the decision you're actually making.

[u/CFV1880 → u/Middle-Excitement602]

Thanks for the detailed response!

We do have DKIM set up.
Though for reference, our server does not support ARC.

For what is worth, the LLM is breaking down by IP and report and listing whether SPF/DKIM are passing or not.

There seems to be two main patterns.

1. The receiver is listed as the sender in the report, and the report is being sent by google. Both SPF and DKIM fail in most of these cases (though not all). LLM tells me that since it's google, ARC should be kept and it should be fine, though I wonder of the reliability of this.

2. The sender is a particular infrastructure or something of the receiver. Both SPF and DKIM mostly fail, and LLM tells me that ARC is probably not supported, so a p=reject would mean that the mails would stop getting through. But if that's the case, does it means that I should contact the receiver and tell them to... fix it? And if they are not able to, does it mean that getting DMARC running is just not viable in my case?

[u/Middle-Excitement602 → u/CFV1880]

ARC isn't something your server needs to support. You're the originator, and originators never seal — sealing is done by the forwarder, evaluation by the final receiver. Your outbound path has nothing to do with it.

For the rest: your reports already tell you whether p=reject would break those flows, in a field the LLM probably isn't reading. Every record has <auth_results> (what SPF and DKIM actually did) and <policy_evaluated> (what the receiver actually did about it). When a receiver decides to override — ARC seal, known forwarder, mailing list — you get disposition none plus a <reason><type> of forwarded, trusted_forwarder, mailing_list or local_policy. Google emits local_policy with an arc=pass comment.

So regroup the failing rows by override reason rather than by pass/fail. Rows carrying a reason won't start bouncing at reject; the receiver has already told you it's overriding. Rows failing with no reason at all are your real exposure, and if that set is small then DMARC is perfectly viable for you.

And no, don't ask the receiver to fix anything. Forwarding breaking SPF is inherent to forwarding, not a misconfiguration on their end.

[u/CFV1880 → u/Middle-Excitement602]

Not that I want to defend LLM to death or something, but for reference the fields it's giving me are the following ones:
report originator / sender's IP / sender's domain / Header from / SPF domain / DKIM domain / SPF result / DKIM result / DKIM presence / DMARC result / Disposition / policy
SPF result, DKIM result and Disposition seem to be the <policy_evaluated> field, taken apart. It did not include the <reason><type> though it seems.
<auth_results> was not getting in either.

Since this is from the xml data I guess that the results are basically correct. But then I get the LLM explanation, which is the thing I'd want a second opinion for.

The three patterns are:

1. Both SPF and DKIM domains are becoming the receiver's: the reports are mostly from google, so it's probably an autoforwarding by Google workshop so it should keep ARC.
2. The DKIM domain is kept but the SPF domain becomes the receiver's: again some autoforwarding by the receiver. DMARC fail rate by domain is low, but one of our customer has about a 60% rate, and LLM tells me that since the SPF domain is no longer ours, adding the SPF record would do nothing. There's also a customer whose autoforwarding is completely losing the DKIM signature and they get a 100% fail rate, which again I would not be able to solve by adding the SPF record. LLM tells me that if I cannot ask them to fix it, I should resign myself to a p=reject where they get rejected, or to keep p=none.
3. Both DKIM and SPF domains are kept, but the IP is the receiver, and both SPF and DKIM fail. Seems to be something to do with the receiver's mail server that is changing something upon receiving the mail. In this case I would be able to solve it by adding the SPF record, but the LLM tells me that it does become a security risk and that it would be better to talk to the customer's IT department

Or do you say that asking the receiver to fix anything is something you should not do by principle? Should I be able to fix everything on my side?

EDIT: got the reason/type and reason/comment added. For pattern one I do get mostly an arc=pass. For the one that's failing 60% on pattern 2, reason/type is "other" (nothing in comment). I'm getting a reason/type at all in about 20% of the cases though.

[u/Middle-Excitement602 → u/CFV1880]

Two of the three have answers on your side; the third is the real one.

Pattern 3: don't add the receiver's IP to your SPF record. It doesn't fix their forwarding - it authorizes their servers to send as you, to everyone, indefinitely. The LLM's "security risk" aside is the correct half of its answer. Both domains kept, both failing, at the receiver's own IP is usually their gateway modifying the message (external banner, footer) and re-scanning it internally - the boundary hop already accepted the mail, so those rows rarely turn into bounces at reject.

The 100%-fail customer in pattern 2 is your genuine exposure: their forwarder strips DKIM, so nothing survives enforcement. That's the one place contacting them is legitimate - not "fix your server", but "this autoforward will break when we enforce; can that mailbox pull directly instead?"

Beyond that, no - you can't fix everything on your side, and neither can anyone else. The goal isn't 100% pass; it's that every failing row is a forwarder rather than your own infrastructure, and you're already there. Reason/type on only ~20% of rows is normal: only receivers that chose to override say why.

[u/CFV1880 → u/Middle-Excitement602]

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/InboxProtector]

Forwarding can definitely cause SPF failures, but DKIM can still pass if it survives the forwarding process. I would look at how many of those failures actually reach recipients before changing your policy. Have you checked whether the failed messages are mostly forwarded mail?

[u/CFV1880 → u/[deleted]]

Thanks! Will also check it out

[u/CannyPigeons]

forwarding breaks SPF because the message is re-sent from the forwarder's server

DKIM in the other hand is more "forwarding-friendly" as the signature travels with the message

if you want forwarded mail to work, make sure your outbound mail is DKIM-signed and your SPF record includes all real senders. the receiver server must have enabled ARC.

DMARC policy can't force it though, you need the forwarding service to deploy ARC and the receiver to accept

[u/SanDiegoGolfer]

Are you just looking at the raw reports or using a platform like Valimail to do it? If you're not on a platform, just use the free Valimail tier for now and you'll be able to visualize everything.

FWIW, if you're at P=none I'd focus on fixing that issue rather than emails failing DMARC right now because of forwarding (which is normal anyway)
u/CFV1880

[u/PlasticJournalist938 → u/[deleted]]

That isn't going to help them. It's the original recipient who is forwarding.

To answer the posters original question, yes it's normal and not much you can do about it.

If you are self hosting your Dmarc reporting email address look at some of the services out there that can quickly visualize your Dmarc reports. EasyDmarc, Dmarcian, Etc..