If DMARC looked perfectly healthy yesterday and suddenly starts failing for forwarded messages or list traffic, you are not looking at a weird edge case. You are looking at a normal email path.
Forwarders and mailing lists are exactly where DMARC gets interesting, because they change message paths and sometimes message content. SPF and DKIM react very differently to those changes.
This is the practical model to keep in your head:
SPF checks whether the server currently sending the message is authorized for the envelope sender domain.
After forwarding, the server talking to the receiver is usually the forwarder, not the original sender. So even if the original message was valid, SPF can fail at the next hop.
Google says this very directly in its forwarding guidance: forwarded messages often fail SPF, which is why DKIM becomes extra important in forwarded flows.
Tiny example:
Original sender: alerts@example.com
Original MAIL FROM: bounces@example.com
Forwarder relays to recipient mailbox.
Receiving system sees: SMTP client = forwarder.example.net
SPF for example.com is now evaluated against forwarder.example.net IP.
Result can be SPF=fail, even for legitimate mail.That behavior is expected and aligns with the DMARC/indirect-flow interoperability guidance in the RFC series.
DKIM verifies that signed parts of the message are unchanged.
Mailing lists frequently change messages in ways that are useful to humans but hostile to DKIM survival:
[List]Any of those can invalidate a DKIM signature, depending on what was signed and how it was canonicalized.
So a very common sequence is:
If this feels frustrating, that is normal. It is not usually a bad DMARC record. It is email transit behavior.
ARC (Authenticated Received Chain) lets intermediaries attach cryptographically signed authentication results they observed earlier in the path.
In plain terms: a forwarder or list can say, "when this arrived here, auth looked like this," and seal that statement.
Receivers can then decide whether to trust that ARC chain for local handling decisions.
If you want the full ARC mechanics (headers, chain validation, and trust model) in one place, read What is ARC in email and how does it work? (Authenticated Received Chain explained).
Important nuance: ARC does not replace SPF, DKIM, or DMARC. ARC provides extra context that can help a receiver avoid treating all forwarded/list traffic as equally suspicious.
If you run a sending domain:
If you run forwarding or mailing-list infrastructure:
If you operate receiving policy:
When users say "messages from example.com are failing DMARC only after forwarding," inspect these first:
Authentication-ResultsARC-Authentication-ResultsARC-SealDKIM-SignatureReturn-PathYou are usually confirming one of these patterns:
For a focused refresher on parsing auth headers quickly, see DMARC troubleshooting: read Authentication-Results headers and fix alignment failures.
Treat forwarding and mailing lists as a distinct stream during enforcement, not as random "noise." You will see clearer patterns in aggregate reporting and avoid breaking legitimate community or distribution workflows.
If you want to map those patterns in real traffic, pair this with:
Once this model clicks, forwarding/list failures stop looking random. You can explain each failure path, decide where ARC trust helps, and keep DMARC enforcement moving without guesswork.