Forwarders & Mailing Lists: ARC, and Why Legitimate Mail Fails DMARC

You move DMARC toward enforcement, open your aggregate reports, and find a wave of failures — from Gmail, from a university relay, from a mailing list your team is on. Panic sets in: is enforcement going to junk legitimate mail?

Usually, no. What you are looking at is forwarding, and it fails DMARC for mechanical reasons that have nothing to do with spoofing. Understanding why — and what ARC does about it — is the difference between stalling at p=none out of fear and enforcing with confidence.

Why forwarding breaks authentication

DMARC passes when SPF or DKIM passes and aligns. Forwarding can break both:

• SPF breaks on every forward. SPF authorizes the sending IP for your domain. When a recipient auto-forwards your message, the forwarding server — their mail host, not yours — relays it from an IP that is not in your SPF record. SPF fails, because as far as it is concerned an unauthorized server sent mail as you.
• DKIM usually survives a plain forward — the signature covers the message content, so if nothing changes, it still verifies. That is the saving grace of simple forwarding: SPF fails but DKIM (and DMARC) can still pass.
• Mailing lists break DKIM too. Lists typically modify the message — prepending [list-name] to the subject, appending an unsubscribe footer. Any change invalidates the DKIM signature. Now both SPF and DKIM fail, and DMARC fails with them.

So a forwarded message with your domain still in the From: can fail DMARC while being entirely legitimate. (If the SPF-vs-DKIM distinction is fuzzy, our SPF vs DKIM explainer covers it.)

What ARC does about it

ARC — Authenticated Received Chain — exists precisely for this. When a server that supports ARC receives a message and is about to forward it, it records the authentication results it observed (SPF, DKIM, DMARC) and cryptographically signs that record into the message headers. Each subsequent hop adds its own sealed link.

A downstream receiver can then read the chain and see: this message passed authentication before it was forwarded, and a trusted intermediary is vouching for that. It can choose to honor that result instead of failing the message on the broken SPF/DKIM. In effect, ARC preserves the original verdict across hops. The deeper mechanics are in what ARC is.

The catch: ARC is only as useful as the receiver's willingness to check it. The major providers (Google, Microsoft, Yahoo) implement it and handle common forwarding gracefully, but not every receiver evaluates ARC. It mitigates the forwarding problem — it does not universally erase it.

Reading these failures correctly

The mistake is treating every DMARC failure in your reports as an attack. Forwarding failures have a recognizable signature, and learning to spot them keeps you from stalling:

• Known intermediaries. Sources like Gmail, Outlook, university or ISP mail hosts, and mailing-list servers are forwarders, not forgers.
• DKIM tells the story. A source failing SPF but passing DKIM and DMARC is a plain forward working as intended. A source failing both, from a list server that rewrites messages, is a list — legitimate, just mangled.
• Volume and pattern. Steady, low-volume failures from recognizable mail systems are forwarding. A sudden burst from an unknown network is the spoofing you actually want to block. We walk through reading these in reading DMARC aggregate reports.

Do not let forwarding stall your rollout

Here is the reassurance teams need: forwarding failures are usually safe to enforce through. You are not the one sending the forwarded copies — an attacker cannot exploit "legitimate mail sometimes gets forwarded" to slip spoofed mail past p=reject. The forwarded mail that fails was never going to be the bulk of your traffic, and the big providers handle the common cases via ARC.

So once you have confirmed the failures in your reports are forwarding and lists, not unknown senders, move to quarantine and then reject anyway. Holding at p=none to avoid inconveniencing a handful of forwards leaves your domain spoofable — a far worse trade.

Forwarding is the boogeyman that keeps domains stuck at p=none. Once you can tell a forward from a forgery in your reports, the fear evaporates: identify the legitimate intermediaries, lean on ARC where it is honored, and enforce anyway. See what is actually failing under your domain — then move forward.