← RFC Reference

RFC 6377: DKIM and Mailing Lists

Why This Exists

DKIM (RFC 6376) signs email headers and body content with a cryptographic hash. Any modification after signing invalidates the signature. Mailing lists, by design, modify messages in transit. This creates a fundamental tension:

• DKIM wants messages to arrive exactly as signed.
• Mailing lists add footers, prepend "[list-name]" to subjects, add List-* headers, rewrite From addresses, and wrap messages in digests.

When DMARC entered the picture (requiring DKIM or SPF alignment), this tension became a deliverability crisis. Messages sent to mailing lists by domains with p=reject DMARC policies started bouncing for all list subscribers. RFC 6377 was published to document the problem and recommend mitigation strategies.

How It Works

What Mailing Lists Do to Messages

A typical mailing list manager (Mailman, Sympa, LISTSERV, Google Groups) may perform any combination of:

The Signature Verification Flow

; Step 1: Author sends DKIM-signed message to list
From: alice@example.com
To: dev-list@lists.example.org
Subject: Proposed API change
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Step 2: List software modifies the message
From: alice@example.com            ← unchanged (or rewritten)
To: dev-list@lists.example.org
Subject: [dev] Proposed API change  ← modified: prefix added
List-Id: <dev-list.lists.example.org>  ← added
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Original body + appended footer
The body text here...

--
To unsubscribe, visit https://lists.example.org/unsub  ← added

; Step 3: Recipient's server verifies DKIM
; Result: FAIL (Subject and body were modified after signing)

Recommended Practices for List Operators

RFC 6377 recommends that mailing lists minimize modifications to preserve DKIM signatures:

1. Do not modify the Subject header. Avoid prepending [list-name]. Use the List-Id header instead — mail clients can filter on it.
2. Do not add body footers. Use MIME encapsulation if footer content is required, or add the footer as a separate MIME part rather than appending to the existing body.
3. Add a new DKIM signature. The list should sign the modified message with its own DKIM key (d=lists.example.org). This does not repair the original signature, but it provides a valid signature from the list domain.
4. Consider From-rewriting for DMARC. When the original sender's domain publishes p=reject, rewrite the From header to the list domain and put the original sender in Reply-To. This is widely implemented as "From munging."

Recommended Practices for Senders

1. Use relaxed canonicalization. Sign with c=relaxed/relaxed rather than c=simple/simple. Relaxed canonicalization tolerates minor whitespace changes that some list software introduces.
2. Sign only essential headers. The h= tag should cover headers you care about (From, Subject, Date, To, Message-ID) but not headers that lists commonly add (List-Id, List-Unsubscribe).
3. Use l= body length tag cautiously. The l= tag limits how much of the body is signed, so appended footers don't break the signature. However, this has security implications — an attacker could append malicious content below the signed portion.

Key Technical Details

The DMARC Complication

RFC 6377 predates DMARC (RFC 7489), but the problems it describes became far more severe once DMARC was deployed. With DMARC p=reject:

; Author's domain publishes strict DMARC
_dmarc.example.com TXT "v=DMARC1; p=reject; ..."

; Message goes through mailing list, DKIM breaks
; Recipient's server checks DMARC:
;   - SPF: FAIL (envelope sender is list, not example.com)
;   - DKIM: FAIL (signature broken by list modifications)
;   - DMARC: FAIL → REJECT
; Result: message bounces for all list subscribers

This is why ARC (RFC 8617) was developed — to preserve authentication results across intermediaries like mailing lists.

ARC as the Modern Solution

The Authenticated Received Chain (ARC) protocol lets intermediaries like mailing lists record the original authentication results before modifying the message. The recipient's server can then use the ARC chain to recover the original DKIM/SPF pass, even after the list has broken the original signature.

From-Rewriting Strategies

The most common DMARC mitigation for mailing lists is From-rewriting:

; Original message
From: Alice Smith <alice@strict-dmarc.com>

; After list From-rewriting
From: Alice Smith via Dev List <dev-list@lists.example.org>
Reply-To: Alice Smith <alice@strict-dmarc.com>

This preserves the original sender's identity in the display text and Reply-To while making the From domain match the list's DKIM signature.

Common Mistakes

• Using c=simple/simple canonicalization. Simple canonicalization fails on even trivial whitespace changes. Always use c=relaxed/relaxed if your messages may pass through mailing lists or other intermediaries.
• Signing too many headers. Including headers like List-Id or List-Unsubscribe in the DKIM h= tag guarantees failure when a list adds those headers. Sign only the headers you generate.
• Publishing p=reject DMARC without considering lists. If your users send to mailing lists, a strict DMARC reject policy will cause their list messages to bounce for all subscribers. Consider p=quarantine or ensure your users understand the implications.
• List operators not adding their own DKIM signature. After modifying a message, the list should sign it with its own key. Without this, the message arrives with no valid DKIM signature at all.
• Relying solely on l= body length. While it can preserve signatures past appended footers, l= has been deprecated by many best-practice guides because it allows content injection below the signed boundary.
• Not implementing ARC. Modern list software should implement ARC to preserve the original authentication chain. Without ARC, recipients have no way to know the message was originally authenticated.

Deliverability Impact

• Broken DKIM on list mail causes bounces. With DMARC p=reject, broken DKIM means rejected messages. List subscribers stop receiving mail, and the list operator gets flooded with bounces.
• From-rewriting preserves deliverability but changes sender identity. Recipients see the list address in From, not the original sender. This can confuse users but is the most reliable way to ensure delivery.
• ARC improves delivery for list mail. Major providers (Gmail, Microsoft, Yahoo) honor ARC chains. A valid ARC seal from a reputable list can override a broken original DKIM signature.
• List reputation matters. Receiving servers evaluate the list's domain reputation. A well-maintained list with good sending practices, proper DKIM signing, and ARC implementation will see better delivery rates than a poorly-run list.
• Monitor your bounce rates from list traffic. If you see spikes in bounces for messages sent to mailing lists, check whether the list is modifying messages in ways that break your DKIM signature, and whether they implement ARC.

Related RFCs