New to DMARC? Start with the fundamentals →
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're 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 isn't in your SPF record. SPF fails, because as far as it's 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's 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 doesn't 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.
Don't let forwarding stall your rollout
Here's the reassurance teams need: forwarding failures are usually safe to enforce through. You aren't the one sending the forwarded copies — an attacker can't 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've confirmed the failures in your reports are forwarding and lists rather than 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.
Frequently asked questions
Why does forwarded email fail DMARC?
Forwarding breaks authentication. When a message is auto-forwarded, the forwarding server sends it from an IP that isn't in your SPF record, so SPF fails. Mailing lists go further and modify the message (adding a subject tag or footer), which invalidates the DKIM signature too. With both broken and the From: still showing your domain, DMARC fails — even though the mail is legitimate and you didn't send the forwarded copy.
What is ARC and does it fix forwarding? ARC (Authenticated Received Chain) lets each forwarding hop record the authentication results it saw and sign that record, so a downstream receiver can see the message passed authentication before it was forwarded. Receivers that check ARC can trust legitimate forwarded mail that would otherwise fail DMARC. It helps, but it's not universal — not every receiver evaluates ARC, so it mitigates the problem rather than fully solving it.
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's honored, and enforce anyway. See what's actually failing under your domain — then move forward.