Skip to content
Sentura Sentura Sentura

Forwarding & Mailing Lists

When a message is forwarded — by someone’s auto-forward rule, a mailing list, or a third-party gateway — SPF almost always fails, because the forwarding server’s IP isn’t in your SPF record. DKIM usually survives, but mailing lists that modify the message can break it too. This is normal, expected, and one of the main reasons a healthy domain never sees a 100% pass rate in its DMARC reports.

Why forwarding breaks SPF

SPF checks the IP address that actually connected to the receiving server against the list in your SPF record. When mail is forwarded, the forwarder’s server makes that connection — and its IP isn’t in your record, because it’s not one of your senders. So SPF fails. There’s nothing wrong on your end; it’s just how SPF works. A message can be perfectly legitimate, sent by you, and still fail SPF the moment it’s relayed through someone else’s infrastructure.

Why DKIM usually survives

DKIM doesn’t care about the connecting IP — it’s a cryptographic signature attached to the message itself. As long as the forwarder passes the message along unchanged, the signature still validates at the final destination. This is why DKIM is the more durable of the two through forwarding, and why DMARC still passes for most forwarded mail: DMARC passes when either SPF or DKIM aligns, and DKIM typically does.

When DKIM also breaks

The exception is anything that modifies the message in transit. Mailing lists are the classic case: many add a [list-name] prefix to the subject, append a footer with unsubscribe links, or rewrite headers. Any change to the signed content invalidates the DKIM signature — so now both SPF and DKIM fail, and DMARC fails with them. That’s why list traffic is the most common source of legitimate DMARC failures.

Telling breakage from spoofing

In your DMARC aggregate reports, forwarding and list failures look different from real attacks:

  • Legitimate forwarding tends to show up as recognisable infrastructure — forwarding services, university or ISP mail servers, known list platforms — often with DKIM passing but SPF failing (a plain forward), or a familiar source failing both (a modifying list).
  • Spoofing tends to come from unfamiliar IPs you can’t account for, failing both checks, sometimes at volume, with no plausible reason to be sending as you.

The judgement call is whether a failing source is something you can explain. A handful of forwards and a mailing list you know about are expected noise; an unknown bulk sender failing everything is the signal DMARC exists to surface.

The mitigations (mostly not yours to deploy)

Two standards try to soften forwarding failures, but they live on the forwarder’s side, not yours:

  • SRS (Sender Rewriting Scheme) rewrites the envelope sender to the forwarder’s own domain so the SPF check passes at the next hop. The important caveat: that pass is aligned to the forwarder’s domain, not yours — so SRS stops an outright SPF rejection but doesn’t, on its own, make DMARC pass. It’s DKIM surviving the forward that actually gives DMARC its aligned pass.
  • ARC (Authenticated Received Chain) lets a forwarder attach a signed record of the original authentication results, so the final receiver can choose to trust that the message passed before forwarding altered it. Major providers like Gmail and Microsoft evaluate ARC and often deliver anyway — but it’s advisory: the receiver decides whether to honour the chain, and the forwarder has to add it in the first place.

Because you mostly don’t control either of these, the practical takeaway isn’t “fix forwarding” — it’s “expect a small amount of it, make sure your own DKIM is rock-solid (it’s the signal that survives), and don’t let the rest block you.”

Start here