Forwarding and mailing lists

When a message is passed on by a forwarder or a mailing list, the server delivering it to you is no longer the one the original sender authorized, so SPF fails. If the forwarder changes the message (a subject tag, a footer), the original DKIM signature fails too. With both gone, DMARC fails for the original sender's domain even though the message is perfectly legitimate. Intermediaries work around this by rewriting the envelope sender (SRS), rewriting the From line, or adding an ARC chain. Each leaves recognizable traces in the headers.

RFC 7960 is the IETF's survey of these "indirect mail flow" problems; the sections cited below are worth reading if you run a list or a forwarding service.

Case 1: plain forwarding

Example: mail to alex@alumni.example.org is forwarded automatically to alex@example.net.

SPF. The forwarder connects to example.net from its own IP address. If it keeps the original envelope sender, example.net checks the original domain's SPF record, finds the forwarder is not listed, and gets fail or softfail. RFC 7208 §10.3 describes exactly this. RFC 5321 §3.9 notes that a simple alias keeps the envelope sender as it was.

DKIM. A forward that does not touch the message leaves the signature intact, so DKIM still passes.

DMARC. Because DKIM survived and is aligned, DMARC passes. This is why DMARC needs only one aligned pass (see DMARC alignment).

What you see:

Authentication-Results: mx.example.net;
 spf=softfail (domain of sender@example.com does not designate 198.51.100.40 as permitted sender) smtp.mailfrom=example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com
Received: from relay.alumni.example.org (relay.alumni.example.org [198.51.100.40]) by mx.example.net ...

An SPF failure next to a DKIM pass, with the last hop being a forwarding service you recognize, is normal. If the sender signs without alignment, or does not sign at all, DMARC will fail here instead.

SRS: rewriting the envelope sender

Many forwarders avoid the SPF failure by rewriting the envelope sender into their own domain before passing the message on, which RFC 7208 Appendix D.2 describes as a mediator option. The common scheme is SRS (Sender Rewriting Scheme). It is not an IETF standard, but it is widely implemented. SRS packs the original address, a timestamp and a short hash into the new local part so that bounces can be routed back to the original sender:

Return-Path: <SRS0=Hq3t=VE=example.com=sender@alumni.example.org>
Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=alumni.example.org;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

SPF now passes, but for alumni.example.org, which does not align with example.com (RFC 7960 §2.2). DKIM is still what carries DMARC. A Return-Path starting SRS0= or SRS1= is a reliable sign that the message was forwarded.

Case 2: mailing lists

A mailing list receives a post and sends a new copy to every subscriber. RFC 5321 §3.9 requires a list to change the envelope sender to its own administrative or bounce address, so SPF is checked against the list's domain and usually passes, but for the list, not for the author.

Lists also commonly change the message itself (RFC 7960 §3.2.3):

• adding a tag to the subject, like [garden-club];
• appending a footer with unsubscribe instructions;
• stripping attachments or HTML, or converting to plain text;
• adding or rewriting headers.

Any of those breaks the author's DKIM signature: a subject tag invalidates the header signature if Subject was signed (it nearly always is), and a footer changes the body hash. Now nothing aligned passes:

Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=lists.example.org;
 dkim=fail (body hash did not verify) header.d=example.com;
 dkim=pass header.d=lists.example.org;
 dmarc=fail (p=REJECT) header.from=example.com
List-Id: Garden Club <garden-club.lists.example.org>

If example.com publishes p=reject, receivers that enforce it would bounce the post for every subscriber. RFC 7960 §3.2.3.1 notes the knock-on effect: those bounces can get subscribers automatically removed from the list.

Fix 1: the list rewrites the From line

The most common mitigation (RFC 7960 §4.1.3.3) is for the list to put its own address in From: and keep the author's name in the display name, often with the author's address moved to Reply-To or to an Original-From/X-Original-From header (RFC 7960 §4.1.3.1 notes that no standard says how clients should treat those):

From: "Sam Rivera via Garden Club" <garden-club@lists.example.org>
Reply-To: Sam Rivera <sam.rivera@example.com>
X-Original-From: Sam Rivera <sam.rivera@example.com>

Now the list's own SPF and DKIM align with the From domain, and DMARC passes, for the list. The cost is that the visible sender is no longer the author, and replying needs care. Some list software only rewrites when the author's domain has a quarantine or reject policy.

This is also where the "via" wording in some clients comes from. Gmail, for example, shows "via" and another domain next to a sender's name when the sending domain differs from the From domain, and shows posts to Google Groups from domains with a quarantine or reject policy as "Sender Name via Group-Name" (Gmail Help).

Watch out: Because the list's name sits in the display name, "Sam Rivera via Garden Club" looks like a display-name trick, and the Reply-To differs from From. For list mail both are expected. Check the List-Id header and the list domain.

Fix 2: ARC

ARC lets the list record what authentication looked like when the post arrived, and sign that record (RFC 8617 §7.1.3):

ARC-Authentication-Results: i=1; lists.example.org;
 dkim=pass header.d=example.com; dmarc=pass header.from=example.com
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; b=...

The subscriber's provider may then accept the message despite the DMARC failure, if it trusts the list as a sealer. DMARC allows receivers this kind of local override (RFC 9989 §5.4). Whether a given provider trusts a given list is not something you can see from outside. Details in ARC explained.

Quick reference: what the headers tell you

Paste the headers into the analyser to see the forwarding hop in the Received chain, each authentication result explained, and any ARC sets laid out by instance.