If plain forwarding preserves DKIM, why does mine keep failing?

Almost always because the forwarder is modifying the message, appending a footer, tagging the Subject, or re-encoding the body, which changes the signed bytes and invalidates the hash. Mailing lists are the most common culprit. Stop the modification or add ARC to preserve the original result.

Will SRS fix DKIM on forwarded email?

No. SRS rewrites the envelope-from so SPF can pass against the forwarding server, but it does nothing for DKIM. If DKIM broke because the message body or headers were altered, you need relaxed canonicalization, an unmodified message, or ARC, not SRS.

Does forwarding-related DKIM failure cause DMARC to reject my mail?

It can. DMARC needs SPF or DKIM to pass and align; forwarding usually breaks SPF alignment, so if DKIM also fails, DMARC fails. Under p=reject that mail can be rejected, which is why ARC and monitoring your aggregate reports matter before tightening policy.

DKIM Fails After Email Forwarding: Why It Happens and How to Fix It

VigilDog Team · October 1, 2026 · 7 min read

A message leaves your server with a perfect DKIM signature, gets forwarded once, and lands as "dkim=fail" in the recipient's headers. It's one of the most confusing email problems because the cause isn't your setup, it's what the forwarding server did to the message in transit. Here's exactly why DKIM fails after forwarding, when it actually survives, and how to keep forwarded mail authenticated.

The surprise: plain forwarding usually keeps DKIM intact

DKIM signs a cryptographic hash of the message body and a chosen set of headers. As long as those bytes don't change, the signature stays valid no matter how many hops the message takes, the signing domain and the receiving server never need to talk to each other. So a straight "store and forward" that passes the message through untouched typically preserves DKIM just fine.

This is precisely why DMARC leans on DKIM to survive forwarding when SPF can't. The failures people see aren't caused by forwarding itself; they're caused by forwarders that modify the message on the way through.

How SPF, DKIM and DMARC verify an email

What actually breaks the signature

Any change to a signed header or to the body invalidates the hash. Forwarders and mailing lists do this constantly, often without meaning to:

Appending a footer like "Forwarded by..." or a mailing-list unsubscribe banner to the body.
Rewriting the Subject, for example prepending a list tag like "[team]".
Re-encoding the body (converting between quoted-printable and base64, or changing character sets).
Anti-spam or gateway software inserting or reordering signed headers.
Line-ending or whitespace normalization applied by an intermediate MTA.

SPF is the other half of the story

Even when DKIM survives, forwarding almost always breaks SPF. SPF authorizes the sending IP for the envelope-from domain, but a forwarder relays from its own IP, which isn't in your SPF record, so SPF fails at the final destination. That's expected behavior, not a misconfiguration.

The mitigation on the forwarder's side is the Sender Rewriting Scheme (SRS), which rewrites the envelope-from to the forwarding domain so SPF can pass against the forwarder instead. But SRS only rescues SPF; it does nothing for a DKIM signature that was broken by body edits. That asymmetry, SPF broken by the relay, DKIM broken by modification, is why forwarded mail needs a mechanism that spans both.

How to diagnose it

Open the received message and read the Authentication-Results header the final receiver added. You're looking for whether dkim shows pass or fail, and critically, which domain (the d= value) it evaluated, a fail on the forwarder's own signature is different from a fail on your original one.

If DKIM is failing, check the canonicalization your signer uses. DKIM has two canonicalization modes per part (header and body): "simple" is strict and breaks on the tiniest whitespace change, while "relaxed" tolerates common whitespace and line-wrapping normalization. Signing with relaxed/relaxed survives far more forwarding paths than simple/simple. Confirm your published selector and record are valid with a DMARC and email-auth checker so you know the signature was sound before it left.

How to fix it

There's no single switch, but the fixes stack well. Start on your own side: sign with relaxed/relaxed canonicalization and sign only the headers you need, so incidental reformatting doesn't invalidate the hash. If you control the forwarding system, a mailing list or a mail gateway, the highest-impact change is to stop mutating messages: drop the appended footer, stop tagging the Subject, and avoid re-encoding bodies.

When modification is unavoidable, the real answer is ARC (Authenticated Received Chain). ARC lets each intermediary record the authentication results it saw and cryptographically vouch for them, so the final receiver can trust that the message passed DKIM before the forwarder altered it. Pair ARC with SRS on the forwarder to keep SPF alive, and you cover both halves. Our SPF, DKIM, and DMARC fix guide walks through getting the underlying records right first, since ARC can't rescue a signature that was never valid to begin with.

What this means for DMARC

DMARC passes when either SPF or DKIM passes and is aligned with the visible From domain. Because forwarding routinely kills SPF alignment, DKIM is often the only thing standing between forwarded legitimate mail and a DMARC failure. If you're tightening a policy toward reject, this is exactly the traffic that gets caught in the crossfire, plan for it, as we describe in the DMARC p=reject rollout guide, and lean on aggregate reports to see how much of your forwarded mail is surviving.

That visibility is the part teams miss until something breaks. VigilDog's email deliverability monitoring watches your SPF, DKIM, and DMARC records and parses your DMARC aggregate reports, so you can see forwarded-mail failures as a trend instead of discovering them one angry recipient at a time.