Why forwarded mail still passes DMARC (sometimes)

What a forwarder actually does

An email forwarder is anything that receives a message addressed to one mailbox and re-delivers it to a different one. The most common forms:

• Personal forwarding rules — Gmail's "forward all incoming mail to alice@example.com" setting.
• Catch-all aliases — info@yourcompany.com configured to forward to a real human's mailbox.
• Corporate forwarders — old IT setups where a former employee's address auto-forwards to a successor.
• Mailing lists — listserv-style ones, which forward each inbound message to a list of subscribers.

From the receiving server's perspective, all of these look similar: a connection arrives, claiming to deliver mail with a From: header set to the original sender, but the connection is being made by the forwarder's server, not the original sender's.

That distinction is what breaks SPF.

Why SPF breaks during forwarding

SPF answers: "is the IP connecting to me on the sender's published list of allowed senders?" When mail is forwarded, the connecting IP is the forwarder's server. The forwarder isn't listed in the original sender's SPF record (why would it be — it's not part of their normal sending infrastructure). So SPF authentication fails.

This is not a bug — SPF is doing exactly what it's designed to do. It's just that the protocol predates widespread mail forwarding patterns, and forwarding is fundamentally incompatible with "the connecting IP must be in the sender's list." Any solution has to come from somewhere else in the stack.

Why DKIM usually survives

DKIM signs a chunk of the message — typically critical headers (From, Subject, Date, To, etc.) plus the body, plus a hash of both. The signature travels in the message itself, in a DKIM-Signature: header.

When a forwarder relays the message unchanged, the signature is still valid at the destination. The receiver fetches the original sender's public key from DNS, verifies the signature against the message it received, and gets a clean pass. The forwarder doesn't even need to know DKIM exists — it just delivered bytes.

DKIM breaks when the forwarder modifies the message in flight. Common culprits:

• Subject-line tagging — some mailing lists prepend [list-name] to the subject. That changes a signed header, breaking the signature.
• Footer addition — listserv unsubscribe footers are appended to the body, changing the body hash, breaking the signature.
• Header rewriting — content filters that reformat headers, anti-spam tools that add scoring headers ABOVE the DKIM line in a way that affects canonicalization.

Modern listserv software (Mailman 3, GroupServer, etc.) handles this explicitly by rewriting the From: header to the list's own domain — at which point the message is no longer claiming to be from the original sender, so DMARC alignment moves to the list's domain instead. That's the right fix architecturally.

The DMARC alignment rule that saves the day

DMARC's authentication rule is: pass if EITHER SPF or DKIM passes AND is aligned. The "or" is load-bearing.

Forwarded mail's typical authentication shape:

• SPF: fails (forwarder's IP isn't in your record).
• DKIM: passes (signature traveled with the message).
• DKIM alignment: passes (your DKIM signature uses d=<your-domain>, matching the From header).

Result: DMARC passes via the DKIM path. The receiver delivers normally. This is exactly why DMARC was designed with the "either-or" rule — forwarding was already widespread when DMARC was being standardized, and any rule that required SPF and DKIM to BOTH pass would have broken forwarded mail at internet scale.

See DMARC alignment, in plain English for the deeper version of this.

When forwarding breaks DMARC

Forwarded mail fails DMARC when:

• The forwarder modifies the message in a way that breaks DKIM (the cases above), AND
• SPF is also failing (because of the forwarder's IP), so neither authentication path is salvageable.

At p=none, this just shows up as a failure row in your DMARC reports — annoying but harmless. At p=quarantine or p=reject, those messages get penalized or bounced, which is when end users start complaining.

The fix path depends on who's doing the forwarding:

• Personal forwarding rules in Gmail/Outlook — these generally don't modify messages, so DKIM survives. Rarely a problem.
• Corporate forwarders running content filters — ask your IT team to disable any header/body modification on forwarded mail for trusted source domains. Most filters have an exception list.
• Old mailing-list software — push for a migration to modern software with From:-rewrite. Mailman 3 and Sympa both do this correctly out of the box.
• Mailing lists you don't control — accept the loss. Some fraction of subscribers will see your mail quarantined. The rest will see it normally.

Where ARC fits in

ARC (Authenticated Received Chain, RFC 8617) is a newer mechanism designed specifically for the forwarding problem. The forwarder cryptographically signs an attestation that says: "I received this message and at the time I received it, SPF/DKIM/DMARC results were X." Downstream receivers can choose to trust the forwarder's attestation as a substitute for their own re-evaluation.

If you've ever wondered why some forwarded mail miraculously delivers cleanly through DMARC enforcement when it shouldn't — ARC is often what's happening. The receiving server is honoring an ARC chain from a trusted forwarder.

ARC adoption status:

• Google — both signs ARC on Gmail forwarding and honors ARC chains from trusted forwarders. The reference implementation.
• Microsoft — Office 365 / Outlook.com signs and honors ARC. Coverage is good.
• Yahoo / AOL / others — partial coverage, varies by configuration.
• Smaller / older mail servers — usually no ARC. Mail forwarded through them remains exposed to the alignment-failure scenario.

From your side as a sender, there's nothing to deploy for ARC — it's a thing forwarders and receivers do for you, when both ends are ARC-aware. Worth knowing about so you understand why some forwarded rows look fine and others don't.

What to actually do

Practical takeaways:

1. Make sure DKIM is solid before you progress past p=none. DKIM is the protection against forwarder breakage. A robust 2048-bit DKIM signature on every outbound message means almost all forwarded mail survives DMARC enforcement. Rotate any 1024-bit selectors.
2. Watch for SPF-fails-DKIM-passes pattern in reports. That's the forwarder fingerprint. Volume and source IPs change but the pattern is consistent. As long as DKIM is passing in those rows, DMARC is passing — you're fine.
3. Look at SPF-fails-DKIM-fails-too rows separately. That's the breakage case — content filter or mailing list modifying messages in flight. See if the forwarder is identifiable; if so, decide whether to push for a fix or accept the loss.
4. Don't try to "fix" SPF for forwarders. Adding forwarders' IPs to your SPF record is the wrong move — it doesn't scale, the IPs change without warning, and you'd be saying "this forwarder is authorized to send as me from any of its IPs," which is significantly broader than what SPF should grant.

The forwarder-aware mental model

DMARC reports look noisier than you'd expect because forwarders are extremely common. A typical small business has multiple forwarding paths in routine use: customer-support catch-alls, founder-to-team rules, employees who set up forwards-to-personal-Gmail, etc. Almost all of those produce SPF failures with DKIM passes — clean DMARC pass on alignment.

Once you see this pattern, the report-noise mystery clears up. The question shifts from "why is so much mail failing SPF?" to "is there anything in the SPF-and-DKIM-both-fail rows that needs my attention?" The answer is usually no, but checking is the discipline.

Related

• DMARC alignment, in plain English — the either-or rule that makes forwarding survivable.
• What to do when a report shows Unknown senders — forwarders are one of the patterns covered there.
• Why 1024-bit DKIM keys are being phased out — DKIM is the load-bearing authentication for forwarded mail; key strength matters.