Why Forwarded Email Fails DMARC (and the Fix)

24 June 2026 · DMARC Engine · 7 min read

Forwarded email fails DMARC mainly because forwarding breaks SPF: when a server relays your message, the connecting IP is the forwarder's, not yours, so the receiving mailbox sees an IP that isn't in your SPF record. The good news is that DKIM usually survives forwarding intact, and because DMARC passes when either SPF or DKIM passes with alignment, well-signed mail keeps passing DMARC even when forwarded. This article explains exactly where forwarding breaks authentication, where ARC and mailing lists come in, and why you can still move safely to p=reject once DKIM is solid.

The short answer

DMARC passes if at least one of the following is true:

SPF passes and is aligned: the IP that connected is authorised in your SPF record, and the MAIL FROM (envelope) domain matches the From: header domain.
DKIM passes and is aligned: a DKIM-Signature validates against your published public key, and the signing d= domain matches the From: header domain.

Plain forwarding (a redirect rule, an alias, a "send a copy to" forward) almost always breaks SPF because the message arrives from the forwarder's mail server, not yours. It usually does not break DKIM, because the signature is carried inside the message headers and body, which the forwarder relays unchanged. So a message that is properly DKIM-signed by your sending domain will still satisfy DMARC after forwarding: SPF fails, DKIM passes, DMARC passes. The fix for "forwarded mail fails DMARC" is therefore almost always: sign with DKIM and align it to your From: domain.

Why forwarding breaks SPF (the mechanism)

SPF (RFC 7208) authorises the sending IP for a given envelope domain (the MAIL FROM, also called the Return-Path or bounce address). The receiving server compares the connecting IP against the SPF record of that envelope domain.

When mail is forwarded:

Your server sends to the forwarding address. SPF passes at that first hop.
The forwarder accepts the message and re-transmits it to the final mailbox, now connecting from the forwarder's IP.
The final mailbox checks SPF. The forwarder's IP is not in your SPF record, so SPF fails (or returns a softfail with ~all).

Crucially, even if SPF technically passed because the forwarder rewrote the envelope to its own domain (a technique called SRS, Sender Rewriting Scheme), that pass would be unaligned: the envelope domain is now the forwarder's, not your From: domain. DMARC needs alignment, so an SPF pass on a rewritten envelope does nothing for DMARC. This is why SPF alone cannot survive forwarding.

Why DKIM usually survives forwarding

DKIM (RFC 6376) signs the message itself (selected headers and the body) and publishes the public key in DNS under a selector (e.g. selector1._domainkey.yourdomain.com). Because the signature travels inside the message, a forwarder that relays the content untouched preserves the signature, and the receiver can still verify it. DKIM also aligns naturally: the signing domain (d=) is your domain, which matches your From: header.

DKIM does break in two situations:

The message body is modified in transit. Footers, "scanned by antivirus" banners, link rewriting, or charset/encoding changes alter the body hash and invalidate the signature. The c= canonicalisation choice matters here: relaxed/relaxed tolerates whitespace and header-folding changes; simple/simple is far more fragile.
A signed header is changed or a Subject: is prefixed (e.g. [EXTERNAL] or a list tag), if that header was covered by the signature.

So plain redirect-style forwarding keeps DKIM intact; content-modifying intermediaries (mailing lists, some security gateways) can break it.

Mailing lists are the hard case

Discussion lists (Mailman, Google Groups, Listserv) are the classic DMARC breaker because they routinely:

add a [ListName] subject tag,
append a footer with unsubscribe links,
and re-send from the list server's IP.

That combination breaks both SPF (new IP) and DKIM (modified subject/body). The list keeps your From: header, so DMARC at the recipient fails. If your policy is p=reject, the recipient rejects mail that legitimately passed through the list.

Two things mitigate this:

ARC (Authenticated Received Chain). A list that supports ARC seals the authentication results it observed before it modified the message. A downstream receiver that trusts the list's ARC seal can honour the original DKIM/SPF result and deliver the message even though local checks now fail. ARC is increasingly supported by large mailbox providers but is not universal, so you cannot rely on it alone.
List From: rewriting. Many lists, when they detect a strict DMARC policy, rewrite the From: to the list's own address (e.g. Jane via List <list@example.org>). This sidesteps DMARC entirely because the From: is no longer your domain. It is not elegant, but it is the most reliable way lists cope with p=reject.

The practical takeaway: mailing-list breakage is a property of the list, not a flaw in your DMARC. Your job is to make sure your own direct and forwarded mail passes, and to let aggregate reports tell you which list sources to investigate.

Step-by-step: diagnose and fix forwarding failures

Confirm DKIM is signing and aligned. Send a test message to a mailbox you control and inspect the headers (Authentication-Results). You want to see dkim=pass with a header.d= that equals your From: domain. If DKIM is missing or unaligned, that is your root cause; see set up DKIM for my domain.
Read your DMARC aggregate reports. Forwarding shows up as a source IP you don't recognise (the forwarder) with spf=fail but dkim=pass. If dkim=pass, DMARC is passing and there is nothing to fix. Our guide on how to read a DMARC aggregate report walks through the XML.
Separate "forwarded but passing" from "forwarded and failing." Only the rows where both SPF and DKIM fail and the From: is yours are real problems. Those are usually mailing lists or content-modifying gateways.
For each failing source, identify the intermediary. A reverse-lookup of the IP usually reveals the forwarder or list provider. Decide whether it is legitimate (your own alias, a partner relay) or unwanted.
Make legitimate intermediaries DKIM-safe. Where you control the gateway, prefer relaxed/relaxed canonicalisation, avoid body-modifying features for signed mail, and enable ARC if available.
Leave mailing lists to handle themselves. Confirm the list rewrites From: or seals with ARC. If it does neither and breaks at p=reject, that is a list-configuration issue to raise with the list owner, not a reason to weaken your policy.

Worked example

Suppose acme.co publishes:

v=spf1 include:_spf.google.com ~all

and DKIM with selector google so messages carry d=acme.co. The DMARC record is:

v=DMARC1; p=reject; rua=mailto:reports@acme.co; adkim=r; aspf=r;

Jane at acme.co emails Bob, who forwards everything to his personal Gmail. At Gmail:

SPF: the connecting IP is Bob's forwarding server, not Google's outbound range for acme.co. spf=fail.
DKIM: Bob's forward relays the message untouched. The google._domainkey.acme.co key still validates. dkim=pass, header.d=acme.co, aligned.
DMARC: passes on the strength of DKIM. Gmail delivers normally, even at p=reject.

Now Jane posts to a Mailman list that adds a [acme-users] subject tag and a footer:

SPF: fails (list server IP).
DKIM: fails (subject and body changed).
DMARC: fails. If the list rewrites From: to acme-users@list.example.org or seals with ARC, the message still delivers; otherwise it is rejected, correctly, because nothing now authenticates it as acme.co.

This is exactly the picture you want: ordinary forwarding rides through on DKIM, and only true content-modifiers need handling.

Verify it before and after enforcement

Run your domain through the DMARC checker to confirm your policy and reporting addresses are valid.
Confirm SPF is within the 10 DNS-lookup limit and isn't returning a permerror with the SPF checker; a broken SPF record makes forwarding problems harder to diagnose.
Send test mail through each path (direct, alias forward, list) and read the Authentication-Results header. DKIM pass with alignment on the forwarded copy is your green light.
Watch a few weeks of aggregate reports at p=none before tightening, so you can see every forwarder. See is it safe to move to p=reject.

Why p=reject is still safe

p=reject only rejects mail that fails DMARC, i.e. mail where neither SPF nor DKIM aligns. Because well-signed DKIM survives ordinary forwarding, the overwhelming majority of forwarded legitimate mail keeps passing. The narrow exception is content-modifying intermediaries, and those are handled by ARC or From: rewriting at the intermediary, not by loosening your policy. Staying at p=none to "protect" forwarded mail leaves your domain spoofable while doing nothing to help the handful of list scenarios that need an intermediary-side fix.

Hosted DMARC from DMARC Engine makes this concrete: we monitor your aggregate reports, flag which sources are forwarders passing on DKIM versus genuine failures, verify DKIM alignment across every sending and forwarding path, and guide you through the enforcement journey to p=reject with no email outage.

Next steps

Verify DKIM is signing and aligned to your From: domain. This is the single most important fix.
Use the DMARC checker and SPF checker to confirm your records are valid and within the SPF lookup limit.
Read your aggregate reports to separate forwarders-that-pass from true failures.
For mailing lists, confirm the list rewrites From: or seals with ARC, then proceed confidently to p=reject.

Why does forwarded email fail DMARC, and what can I do?