Skip to content
Back to Blog
DMARC.WS Team··7 min read

Email Forwarding and DMARC: Why Forwarded Emails Fail and How ARC Helps

DMARCARCEmail ForwardingSPF

The Forwarding Problem

Email forwarding is one of the most common reasons DMARC authentication fails for legitimate messages. Understanding why requires knowing how SPF and DKIM behave when a message passes through an intermediary.

Why SPF Breaks on Forwarding

SPF checks whether the sending server's IP address is authorized by the domain's SPF record. When an email is forwarded:

  1. Alice sends email from alice@company.com via Company's mail server (IP: 203.0.113.10)
  2. Bob at bob@university.edu has forwarding set up to bob@gmail.com
  3. University's server (IP: 198.51.100.5) forwards the message to Gmail

When Gmail performs the SPF check, it sees the message came from University's IP (198.51.100.5), which is not listed in company.com's SPF record. SPF fails.

This is working as designed — SPF validates the direct sending server, not the original sender. Forwarding introduces a new server that the original domain never authorized.

Why DKIM Usually Survives

DKIM signatures are attached to the message itself, not the sending server. When a message is forwarded:

  • If the forwarding server doesn't modify the message, the DKIM signature remains valid
  • If the forwarding server adds headers, the signature usually still works (headers signed by DKIM are preserved)
  • If the forwarding server modifies the body (appending a footer, for example), the DKIM signature breaks

In practice, DKIM survives most simple forwarding scenarios. This is why DKIM is critical for DMARC enforcement — it's your safety net when SPF fails due to forwarding.

The DMARC Impact

DMARC requires either SPF or DKIM to pass with alignment. In the forwarding scenario:

  • SPF fails (wrong sending IP)
  • DKIM passes if the message body isn't modified

If DKIM passes and the d= domain aligns with the From domain, DMARC passes. The forwarding is invisible to DMARC.

But if DKIM also fails (because the forwarder modified the message), both mechanisms fail and DMARC fails. With p=reject, the message is dropped. The legitimate forwarded email never reaches its destination.

Common Forwarding Scenarios

Simple Auto-Forward

University email forwarding to Gmail, old email address forwarding to new one, etc. DKIM usually survives. DMARC typically passes.

Mailing Lists

Mailing list servers (Mailman, Google Groups, LISTSERV) often:

  • Rewrite the Subject line (adding [list-name])
  • Modify the body (adding footer/unsubscribe links)
  • Rewrite the From header (to the list address)

These modifications break DKIM, and SPF already fails. The From rewrite actually helps DMARC in some cases — if the list rewrites From to its own domain, it sends as the list domain, not yours. But if it preserves the original From, DMARC fails.

Security Gateways

Email security appliances that scan and modify messages can break DKIM signatures if they alter headers or body content. This is a common issue in enterprise environments where messages pass through multiple security layers.

Enter ARC: Authenticated Received Chain

ARC (RFC 8617) was created specifically to solve the forwarding problem. It allows intermediate mail servers to vouch for the authentication results they observed.

How ARC Works

When a forwarding server receives a message that passes authentication:

  1. It records the authentication results in an ARC-Authentication-Results header
  2. It signs the message state with an ARC-Message-Signature header
  3. It adds an ARC-Seal header that chains to any previous ARC headers

Each intermediary adds its own set of ARC headers, creating a chain of trust. The final receiver can look at this chain and say: "Even though SPF fails now, the first forwarder verified that SPF passed when the message was originally received."

ARC Headers Example

ARC-Seal: i=1; a=rsa-sha256; d=university.edu; s=arc-key;
  cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=university.edu;
  s=arc-key; h=from:to:subject:date; b=...
ARC-Authentication-Results: i=1; university.edu;
  dkim=pass header.d=company.com;
  spf=pass smtp.mailfrom=company.com;
  dmarc=pass header.from=company.com

The i= tag is the instance number, incrementing with each forwarder in the chain. The cv= (chain validation) tag indicates whether the previous ARC chain was valid.

ARC Limitations

  • Trust-based: Receivers must trust the ARC signer. A malicious intermediary could fabricate ARC headers.
  • Not universally adopted: ARC is still rolling out across the email ecosystem.
  • Receiver discretion: Receivers are not required to honor ARC results. Most major providers (Google, Microsoft) do, but some don't.
  • Doesn't fix the root cause: ARC is a workaround for forwarding, not a replacement for proper authentication.

Practical Solutions

For Domain Owners

  1. Always configure DKIM: It's your best defense against forwarding-related failures. SPF will fail on forwards, but DKIM can survive.
  2. Monitor DMARC reports: Look for patterns of DKIM failures from known forwarding services.
  3. Don't panic about forwarding failures: Some level of forwarding failure is expected and unavoidable. Focus on your overall pass rate.

For Users Who Forward Email

  1. Use IMAP/POP fetch instead of forwarding: Configure your destination mailbox to pull messages from the original server, rather than having the original server forward them. This avoids the forwarding problem entirely.
  2. Whitelist known forwarders: If you use Google Workspace or Microsoft 365 as the destination, configure trusted forwarder settings.

For Mailing List Operators

  1. Rewrite the From header: Change the From address to the mailing list domain. This is the most reliable fix. The original sender's address can go in Reply-To.
  2. Implement ARC signing: Add ARC headers so downstream receivers can validate the chain.
  3. Avoid modifying the body: If possible, add list metadata in headers rather than appending to the body.

Checking ARC Support

To see if your email provider supports ARC, check the Authentication-Results header of a forwarded message:

Authentication-Results: mx.google.com;
  arc=pass (i=1 spf=pass dkim=pass dmarc=pass);
  dmarc=fail (p=REJECT)

Here, DMARC fails based on direct authentication, but ARC passes because the intermediary vouched for the original results. Gmail will typically deliver this message despite the DMARC failure.

Summary

Email forwarding is a known challenge for DMARC authentication. SPF always fails on forwarding, while DKIM usually survives if the message body isn't modified. ARC provides a trust chain that lets receivers honor the original authentication results.

The practical takeaway: DKIM is your most important protocol for handling forwarding, and some forwarding failures are normal and expected. Don't let forwarding-related failures prevent you from reaching p=reject — they're an acceptable trade-off for domain protection.