How email forwarding breaks authentication

You set up SPF, DKIM, and DMARC. Everything passes. Then one recipient forwards your message to another mailbox and authentication breaks. The email lands in spam or gets rejected entirely. This is not a bug in your configuration. It is how forwarding works, and it has been a known problem since authentication protocols were designed.

What happens when an email is forwarded

There are two types of forwarding, and they break different things.

Redirect (server-side forwarding). The intermediary server receives the message and sends it onward without changing the From header. The envelope sender (MAIL FROM) changes to the forwarding server’s address. The body may or may not be altered: some servers add footers, modify headers, or re-encode MIME parts.

Resend (manual forwarding). The user clicks “Forward” in their mail client. A new message is composed with a new envelope, new headers, and the original content quoted or attached. From the authentication standpoint, this is a completely new email. The original sender’s SPF, DKIM, and DMARC no longer apply because the From address belongs to the forwarder. This type is not the problem. Server-side redirect is.

SPF: the first thing to break

SPF validates the sending IP against the DNS record of the envelope sender’s domain. When server B forwards a message originally sent by server A, the final destination (server C) sees the connection from server B’s IP. Server B is not listed in the original domain’s SPF record. Result: SPF fail.

Here is what the authentication header looks like after a forward:

Authentication-Results: mx.destination.com;
    spf=fail (sender IP is 203.0.113.50) smtp.mailfrom=forwarder.net;
    dkim=pass header.d=original-sender.com;
    dmarc=fail (p=NONE sp=NONE) header.from=original-sender.com

SPF was designed before widespread forwarding. The protocol has no mechanism to account for intermediary hops. Some forwarding servers rewrite the envelope sender using SRS (Sender Rewriting Scheme), which patches the SPF problem but introduces its own complications: bounce handling becomes harder, and the rewritten address looks unfamiliar in logs.

SRS rewrites the envelope MAIL FROM to something like:

SRS0=HHH=TT=original-sender.com=user@forwarder.net

Now server C checks SPF against forwarder.net, which passes because server B is authorized for that domain. Problem solved, but only for SPF. DMARC alignment is still broken because the From header still says original-sender.com, and SPF now aligns with forwarder.net.

DKIM: survives forwarding, sometimes

DKIM signs specific headers and the body of the message. Since the signature is attached to the content rather than the sending IP, a simple forward that does not alter the message preserves the DKIM signature. The destination server verifies it against the original domain’s DNS, and it passes.

This is why DKIM is the primary authentication mechanism that survives forwarding. But “does not alter the message” is a strong assumption. Forwarding servers modify content more often than you would expect:

• Mailing lists (Mailman, Google Groups, Listserv) add footers, edit the Subject line, or change the Reply-To header.
• Corporate gateways append legal disclaimers to the body.
• Security appliances rewrite URLs for click-time scanning (Proofpoint, Mimecast, Barracuda).
• Some servers re-encode the MIME structure, switching between quoted-printable and base64, or stripping unnecessary parts.

Any of these changes invalidates the DKIM body hash. The header hash may survive if signed headers were not modified, but once the body hash fails, the entire signature fails:

Authentication-Results: mx.destination.com;
    spf=fail smtp.mailfrom=forwarder.net;
    dkim=fail (body hash did not verify) header.d=original-sender.com;
    dmarc=fail header.from=original-sender.com

At this point both SPF and DKIM fail. DMARC requires at least one to pass with alignment. Neither does. The message is treated as unauthenticated.

DMARC: the cascading failure

DMARC checks two things: did SPF or DKIM pass, and does the passing domain align with the From header domain. After forwarding:

• SPF fails (wrong IP) or passes for a different domain (SRS rewriting).
• DKIM fails if the body was modified, or passes if untouched.

If DKIM passes, DMARC alignment works because the DKIM d= domain matches the From header. This is the one scenario where forwarding does not break authentication. Everything else results in DMARC failure.

With p=none, DMARC failure is just a report entry. With p=quarantine, the message goes to spam. With p=reject, it is dropped entirely. And you, the original sender, may never find out: the forwarding recipient just stops receiving your emails.

This creates a real problem for organizations moving from p=none to p=reject. DMARC aggregate reports show a spike in failures. Some of those are phishing attempts being blocked. Some are legitimate forwards. Telling them apart requires examining the source IPs and correlating them with known forwarding services.

ARC: the protocol built to fix this

Authenticated Received Chain (ARC, RFC 8617) was designed specifically for the forwarding problem. The idea is simple: each intermediary that handles the message records the authentication state as it was at the time of receipt, then signs that record.

ARC adds three headers at each hop:

• ARC-Authentication-Results — the authentication results as seen by this hop.
• ARC-Message-Signature — a DKIM-like signature over the message at this point.
• ARC-Seal — a signature over all previous ARC headers, creating the chain.

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.net; s=arc-20260101;
    cv=none; b=dGhpcyBpcyBhIHNpbXBsaWZpZWQgZXhhbXBsZQ==
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.net;
    s=arc-20260101; h=from:to:subject:date;
    bh=abc123...; b=xyz789...
ARC-Authentication-Results: i=1; forwarder.net;
    spf=pass smtp.mailfrom=original-sender.com;
    dkim=pass header.d=original-sender.com;
    dmarc=pass header.from=original-sender.com

When the final destination receives the message with broken SPF and DKIM, it can look at the ARC chain and see that the first hop verified everything successfully. If the destination trusts the forwarding server (and its ARC signature validates), it can override the DMARC failure.

Gmail, Microsoft 365, and Yahoo all evaluate ARC when making DMARC override decisions. Google has stated explicitly that ARC results factor into their delivery decisions for forwarded mail. ARC is not a guarantee, though: the receiving server decides whether to trust the intermediary, and not every forwarder implements ARC.

Mailing lists: the worst case

Mailing lists (Mailman, Google Groups, LISTSERV) are the most aggressive type of forwarder. They typically modify the Subject (adding a prefix like [list-name]), add or replace the Reply-To header, append a footer with unsubscribe instructions, and sometimes rewrite the From header entirely.

This breaks DKIM because the signed headers and body no longer match. SPF fails because the list server’s IP is not in the original sender’s SPF record. DMARC fails on both counts.

The common workaround: the mailing list software rewrites the From header to its own domain and puts the original sender in Reply-To. Mailman 3 and Google Groups do this by default when the sender’s domain has a strict DMARC policy. It works, but recipients who expect to see the actual sender’s address will be confused.

What senders can actually do

You cannot control what happens after your message leaves your infrastructure. But you can minimize the damage.

Sign with DKIM correctly. Use a 2048-bit key (1024 is still accepted but provides less margin). Sign the headers that matter: From, To, Subject, Date, MIME-Version, Content-Type. Avoid over-signing headers that intermediaries routinely modify: if you sign a header that gets changed, the entire signature fails.

Use l= tag with caution. The DKIM l= (body length) tag allows a signature to cover only the first N bytes of the body. Content appended after that point does not invalidate the signature. In theory, this lets footers be added without breaking DKIM. It also opens a security hole: an attacker can append arbitrary content to a signed message. Most security guidance recommends against using it.

Monitor DMARC reports. Aggregate reports (rua) show you exactly which IPs are sending mail on your behalf and whether authentication passed. Consistent failures from known forwarding services (university mail systems, corporate gateways, mailing list servers) point to forwarding, not spoofing.

Ramp up DMARC policy gradually. Move from p=none to p=quarantine; pct=10, then increase pct over weeks while watching reports. This limits the blast radius of forwarding-related failures during the transition.

Communicate with your recipients. If parts of your audience use university or corporate email that forwards to Gmail or Outlook, a simple note in onboarding (“add our address to your contacts”) will not fix authentication, but it reduces the chance of manual spam reports that compound the problem.

Diagnosing forwarding failures

When a recipient reports missing emails, ask them to check raw headers. The key fields:

# Check authentication results
Authentication-Results: ...
  spf=fail ...
  dkim=fail (body hash did not verify) ...
  dmarc=fail ...

# Look for ARC headers - presence means
# an intermediary tried to preserve auth state
ARC-Authentication-Results: i=1; ...
  spf=pass ...
  dkim=pass ...

# Check Received headers to trace the path
Received: from forwarder.net (203.0.113.50) by mx.destination.com ...
Received: from mta.original-sender.com (198.51.100.25) by forwarder.net ...

If you see ARC headers with passing results at hop 1 but failing results at the destination, the forwarding server is doing its part. The destination server chose not to trust the ARC chain, or does not support ARC at all.

No ARC headers means the forwarding server is not ARC-aware. The authentication state from the first hop is lost entirely.

How big is the problem

Forwarding is common. Alumni email addresses at universities forward to personal Gmail or Outlook accounts. Small businesses use domain email that redirects to a shared inbox. Users set up auto-forwarding between accounts. IT departments configure gateway relay rules.

Google reported in their DMARC deployment analysis that forwarding is the leading cause of legitimate DMARC failures. If you send to B2B audiences in higher education or corporate environments, expect 5-15% of your recipients to receive your email through at least one forwarding hop.

For senders with strict DMARC policies, this means a measurable portion of legitimate recipients may not receive their messages, unless DKIM survives intact and the forwarding path does not modify the email body.

Protocol behavior after forwarding

DKIM is your only real defense against forwarding-induced authentication failure. If DKIM holds, DMARC passes via DKIM alignment. If DKIM breaks, you depend entirely on the receiving server trusting the ARC chain, and that is outside your control.