DKIM, Mailing Lists, and Forwarding: Why Signatures Break and How ARC Tries to Help

A correctly signed DKIM email can still fail DKIM verification at the recipient — and the most common reason is something the original sender often has no control over: mailing lists and forwarding

DKIM (DomainKeys Identified Mail) works by having the sending domain cryptographically sign parts of an email, with the signature verifiable against a public key published in DNS. This is robust against many forms of tampering — but certain legitimate, common email handling patterns (mailing lists, forwarding, and certain types of "send on behalf of" scenarios) can break DKIM signatures in ways that are well understood but still cause real deliverability problems, and ARC (Authenticated Received Chain) was developed specifically to address this.

Why mailing lists break DKIM

A mailing list (e.g., a discussion list where members' emails get redistributed to all subscribers) typically does one or more of the following to messages it processes:

• Adds a footer (e.g., "to unsubscribe, click here")
• Modifies the subject line (e.g., prepending [listname])
• Sometimes modifies the "From" address or other headers

DKIM signatures cover specific headers and the message body (the exact scope is defined in the DKIM signature itself, via the h= tag for headers and a hash of the body). If a mailing list modifies the body (adding a footer) or modifies a signed header (like the Subject line), the DKIM signature — which was computed over the original content — no longer matches the modified content that recipients receive. The signature verification fails, even though the original sender's signature was perfectly valid for what they actually sent.

This is "breaking DKIM" in a technical sense, but it's not necessarily a security problem — it's an inherent consequence of legitimate mailing list operation, where a message is genuinely modified in transit by an intermediary that recipients have chosen to subscribe to. The challenge is how recipient mail systems should treat this.

ARC: preserving authentication results through intermediaries

Authenticated Received Chain (ARC) was developed to address exactly this scenario. The core idea: when an intermediary (like a mailing list server) receives a message, it can:

1. Record what the authentication results were when it received the message (i.e., "when this message arrived here, SPF/DKIM/DMARC passed for the original sending domain")
2. Add its own ARC signature to the message, cryptographically signing this record of authentication results, along with an indication that this intermediary is "vouching" for having seen valid authentication
3. Pass this ARC information along with the (possibly modified) message to the next hop

The result: when the message arrives at its final destination (e.g., a list subscriber's inbox provider), even though the original DKIM signature may no longer verify (due to the mailing list's modifications), the receiving system can look at the ARC chain and see "this message's authentication did pass at the point it was received by [mailing list domain], which itself has a reputation/relationship that this receiving system can evaluate."

ARC doesn't replace DKIM/SPF/DMARC — it's an additional mechanism that sits alongside them, specifically providing a way for intermediaries to pass along a record of "authentication passed here" through a chain of hops, for receiving systems that choose to consider this information.

What an ARC header set looks like

ARC adds three related headers to a message, as a set (added together by each ARC-participating intermediary):

• ARC-Authentication-Results: records the authentication results (similar in concept to the standard Authentication-Results header) as seen by this intermediary
• ARC-Message-Signature: a DKIM-style signature over (parts of) the message, signed by this intermediary
• ARC-Seal: a signature over the ARC headers themselves (including any prior ARC header sets from earlier intermediaries), creating a "chain" — each hop's seal covers the previous hops' ARC information, allowing the chain to be validated as a sequence

A message that's passed through multiple ARC-participating intermediaries (e.g., forwarded multiple times) can accumulate multiple ARC header sets, each with an instance number, forming the "chain."

Whether ARC actually helps depends on the receiving system

ARC is a relatively newer mechanism compared to SPF/DKIM/DMARC, and its adoption and the degree to which receiving mail systems actually use ARC information in their filtering decisions varies. Some major mail providers have implemented ARC support and may use it as one signal among many when evaluating messages that have failed standard DKIM/SPF alignment due to intermediary modification — but ARC isn't a guarantee that a message which fails standard authentication will be treated favourably; it's additional information that a receiving system may incorporate into its overall evaluation, which also includes many other signals.

Forwarding: a related but distinct issue

Simple email forwarding (e.g., an individual's "forward all mail from this address to that address" rule, or a company alias that forwards to an employee's actual mailbox) can also affect DKIM and SPF results, though the specifics differ from mailing list modification:

If the forwarding doesn't modify the message (pure forwarding, no added footers or header changes): the original DKIM signature can remain valid, since DKIM signs content, not the "path" the message took — DKIM verification doesn't inherently care which server relayed the message, only whether the signed content matches.

SPF, however, is more directly affected by forwarding: SPF works by checking whether the sending IP (the server that connected to deliver the message) is authorised for the envelope sender domain. When a message is forwarded, the forwarding server becomes the "sending IP" for the next hop — but the envelope sender domain may still be the original sender's domain, which didn't authorise the forwarding server's IP in its SPF record. This is a well-known reason SPF can "fail" after forwarding, even though DKIM (if the message wasn't modified) might still pass.

DMARC alignment and DKIM's relative robustness to forwarding is part of why DMARC's "relaxed" alignment and its reliance on either SPF or DKIM passing (with correct alignment) provides some resilience — if forwarding breaks SPF but DKIM still passes (because the message content wasn't modified and the original signature remains valid), DMARC can still pass based on the DKIM result alone.

Practical implications for domain owners

You can't fully control how recipients' mail systems handle messages that pass through mailing lists or forwarding — but understanding these mechanisms helps with:

Debugging "why did this specific message fail DKIM" reports: if you're investigating a DMARC report (covered in a previous article) showing DKIM failures for messages that you're confident were correctly signed when sent, checking whether those messages went through a mailing list or forwarding service is a reasonable diagnostic step — the failure may be a known consequence of that intermediary's processing, not an indication of a problem with your own DKIM setup.

Not over-reacting to isolated DKIM failures in DMARC reports: a small number of DKIM failures, particularly from sources that look like they could be mailing lists or forwarding services (sometimes identifiable from the reporting IP or other report details), may simply reflect this known category of issue, rather than indicating a configuration problem with your own domain's DKIM setup that needs fixing.

How to use the DKIM Checker on sadiqbd.com

1. Verify your domain's DKIM record is correctly published — the foundational check, independent of any downstream mailing-list/forwarding considerations
2. Use alongside DMARC report analysis — if DMARC reports show DKIM failures from specific sources, the DKIM Checker confirms your own record is fine, helping isolate whether failures are due to your configuration or to intermediary processing (mailing lists, forwarding) at the reporting source
3. Check after any DKIM key rotation — ensure the new key is correctly published and matches what your mail server is signing with

Frequently Asked Questions

Should I try to prevent my emails from being forwarded or distributed via mailing lists, to avoid DKIM issues? Generally no — forwarding and mailing list distribution are normal, legitimate parts of how email is used, and recipients' choices to forward or subscribe to lists aren't something senders typically have or should have control over. The DKIM/ARC/DMARC ecosystem is designed to accommodate these legitimate patterns as much as possible, even if not perfectly — focusing on correctly configuring your own domain's authentication remains the right priority, rather than trying to prevent normal email usage patterns.

Does ARC require any setup on my part as a domain owner sending email? ARC is primarily implemented by intermediaries (mailing list software, forwarding services, some corporate email gateways) — as a domain owner sending email, you generally don't need to configure anything specifically for ARC; it's the receiving/relaying systems that add ARC headers. Your focus remains on correctly configuring SPF, DKIM, and DMARC for your own domain.

Is the DKIM Checker free? Yes — completely free, no sign-up required.

Try the DKIM Checker free at sadiqbd.com — verify your domain's DKIM record configuration and signing key in DNS.