Why forwarding breaks email authentication

26 May 2026 · 13 min read

Why forwarding is the hardest problem in email authentication

If you have ever published a DMARC record, opened your first report, and found a column of failures coming from a domain you have never heard of, there is a good chance you were looking at forwarding. Forwarding is the single most common reason that legitimate, genuinely-yours email shows up as failing authentication. It is not spoofing, it is not a misconfiguration on your side, and very often there is nothing wrong with your sending setup at all. The mail simply passed through an intermediary that broke one of the checks DMARC relies on.

This article explains exactly what happens to SPF and DKIM when a message is forwarded, why one of them almost always survives and the other almost always does not, how DMARC alignment copes (or fails to cope) with the result, and where ARC, the newer Authenticated Received Chain standard, fits in. By the end you should be able to look at a forwarded-mail failure in your reports and know whether it is harmless, whether it is costing you legitimate delivery, and what, if anything, you should do about it.

The short version, so you have the shape of it before the detail: forwarding almost always breaks SPF, usually preserves DKIM, and DMARC survives forwarding precisely because it only needs one of the two to pass and align. Everything below is the careful version of that sentence.

What "forwarding" actually means here

Before we can talk about what breaks, we need to be precise, because "forwarding" covers several different mechanisms that behave differently.

• Server-side alias or redirect forwarding. A mailbox like info@yourcompany.com is configured to redirect everything to personal@gmail.com. The receiving server accepts the message, then re-sends it onward to the final destination. The original From header is preserved. This is the classic case and the one that breaks SPF.
• Mailing lists. A list address like discuss@list.example.org receives a message and re-distributes it to every subscriber. Lists almost always modify the message: they add a subject tag like [discuss], append a footer with unsubscribe links, or change the body in other ways. This breaks DKIM as well as SPF, which makes lists the hardest case of all.
• Account-level "fetch and forward" rules. A user sets up a rule in their mail client or provider to forward certain messages to another address. Behaviour varies, but most of these re-send the message and therefore behave like server-side forwarding.
• Filtering gateways and security appliances. A message passes through an inbound security product (anti-spam, anti-phishing, a sandbox) that receives it on one side and re-injects it on the other. These often rewrite or re-sign in ways that can break or preserve authentication depending on the product.

What these have in common is an intermediary: a server that is not the original sender and not the final recipient, which accepts the message and sends it on. That intermediary is the source of the trouble, because authentication checks were designed around a direct path from sender to recipient, and forwarding inserts an extra hop the original sender never authorised.

If you want a refresher on how the three identities (the From header, the Return-Path, and the DKIM d= domain) relate to each other, the DMARC alignment guide covers that groundwork, and the glossary defines each term. This article assumes you have the basics and focuses on what changes when a message is forwarded.

Why forwarding breaks SPF

SPF authenticates the connecting IP address against the SPF record of the Return-Path (envelope-from) domain. That is the whole mechanism: when a server connects to deliver mail, the receiver looks up the SPF record of the envelope domain and asks "is this connecting IP allowed to send for this domain?".

Now follow what happens during forwarding. Suppose news@yourbrand.com sends a message to info@partner.com, and partner.com forwards everything to boss@gmail.com.

1. Your original send leaves your mail server. Gmail, Microsoft, or whoever the first recipient's provider is, sees a connection from your IP and checks it against your SPF record. It passes. So far so good.
2. partner.com accepts the message, then opens a new connection to Gmail to deliver it to boss@gmail.com. This connection comes from partner.com's IP address.
3. Gmail checks SPF for the message. But the Return-Path still references a domain whose SPF record lists your servers, not partner.com's. The connecting IP is now partner.com, which is not in that SPF record.
4. SPF returns a fail (or softfail). The message was authentically yours, but the IP that delivered it on the final hop was never authorised by the SPF record being checked.

This is not a bug. It is exactly what SPF is supposed to do: it ties authorisation to the IP that connects, and on a forwarded message the connecting IP is the forwarder, not the original sender. SPF has no concept of "this message was relayed by a trusted intermediary on behalf of someone else". The moment a different server connects, SPF for the original domain breaks.

The classic mitigation forwarders use is SRS, the Sender Rewriting Scheme. With SRS, the forwarder rewrites the envelope-from to its own domain (something like SRS0=hash=tt=yourbrand.com=news@partner.com) so that SPF will pass against partner.com's record on the second hop. This stops the message from being rejected outright for an SPF failure. But, crucially, SRS does nothing for DMARC. Rewriting the envelope to partner.com means SPF now passes for partner.com, but partner.com does not match the From header yourbrand.com, so the SPF result does not align. From DMARC's point of view, an SRS-rewritten message still has no usable SPF result. SRS solves a plain-SPF deliverability problem; it does not solve the DMARC alignment problem. For a deeper look at why a passing SPF result can still fail DMARC, see DMARC alignment explained.

The practical upshot: after forwarding, SPF cannot be relied on to carry your authentication. Whether it hard-fails on the connecting IP or is rewritten via SRS, the result does not align with your From domain. Something else has to do the work, and that something is DKIM.

Why DKIM usually survives forwarding

DKIM works on a completely different principle, and that difference is why it is the hero of forwarded mail.

DKIM does not care about IP addresses or connection paths. It is a cryptographic signature over the message itself: selected headers and the body are hashed and signed with a private key when the message is sent, and the matching public key is published in DNS. Any receiver, however many hops later, can recompute the hash, fetch the public key from the signing domain's DNS, and verify the signature. The signature travels inside the message, in the DKIM-Signature header, so it is not affected by who relays the message or from which IP.

This means that for plain forwarding that does not alter the message, DKIM passes straight through. The signature your server applied is still valid at the final destination, because nothing about the bytes that were signed has changed. And because DKIM signs with your d=yourbrand.com domain, the verified result aligns with your From header. DKIM alignment is preserved, so DMARC passes. This is the single most important reason DKIM is non-negotiable for any domain that expects its mail to be forwarded: DKIM is the only one of the two mechanisms that can survive a forwarding hop with alignment intact.

You can confirm what a domain currently signs with the DKIM checker, and the DKIM product page explains how proper signing is set up.

There is an important caveat, though: DKIM survives forwarding only if the message is not modified in a way that touches what was signed.

When DKIM breaks too: mailing lists and body modification

DKIM signs a hash of the body and of specific headers. If anything that was covered by the signature changes in transit, the hash no longer matches and the signature fails. Forwarding that re-sends a message byte-for-byte is fine. Forwarding that edits the message is not.

This is why mailing lists are the worst case. A typical list will:

• Add a tag to the Subject, turning Project update into [team-list] Project update. If the Subject header was signed (it almost always is), the signature breaks.
• Append a footer to the body, usually an unsubscribe link or list information. The body hash no longer matches, so the signature breaks.
• Sometimes change the MIME structure, re-encode the body, or convert HTML, all of which alter the signed content.

Once the body or a signed header is modified, DKIM fails. And we already established that SPF fails on forwarding too. So on a modified, forwarded message both SPF and DKIM are broken, which means DMARC has nothing left to align and the message fails DMARC outright. At p=quarantine or p=reject, that can mean your perfectly legitimate post to a mailing list lands in spam or is rejected for every subscriber whose provider enforces your policy. This specific scenario, a real service that cannot align at enforcement, is explored further in why a service is not aligned at reject.

To summarise the survival rules:

• Plain forwarding (no edits): SPF breaks, DKIM survives and aligns, DMARC passes. Harmless.
• Mailing lists and editing intermediaries: SPF breaks, DKIM breaks, DMARC fails. This is the case that actually costs you delivery.

How DMARC copes with forwarding

Here is the elegant part of the design, and the reason DMARC works at all in a world full of forwarders.

DMARC does not require both SPF and DKIM to pass. It requires **at least one of them to pass and align** with the From domain. One aligned pass is enough. This "either/or" rule is precisely what makes DMARC robust against forwarding.

Walk it through for plain forwarding:

• SPF: fails or is rewritten, does not align. No help.
• DKIM: signature still valid, d= matches the From domain, aligns.
• DMARC result: pass, on the strength of DKIM alone.

The forwarding broke SPF, but because DKIM carried the authentication through intact, DMARC still passes and the message is delivered normally. The recipient never knows anything happened. This is the everyday reality for the overwhelming majority of forwarded mail, and it is why a well-configured domain (one that signs everything with aligned DKIM) can be at p=reject and still have its forwarded mail delivered.

It is also why DKIM is the load-bearing mechanism for DMARC and SPF is not. Many people instinctively treat SPF as the primary authentication method because it is older and simpler. For DMARC survival across the real internet, the priority is the other way around. If you have to pick one to get perfect, get DKIM perfect. SPF is a useful second signal, but it is the one that forwarding destroys.

Where DMARC genuinely cannot cope is the mailing-list case, where forwarding has broken both mechanisms. There is no aligned pass left, so DMARC fails, and there is nothing DMARC itself can do about it. That gap is exactly what ARC was invented to close.

ARC: rescuing authentication after it has already broken

ARC, the Authenticated Received Chain, is a standard designed for precisely the situation where a legitimate intermediary breaks authentication. It does not prevent the break. Instead, it lets the intermediary vouch for what the authentication results were before it touched the message, so a later receiver can choose to trust that vouching and deliver the message even though SPF and DKIM now fail.

The mechanics, kept practical:

1. When a message arrives at an ARC-aware intermediary (say a mailing list), the intermediary evaluates SPF, DKIM, and DMARC as normal and records the results.
2. It then adds a set of ARC headers that capture those results and seals them with its own cryptographic signature. The key headers are the ARC-Authentication-Results (a snapshot of what passed before), the ARC-Message-Signature (a DKIM-like signature over the message as the intermediary saw it), and the ARC-Seal (which signs the chain itself so it cannot be tampered with).
3. The intermediary then modifies and re-sends the message as it normally would, breaking the original DKIM in the process.
4. When the final receiver evaluates the now-broken message, it sees that SPF and DKIM fail and DMARC therefore fails. But it also sees a valid ARC chain saying "when I, a forwarder you may choose to trust, received this message, DMARC passed for yourbrand.com". If the receiver trusts that intermediary, it can apply a local override and deliver the message instead of enforcing your p=reject.

The vital point about ARC is that it is advisory, not authoritative, and it is entirely the receiver's choice whether to honour it. ARC does not make a failing message pass DMARC. It gives the receiving system a trustworthy reason to override the failure for a known, reputable forwarder. Large providers like Gmail and Microsoft both seal and evaluate ARC, which is why mail forwarded through major mailing lists often still gets delivered to recipients at those providers even though raw DMARC has failed.

What ARC does not do is worth stating plainly, because it is widely misunderstood:

• ARC does not require any configuration on your side as the original sender. You do not publish an ARC record or add anything to your DNS. ARC is implemented by intermediaries and receivers, not by senders.
• ARC does not let an attacker bypass DMARC. The receiver only honours ARC from intermediaries it independently trusts, and the seal prevents tampering with the recorded results.
• ARC does not turn a DMARC fail into a DMARC pass in your reports. The message still reports as a DMARC failure; ARC simply influences the delivery decision at trusting receivers.

So ARC is best understood as a safety net under the mailing-list gap, operated by the ecosystem on your behalf. You benefit from it without doing anything, but you cannot rely on it universally, because not every receiver evaluates it and not every intermediary seals it.

Reading forwarding in your DMARC reports

This all becomes concrete the moment you start reading aggregate reports, because forwarding has a recognisable signature. If you have not yet set up reporting, enabling RUA aggregate reports is the first step, and the DMARC report analyzer will parse the XML into something readable.

Here is how to tell forwarding apart from genuine spoofing in the data:

• Look at the source. Forwarding failures come from the IP addresses and hostnames of real, recognisable mail providers and organisations: university mail servers, corporate gateways, well-known mailbox providers. Spoofing tends to come from residential IP ranges, unfamiliar hosting providers, or sources with no plausible reason to send your mail.
• Look at which check passed. The tell-tale forwarding pattern is DKIM pass with alignment, SPF fail. That combination means your DKIM signature survived but the relaying IP was not in your SPF record: classic plain forwarding, and harmless because DMARC still passed.
• Look for both failing together at a known list. SPF fail and DKIM fail from a mailing-list domain is the case worth attention, because those messages genuinely failed DMARC and may have been quarantined or rejected for subscribers.
• Watch the volume and consistency. A steady trickle from the same handful of legitimate forwarders is normal. A sudden spike from unfamiliar infrastructure is the thing to investigate.

The practical mistake to avoid is panicking at the raw fail count and staying at p=none because of it. Most forwarding failures in a typical report are the harmless DKIM-passed kind, where DMARC actually passed overall. Stalling enforcement over them leaves your domain spoofable for no real benefit. The right move is to identify which failures are genuine alignment problems and fix those, then proceed to enforcement. The path from monitoring to enforcement without breaking real mail is covered in reach p=reject without breaking email.

What to actually do about forwarding

You cannot stop other people forwarding your mail, and you would not want to. What you can do is make sure that when they do, your authentication survives. Concrete steps, in priority order:

1. Get DKIM perfect and aligned on every stream. This is the most important thing on the list. Because DKIM is the only mechanism that survives plain forwarding with alignment intact, every legitimate source of your mail (your mail platform, your CRM, your transactional service, your support desk) must sign with an aligned d= domain. Audit each one. A single unsigned stream is a stream that forwarding will silently break. Verify signing with the DKIM checker.
2. Use a custom Return-Path so SPF aligns where it can. Forwarding will still break SPF on the final hop, but on direct (non-forwarded) delivery, an aligned SPF result is a valuable second signal and a fallback if a DKIM signature ever has a problem. The SPF checker and SPF product page cover this.
3. Sign as little, and as stably, as possible for list traffic. If a particular address posts to mailing lists, be aware that lists will modify the message. There is no sender-side fix that makes DKIM survive body edits; this is the case where you rely on ARC at the receiving end and accept that some strict receivers may still fail the message.
4. Read your reports before and after enforcement. Use ongoing monitoring so that when you tighten your policy you can immediately see whether any aligned source started failing, as opposed to the expected background noise of forwarding. Change alerts mean you find out from your dashboard, not from a colleague whose forwarded mail vanished.
5. Do not let forwarding noise keep you at p=none. The whole point of understanding the mechanics above is to separate harmless forwarding failures (DKIM passed, DMARC passed) from real ones. Once you have, the harmless ones are not a reason to stay unprotected. Move through none to reject deliberately.

The practical takeaway

Forwarding breaks SPF almost every time, because SPF is tied to the connecting IP and a forwarder connects from its own address. Forwarding usually preserves DKIM, because DKIM is a signature that travels inside the message, which is exactly why DKIM is the mechanism that actually carries your authentication across hops. DMARC survives forwarding because it needs only one aligned pass, and DKIM normally provides it. The one place this breaks down is editing intermediaries like mailing lists, which damage the body and so break DKIM too; ARC exists to let trusted forwarders vouch for the original result and rescue delivery at receivers that honour it, with no action required from you as the sender.

If you take one thing away: make DKIM aligned and bulletproof on every stream, then read your reports to tell harmless forwarding apart from real failures. That is the whole game.

To see what survives forwarding for your own domain, start with the DMARC checker and the DKIM checker, feed your aggregate reports through the DMARC report analyzer, and browse the full set of free tools. If you would rather not work through the alignment, signing and reporting by hand, our done-for-you service takes your domain from p=none to p=reject with monitoring and change alerts, so forwarding failures get triaged for you and your real mail keeps flowing.