Legitimate mail fails DMARC every day, and forwarding is the largest single reason. This lesson is about predicting which protocol survives which intermediary, because that prediction is what stops you misreading a report.
Plain forwarding
A user sets their address to forward everything to a personal account. The forwarding server takes delivery, then re-sends from its own IP.
example.com ──► recipient.org ──forward──► gmail.com
SPF: connecting IP is now recipient.org's, checked against
example.com's SPF record. Not listed. FAILS.
DKIM: message body and headers unchanged. Signature still
verifies for d=example.com. PASSES, and aligns.
DMARC: PASS — one aligned pass is enough.So plain forwarding is survivable, and only if DKIM is deployed. A domain with SPF alone fails DMARC on every forwarded message, and at p=reject those messages bounce.
Mailing lists
Lists are harder, because a list does not just relay — it modifies:
- Appends an unsubscribe footer, changing the body and breaking the body hash.
- Prepends a tag to the subject, breaking the signature if
subjectwas signed. - Sends from its own infrastructure, so SPF does not align either.
| Protocol | Result through a modifying list |
|---|---|
| SPF | Fails — the list’s IP is not in the author’s record. |
| DKIM | Fails — the body hash no longer matches. |
| DMARC | Fails, with nothing left to pass. |
This is why DMARC enforcement caused real disruption to mailing lists when it was first deployed at scale. The working response, now near-universal, is From rewriting: the list replaces the author’s address with one of its own, so DMARC evaluates the list’s domain, which the list can authenticate.
From: "Alice via Dev List" <dev-list@lists.example.org> Reply-To: alice@example.com
It works, and the cost is that the author’s address is no longer the From address. That is a deliberate trade the list operator makes, not something you can fix from your end.
ARC, and what it does not do
ARC lets an intermediary record the authentication results it saw before it modified the message, and seal that record. A later receiver can then see "this list says the message authenticated correctly when it arrived".
ARC is evidence, not a pass
An ARC chain does not make DMARC pass. It gives a receiver grounds to make an exception, and only if that receiver trusts the intermediary that sealed it. Trust is established out of band, by reputation, and there is no registry of trustworthy sealers. So ARC helps where the intermediary is a large, well-known forwarder and does very little otherwise.
The prediction rule
Two questions, and between them they cover most cases:
- Did the connecting IP change? If yes, SPF will not align. Forwarding, relaying, any intermediary at all.
- Did the body or a signed header change? If yes, DKIM breaks. Footers, subject tags, link rewriting, disclaimer appenders, some antivirus gateways.
Change the hop and you lose SPF. Change the content and you lose DKIM. Do both and nothing survives. This is also the practical argument for deploying DKIM before you enforce: it is the only one of the two that survives the most common intermediary.
The full catalogue of causes — there are about eight, and forwarding is only the most frequent — is in the reference article linked below.