DMARC and Email Forwarding: Why Forwarded Emails Fail and How to Fix It

You set up DMARC, SPF, and DKIM, and everything looks great — until someone forwards one of your emails. Suddenly, your perfectly authenticated message fails DMARC at the final destination. The recipient never sees it, or it lands in spam. This is the single most common cause of "legitimate" DMARC failures, and it catches almost everyone off guard.

Email forwarding and DMARC have a fundamental tension. Understanding why forwarding breaks authentication — and what you can do about it — is essential for any domain owner running DMARC at enforcement.

Why Forwarding Breaks SPF

SPF works by checking whether the sending server's IP address is authorized to send email for the domain in the envelope sender (Return-Path). When you send an email from your mail server, the receiving server looks up your SPF record, finds your server's IP in the authorized list, and SPF passes.

But when a recipient forwards that email, the forwarding server re-sends it from its own IP address. The forwarding server is not in your SPF record — it belongs to the recipient's mail provider, not yours. When the final destination server checks SPF, it sees an IP address that is not authorized for your domain, and SPF fails.

Here is the chain of events:

1. You send email from your-server (IP: 1.2.3.4)
2. Recipient's server receives it → SPF checks 1.2.3.4 → PASS
3. Recipient forwards to another address
4. Forwarding server re-sends from (IP: 5.6.7.8)
5. Final destination checks SPF → 5.6.7.8 not in your SPF record → FAIL

This is not a misconfiguration. It is a fundamental limitation of how SPF works. Our SPF vs DMARC comparison explains this gap in more detail. SPF was designed before email forwarding became as widespread as it is today, and the protocol has no mechanism to handle the IP address change that forwarding introduces.

Why DKIM Usually Survives Forwarding

DKIM takes a fundamentally different approach. Instead of checking the sending server's IP address, DKIM attaches a cryptographic signature to the email's headers and body. This signature is generated using a private key on your mail server and can be verified using a public key published in your DNS.

The critical difference: the DKIM signature travels with the message. When a forwarding server re-sends your email, the signature remains embedded in the message headers. The final destination server can still verify the signature against your public key, regardless of which server delivered the message.

As long as the forwarding server does not modify the signed portions of the message, DKIM passes at the final destination. This is why DKIM is the primary authentication mechanism that survives forwarding.

When DKIM Breaks During Forwarding

DKIM is resilient but not invincible. The signature can break if the forwarding server modifies the message in certain ways:

Adding footers or disclaimers. Some mail systems append legal disclaimers or unsubscribe footers to forwarded messages. If the body is part of the DKIM signature (which it usually is), this modification invalidates the signature.

Rewriting content. Link tracking, content filtering, or anti-virus scanners that modify the message body will break the DKIM signature.

Altering signed headers. If the forwarding server changes headers that are included in the DKIM signature (like the Subject line), the signature becomes invalid.

In practice, most standard forwarding does not modify the message enough to break DKIM. Simple mailbox forwarding rules (like "forward all mail to my personal account") typically preserve the original message intact.

How DMARC Handles Forwarding

When a forwarded email arrives at the final destination, the receiving server evaluates DMARC by checking both SPF and DKIM:

• SPF: Usually fails because the forwarding server's IP is not in your SPF record.
• DKIM: Usually passes because the signature survives forwarding.
• DMARC result: If DKIM passes and aligns, DMARC passes — even though SPF failed.

This is exactly why DMARC uses "or" logic. It only requires one of SPF or DKIM to pass and align. DKIM acts as the safety net when SPF breaks due to forwarding. Without DKIM, forwarded messages would fail DMARC every time.

SRS: Sender Rewriting Scheme

SRS (Sender Rewriting Scheme) is a technique that some forwarding servers use to work around SPF failures. When a forwarder uses SRS, it rewrites the envelope sender (Return-Path) to use its own domain instead of yours.

Here is how it works:

Original Return-Path: bounce@yourdomain.com
SRS-rewritten Return-Path: SRS0=hash=tt=yourdomain.com=bounce@forwarder.com

After the rewrite, the forwarding server's domain (forwarder.com) is in the envelope sender, so SPF is now checked against the forwarder's SPF record instead of yours. The forwarder's own IP is in their SPF record, so SPF passes.

However, there is a catch for DMARC. The SPF-authenticated domain is now forwarder.com, which does not align with your "From" domain. SPF passes but does not contribute to DMARC alignment. DMARC must still rely on DKIM to pass.

SRS helps prevent SPF-based bounces and rejections at the network level, but it does not solve DMARC alignment on its own. It is a partial fix that works alongside DKIM, not a replacement for it.

ARC: The Modern Solution

ARC (Authenticated Received Chain) is a newer protocol designed specifically to solve the forwarding problem for DMARC. When a mail server forwards a message, it can add ARC headers that preserve the original authentication results.

ARC works like a chain of trust. Each server that handles the message adds its own ARC seal, recording what it saw when it received the message. The final destination server can look at this chain and see that the original message passed SPF and DKIM at the first hop, even if those checks fail at the final destination.

Major providers like Google, Microsoft, and Yahoo support ARC. When these providers receive a forwarded message that fails DMARC but has a valid ARC chain from a trusted forwarder, they can choose to override the DMARC failure and deliver the message.

The important thing for domain owners: ARC is handled by mail providers, not by you. You do not need to configure anything on your domain for ARC to work. It is a server-side protocol that forwarding providers and receiving providers implement between themselves.

For a deeper dive into how ARC works, see our DMARC and ARC guide.

Practical Fixes for Forwarding-Related DMARC Failures

If you are seeing DMARC failures caused by forwarding, here are the steps to take.

Ensure DKIM Is Configured

This is the single most important fix. If you have DKIM set up and the signatures survive forwarding, DMARC will pass regardless of SPF failures. Generate your DKIM keys at dkimcreator.com and configure signing for every service that sends email as your domain.

Use Relaxed Alignment

Make sure your DMARC record uses relaxed alignment (the default) rather than strict. With relaxed alignment, a DKIM signature from a subdomain like mail.yourdomain.com still aligns with yourdomain.com in the "From" header. Strict alignment requires an exact match, which can cause unnecessary failures.

Check your record for the adkim tag. If it is set to s (strict), consider changing it to r (relaxed) or removing it entirely (relaxed is the default).

Monitor Your Reports

DMARC aggregate reports will show you exactly which messages are failing and why. Look for patterns: if you see consistent SPF failures from the same IP ranges with DKIM passing, those are likely forwarded messages behaving as expected. If you see both SPF and DKIM failing, the forwarding server may be modifying your messages.

Communicate with Heavy Forwarders

If you run an organization where employees frequently forward corporate email to personal accounts, make them aware that forwarding can affect delivery. Google Workspace administrators should pay special attention to auto-forwarding rules that users set up, since these are a common source of DMARC failures. Where possible, encourage the use of email clients that support multiple accounts rather than forwarding rules.

Check DKIM Signature Scope

When configuring DKIM, consider which headers are included in the signature. At minimum, the "From" header should always be signed. Including too many headers can increase the chance of signature breakage during forwarding, while including too few reduces the security benefit.

The Big Picture

Email forwarding is not going away, and DMARC enforcement is becoming more common. The solution is not to weaken your DMARC policy — it is to make sure your authentication can survive the forwarding path. DKIM is the key piece. Organizations with self-hosted email servers have full control over DKIM signing configuration, which makes them well-positioned to solve forwarding issues at the source. With DKIM properly configured, your emails will authenticate correctly whether they are delivered directly or forwarded through multiple servers.

If you are running DMARC at enforcement and seeing forwarding-related failures in your reports, do not panic. As long as DKIM is in place and passing, the failures you see for SPF are expected and the overall DMARC result should still be a pass.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.