Why email forwarding breaks SPF and DKIM

10 June 2026 · 14 min read

Email almost never travels in a straight line from sender to recipient. It gets redirected by university and corporate aliases, fanned out by mailing lists, scrubbed by security gateways, and quietly relayed by intermediaries that the original sender never set up and cannot see. Every one of those extra hops is a place where authentication can break, and forwarding is the single most common cause of legitimate, well-configured mail failing SPF and DKIM. If you have ever published a clean SPF record and signed every message with DKIM, then watched your DMARC aggregate reports fill with failures from servers you have never heard of, forwarding is almost certainly what you are looking at.

This article explains exactly what happens to SPF and DKIM when a message is forwarded, why SPF breaks in nearly every case, why DKIM survives forwarding sometimes but not always, and how DMARC and ARC respond when one or both fall over. The goal is not just to name the problem but to give you a precise mental model of which identifier is tied to what, so that when you read a report or debug a complaint you know immediately what went wrong and which lever fixes it.

The two identities a forwarded message carries

To understand forwarding you have to keep two separate addresses straight in your head, because forwarding treats them completely differently.

The envelope sender, also called the Return-Path or envelope-from. This is the address used in the SMTP conversation, in the MAIL FROM command. It is not normally visible in a mail client. SPF authenticates this address, and only this address.
The header From, the address a human actually reads at the top of the message, for example news@yourbrand.com. DMARC is anchored entirely to this address. SPF on its own never checks it.

The difference between these two is the root of almost everything that follows. A deeper treatment lives in header From vs envelope from, but the short version is this: forwarding routinely rewrites the envelope while leaving the header From untouched, and that asymmetry is precisely what breaks SPF while DMARC keeps judging you on the unchanged From address.

Why SPF almost always breaks on forwarding

SPF is a check on where the connection came from. When a receiving server accepts a message, it looks at the envelope-from domain, fetches that domain's SPF record from DNS, and asks a single question: is the IP address that just connected to me authorised to send mail for this domain? If the IP is listed (directly, or via an include, a, mx or similar mechanism), SPF passes. If it is not, SPF fails.

Now picture the journey. You send a message from your authorised mail server. The first hop, your own outbound server, is in your SPF record, so SPF passes there. But the recipient has set up forwarding: their address alice@university.edu is an alias that redirects to alice@gmail.com. The university's mail server receives your message and then re-sends it onward to Gmail. Gmail now performs SPF. It looks at the envelope-from domain, which is still yourbrand.com, fetches your SPF record, and checks the connecting IP. But the connecting IP is now the university's server, not yours. The university's server is not, and should not be, in your SPF record. SPF fails.

This is not a misconfiguration. It is the inevitable, designed-in consequence of how SPF works. SPF binds authorisation to the sending IP, and forwarding by definition changes the sending IP while keeping your domain in the envelope. There is no SPF record you can publish that fixes this, because the only fix would be to authorise every forwarding server on the internet, which would defeat the entire purpose of SPF. The classic symptom is a PermError or plain SPF fail appearing in your reports against IP ranges belonging to universities, ISPs, hosting companies and corporate gateways.

The SRS partial mitigation, and its limits

Some well-behaved forwarders implement Sender Rewriting Scheme (SRS). Instead of leaving your domain in the envelope-from, the forwarder rewrites it to one of its own, something like SRS0=hash=...=yourbrand.com@university.edu. Now when Gmail checks SPF, it checks the university's domain against the university's connecting IP, and SPF passes again, because the forwarder is vouching for its own relay using its own SPF record.

SRS rescues the SPF check, but it does nothing for DMARC, and that is the catch most people miss. DMARC does not care that SPF passed for university.edu. It cares whether SPF passed for a domain that aligns with the header From, which is still yourbrand.com. After SRS, the SPF-authenticated domain is the forwarder's, not yours, so SPF is no longer aligned. From DMARC's point of view, SRS converts an SPF failure into an SPF pass that does not count. This is exactly why you cannot rely on SPF to carry a forwarded message through DMARC, and why the next section matters so much. If alignment is a new idea, DMARC alignment explained sets it out from first principles.

Why DKIM can survive forwarding

DKIM works on a completely different principle from SPF, and that difference is why it is the identifier that can survive the journey.

DKIM does not care where the connection came from. It is a cryptographic signature over the content of the message itself: a chosen set of headers, plus the message body. When you sign, your server computes a hash, signs it with a private key, and stamps a DKIM-Signature header onto the message. That header names the signing domain in its d= tag and the key location in its s= selector tag. The receiver fetches the public key from DNS at <selector>._domainkey.<d-domain>, recomputes the hash over the same headers and body, and verifies the signature.

Crucially, none of that depends on the connecting IP. As long as the signed headers and the body arrive byte-for-byte unchanged, the signature verifies no matter how many servers relayed the message in between. The university forwarder can pass your message to Gmail through ten hops and DKIM will still verify, provided nothing it relayed altered the signed content. This is why DKIM is the load-bearing identifier for any domain that wants to reach enforcement: it is the only mechanism built to survive the messy, multi-hop reality of real email. The companion piece DKIM alignment and forwarding drills into the alignment side specifically.

A valid signature is not the same as an aligned one

Just as with SPF, surviving the journey is necessary but not sufficient for DMARC. DMARC asks the stricter question: did a valid signature verify for a domain that aligns with the header From? If your platform signs as d=sendgrid.net and your From is news@yourbrand.com, the signature can verify perfectly and still do nothing for DMARC, because sendgrid.net does not align with yourbrand.com. The fix is to sign as your own domain, which most reputable platforms support through a CNAME or TXT delegation. You can confirm what d= domain currently signs your mail with the DKIM checker, and the mechanics of provisioning aligned signing are covered on the DKIM product page.

Why DKIM sometimes breaks anyway

If DKIM survives forwarding in principle, why do reports show DKIM failures on forwarded mail too? Because the guarantee is conditional: the signed content must arrive unchanged. Plenty of intermediaries change it, usually with good intentions, and any change inside the signed scope invalidates the signature. The most common culprits:

Footer injection. Mailing lists and discussion groups append an unsubscribe footer or a list banner to the body. If the body is signed (it almost always is), that single added line breaks the body hash and DKIM fails. This is the number one reason DKIM dies on mailing lists.
Subject rewriting. Many lists prepend a tag like [list-name] to the Subject. The Subject is one of the headers nearly every signer covers, so rewriting it breaks the signature.
Header reformatting. Some relays re-fold long header lines, re-order headers, or rewrite MIME boundaries. Even whitespace changes can break a signature depending on the canonicalisation in use.
Content scanning and rewriting. Security gateways that rewrite URLs (link protection), strip or rewrite attachments, or add X- warning banners inside the body all alter signed content.
Character set or encoding changes. A relay that re-encodes the body from one transfer encoding to another changes the bytes the signature was computed over.

Canonicalisation softens some of this, but not enough

DKIM offers two canonicalisation modes, simple and relaxed, and the choice affects how forgiving the signature is. relaxed header canonicalisation tolerates whitespace changes and header case differences, so it survives some benign reformatting that simple would not. But canonicalisation only normalises trivial whitespace and folding. It does not let a footer, a rewritten subject, or a stripped attachment slide. For anything that actually changes content, no canonicalisation mode will save you. The trade-offs are laid out in DKIM canonicalisation: simple vs relaxed. Relaxed/relaxed is the sensible default precisely because it maximises the chance of surviving a forwarder that touches headers without changing the meaning of the message.

This gives us the asymmetry stated in the brief, now with the mechanism behind it. SPF almost always breaks on forwarding because forwarding changes the connecting IP, which SPF is bound to, and there is no way to authorise the world's forwarders. DKIM sometimes survives because it is bound to content, not IP, so a plain redirect that touches nothing leaves it intact, while a mailing list that rewrites the body destroys it.

What DMARC does when forwarding breaks one or both

DMARC sits on top of SPF and DKIM and applies one decisive rule: a message **passes DMARC if at least one of SPF or DKIM passes and aligns** with the header From domain. It does not need both. One aligned pass is enough.

That OR is the entire reason a forwarded message often still survives. Walk through the common university-alias case again:

SPF: fails or, after SRS, passes for the forwarder but does not align. Either way, no aligned SPF pass.
DKIM: the forwarder is a simple redirect that does not touch the body. Your aligned d=yourbrand.com signature verifies. Aligned DKIM pass.
DMARC: one aligned pass exists, so DMARC passes. The message is delivered and your policy is honoured.

Now the mailing-list case:

SPF: fails or does not align, as above.
DKIM: the list appended a footer and rewrote the subject. Your signature no longer verifies. No aligned DKIM pass.
DMARC: zero aligned passes. DMARC fails. If your policy is p=reject, a strict receiver rejects the message.

This is why mailing lists are the hard case and plain forwarding is the easy one. A plain alias usually preserves DKIM, so DMARC survives. A list usually destroys DKIM and SPF, so DMARC has nothing left to pass on. The broader treatment of this scenario, including what it does to your reports, is in the DMARC forwarding problem and forwarding and DMARC.

Why this matters for your enforcement journey

The practical consequence is that forwarding failures are expected and should not, by themselves, stop you reaching p=reject. When you read your aggregate reports, you will see a tail of DMARC failures from forwarders and lists. The right question is never "are there any failures?" but "are these failures legitimate forwarded mail, or are they unaligned sources I still need to fix?". Forwarded mail that fails because a list mangled it is not a security hole; it is a known limitation of the protocols. Your real senders, the ones you control, should all reach aligned authentication before you enforce. Tools like the DMARC report analyzer exist to separate the forwarding noise from the sources that genuinely need attention, and the staged approach is described in DMARC from none to reject, safely.

A useful sanity check before you ever enforce: confirm your own published records are clean. Run your domain through the DMARC checker, the SPF checker and the DKIM checker so that any failures you then see in reports can be attributed to forwarding and intermediaries rather than to your own configuration.

ARC: how forwarders can vouch for what they broke

There is one more piece, and it is the protocol designed specifically for the forwarding problem: ARC, the Authenticated Received Chain.

The insight behind ARC is simple. When a forwarder breaks SPF and DKIM, it usually does so after having verified them itself. The university server saw your message arrive with a valid, aligned DKIM signature; it knows the message authenticated correctly at the moment it received it. The tragedy of plain forwarding is that this knowledge is thrown away. By the time Gmail evaluates the message, the original authentication state is gone, and Gmail has no way to know the message was legitimate before the forwarder touched it.

ARC lets a forwarder record and carry that knowledge forward. As a message passes through an ARC-aware intermediary, the intermediary adds three headers:

ARC-Authentication-Results, capturing the SPF, DKIM and DMARC results as the forwarder saw them on arrival.
ARC-Message-Signature, a DKIM-like signature over the message as the forwarder received it.
ARC-Seal, a signature over the chain of ARC headers themselves, so the chain cannot be tampered with.

Each hop adds its own set, building a sealed, ordered chain. When the final receiver evaluates a message that fails DMARC, it can inspect the ARC chain, verify the seals, and see that an intermediary it trusts attests "this message passed DMARC when I received it; the only reason it fails now is that I, a legitimate forwarder, modified it". The receiver can then choose to honour that attestation and deliver the message rather than rejecting it, even though raw SPF and DKIM have failed. The full mechanism is set out in ARC explained and summarised in the ARC glossary entry.

The honest limitations of ARC

ARC is genuinely useful but it is not a silver bullet, and it is important to be precise about what it does and does not give you.

It is advisory, not mandatory. A receiver is free to ignore the ARC chain entirely. ARC gives a receiver a reason to deliver borderline mail; it never forces delivery.
It depends on trust. A receiver only honours an ARC chain from intermediaries it trusts. An attacker can add their own ARC headers claiming anything, so the seals only mean something when the sealing party has a reputation worth respecting. ARC shifts the problem to "do I trust this forwarder", which is a judgement the receiver makes.
The forwarder has to implement it. Plenty of forwarders and lists still do not add ARC headers at all. If the intermediary in your failure path is not ARC-aware, there is no chain for the receiver to consult.
It does not change your DMARC result. ARC does not make SPF or DKIM pass. The message still fails DMARC on its face. ARC simply gives the receiver extra context to override the disposition.

The major mailbox providers (Gmail, Yahoo, Microsoft) both add and honour ARC, which is why a message forwarded through a large, reputable provider often still lands in the inbox even at p=reject, while the same message through an obscure list does not.

Putting it together: a debugging checklist

When you see a forwarded message fail authentication, work through it in this order:

Identify the path. Read the Received headers (or the source in your report) to see which intermediary relayed the message. A university, ISP, corporate gateway or list name is the giveaway.
Check SPF. It has almost certainly failed or gone unaligned. This is normal for forwarding and rarely the thing to fix.
Check DKIM. If DKIM also failed, ask what changed the content: a footer, a subject tag, a rewritten link, a stripped attachment. If DKIM passed and aligned, DMARC passed and there is nothing to fix.
Confirm alignment, not just validity. A verifying signature with a foreign d= does nothing. Make sure your real senders sign as your own domain.
Look for an ARC chain. If the receiver delivered the message despite a DMARC failure, an honoured ARC chain is often why.
Decide whether it matters. Forwarding failures from legitimate paths are expected and should not block enforcement. Unaligned failures from sources you control absolutely should be fixed first.

If a specific message is failing after a forward and you want a structured walkthrough of the fix, fix DKIM fails after forwarding is the targeted guide.

The takeaway

Forwarding breaks SPF because SPF authenticates the connecting server, and forwarding changes the connecting server while keeping your domain in the envelope. There is no SPF record that fixes this, and SRS, which rescues the raw SPF check, leaves SPF unaligned so DMARC still cannot use it. Forwarding breaks DKIM only when an intermediary changes the signed content: a plain redirect leaves your signature intact, while a mailing list that rewrites the body or subject destroys it. DMARC needs just one aligned pass, so well-signed mail through a simple forwarder usually survives, while mail through a mangling list usually does not. ARC exists to close the remaining gap, letting a trusted forwarder vouch that the message authenticated before it was modified, though it is advisory, trust-dependent and only as good as the intermediaries that implement it.

The single most important conclusion for anyone running a domain is this: make DKIM your primary, aligned identifier and treat SPF as the leg that will fail the moment your mail is forwarded. When you do that, the forwarding failures in your reports become predictable background noise rather than a reason to stay stuck at p=none. If you would rather not manage this by hand, our hosted DMARC and hosted DKIM products keep alignment correct and walk a domain safely to p=reject without an email outage. You can start by checking where your domain stands with the DMARC checker and reviewing the requirements for getting to enforcement.