Email Forwarding and DMARC

Published 27 April 2026

You set up DMARC. You progress to p=reject. Your authentication is bulletproof. And then, six months later, a customer complains: "your invoices are going to my spam folder when I forward them to my accountant." You investigate, and DMARC reports show the forwarded copy as failing — which is correct, but unexpected. The original mail was authenticated; the forwarded copy isn't.

This is the forwarding problem, and every DMARC-enforcing domain hits it eventually. Understanding why it happens and what to do about it is the difference between confidently rolling out enforcement and tip-toeing around it.

Why Forwarding Breaks SPF

SPF authorises specific IPs to send mail on a domain's behalf. When mail is forwarded:

1. Original sender (example.com) sends mail to [email protected].
2. Customer has an auto-forward rule sending mail to [email protected].
3. Gmail forwards the mail to the accountant. The connection now comes from Google's IP, not example.com's.
4. The accountant's mail server checks SPF on the example.com domain. Google's IP isn't in example.com's SPF record.
5. SPF fails.

The forward has changed the connection IP, but not the From header — so SPF, which checks against From, fails. There's nothing wrong with the message; the protocol just doesn't survive forwarders.

Why DKIM Sometimes Survives

DKIM signs the message contents (specific headers and the body). The signature is in the headers and travels with the message. As long as the forwarder doesn't modify the signed headers or body, DKIM survives forwarding.

Cases where DKIM survives:

• Plain auto-forwarders (Gmail's filter-based forwarding, Outlook's rules) don't modify the message.
• Most aliases (info@→ a real mailbox) don't modify the message.
• Some mailing lists pass messages through without modification.

Cases where DKIM also breaks:

• Mailing lists that prepend [List Name] to the subject line modify the Subject header (which is usually signed). Signature breaks.
• Lists that add a footer ("To unsubscribe, click here") modify the body. Body hash breaks.
• Antivirus gateways that add disclaimers or stripped attachments modify content. Signature breaks.
• Aggressive whitespace canonicalization in old MTAs (rare in 2026).

DMARC's Alignment Rule

DMARC requires either SPF or DKIM to pass with alignment — meaning the authenticated domain must match (or fall under) the From domain.

Critically, DMARC only needs one of SPF or DKIM to pass. So:

• Forward that breaks SPF but preserves DKIM: DMARC passes. (Common case.)
• Forward that breaks both: DMARC fails. (Mailing lists that modify content, antivirus gateways.)

This is why DKIM is the critical layer for any domain doing DMARC. If DKIM is configured correctly, most forwarding survives; SPF failures alone don't break DMARC.

When Forwarding Becomes a DMARC Problem

Three patterns cause real problems:

1. Mailing lists with subject prefixes or footers

Default behaviour for many list managers (Mailman, Google Groups, AWS WorkMail). Subject prefix breaks signed Subject; footer breaks body hash. DMARC fails on the modified copy reaching list members.

Modern lists handle this with one of two approaches:

• From rewriting. The list rewrites From to be [email protected], with the original sender in Reply-To. Then signs with the list's own DKIM. Works perfectly for DMARC but loses the original sender's identity.
• ARC (Authenticated Received Chain). The list preserves the original headers, adds an ARC seal saying "I trust the original auth that was passing when I received this", and re-signs with its own DKIM. Receivers that respect ARC can then accept the modified mail without DMARC failures. (Covered below.)

2. Forwarders that modify content for filtering

Corporate antivirus gateways and quarantine systems sometimes strip attachments, replace links, or add disclaimers. All break DKIM. Most modern gateways resign with their own DKIM after modification, but only if the gateway is configured to.

3. Auto-forwarders to spam-strict receivers

Gmail user with an auto-forward to a strict B2B receiver (e.g. an Office 365 tenant with stricter-than-default SPF behaviour). SPF fails on the forwarded copy. DKIM survives. DMARC passes (because DKIM is enough), but some receivers are stricter than DMARC requires and may still flag the message.

ARC: The Forwarding Fix

Authenticated Received Chain (ARC) is a standard that lets intermediaries say "I received this mail with authentication X passing, and now I'm modifying it but I want you to know I trust the original auth." Receivers that trust the intermediary can accept the modified mail despite DMARC failing on the modified copy.

ARC adds three headers:

• ARC-Authentication-Results — what authentication results the intermediary observed.
• ARC-Message-Signature — a signature over the message at this point in the chain.
• ARC-Seal — a signature over the entire ARC chain.

Each intermediary in the chain adds its own ARC headers. The final receiver evaluates the chain — if every intermediary in the chain is trusted and the original message had passing auth, the message is accepted even though DKIM and SPF fail on the final hop.

In 2026, ARC support is widespread among major receivers (Gmail, Microsoft, Yahoo, Apple) and most major intermediaries (Google Groups, Mailman 3+, modern Microsoft Exchange). Smaller list managers and corporate gateways vary.

What You Can Do as a Sender

You can't control the forwarder, but you can maximise the chance that forwarding doesn't break your auth:

1. Make sure DKIM is rock-solid. If only one of SPF/DKIM passes after forwarding, you want it to be DKIM.
2. Don't rely on signing only headers that mailing lists modify. Don't sign Subject if your DKIM is being passed through subject-modifying lists. (But signing Subject is generally a good idea otherwise.)
3. Use relaxed canonicalization (c=relaxed/relaxed). Forgives whitespace changes. Stricter canonicalization breaks more often through forwarders.
4. Educate customers when they complain. If a customer's auto-forward is breaking DMARC, the fix may be on their end (using an ARC-aware forwarder, not modifying mail).
5. Monitor your DMARC reports for forwarder-specific failures. A mailing list provider showing as a consistent fail source is a known forwarder problem, not a spoofing concern.

What You Can Do as a Forwarder

If you operate a list, alias, or forwarder:

• Don't modify content if you can avoid it. Footers, subject prefixes, and link rewriting all break DKIM.
• If you must modify content, resign with your own DKIM. The receiver's DMARC check will then pass against your domain, not the original.
• Implement ARC. Adds an authenticated chain of custody so receivers can trust the original auth even after modification.
• Use From rewriting as a fallback for any chain that doesn't properly support ARC.

Common Misconceptions

"DMARC breaks mailing lists."

Partly true — strict DMARC at p=reject rejects forwarded copies that fail auth. But the real cause is the list breaking auth, not DMARC enforcing the rules. Lists that handle DMARC correctly (rewriting From or adding ARC) don't have this problem.

"Just turn off DKIM signing on Subject and the problem goes away."

Doesn't actually help — DMARC alignment cares about which domain DKIM signed for, not how strict the signing is. Loosening signing reduces tampering protection without solving the forwarding problem.

"SPF should just include the forwarder's IP."

You can do this if you control the forwarder ranges, but for general-purpose forwarders (Gmail forwarding, etc.) you'd be authorising every Google IP to send as your domain — defeating SPF entirely.

"ARC fixes everything."

ARC is great but adoption isn't universal. Older mailing list managers and many corporate gateways don't implement it. The receiving side also needs to evaluate ARC chains; some don't yet.

The Practical Reality

Most domains running DMARC at p=reject see a small percentage of legitimate mail failing through forwarding. That's expected and unavoidable; the cost of slightly worse forwarding behaviour is more than compensated for by stopping spoofing.

Watch your DMARC reports. The forwarders that show up consistently are a known set: Google Groups, Mailman, corporate antivirus gateways. Identifying them and noting "this is a forwarder, not a spoofer" lets you ignore that noise and focus on real signal — actual spoofing attempts and configuration drift.

DMARC Dashboard shows your current authentication setup. Combined with regular report monitoring, it's enough to keep DMARC enforcement working without surprises.