KoltrixWhy DMARC breaks mailing lists, and how ARC helps
Forwarders and mailing lists modify messages and break SPF and DKIM. Understand the failure, From rewriting, and what ARC chains do and do not fix.
On this page(7 sections)
DMARC works beautifully for mail that goes straight from sender to recipient. It works much less well for mail that takes a detour through a forwarder or a mailing list.
Understanding why tells you which failures in your reports are worth worrying about.
Direct mail versus indirect mail
In a direct flow, your server connects to the recipient's server and hands over the message. SPF checks your server's IP against your record. DKIM checks your signature over the message as you sent it. Both align with your From domain. DMARC passes.
In an indirect flow, an intermediary receives the message and sends it on:
- Forwarding: a user at one provider forwards all mail to an address at another.
- Mailing lists: a list server receives a post and redistributes it to every subscriber.
- Alias services: a university or professional association address that redirects to a personal mailbox.
The intermediary changes the connection, and often the message, in ways that break the original authentication.
What breaks and why
SPF breaks almost always
The final receiver sees a connection from the intermediary's IP, which is not in your SPF record. Unless the intermediary rewrites the envelope sender to its own domain (a technique called SRS, Sender Rewriting Scheme), SPF fails. If it does rewrite, SPF passes for the intermediary's domain, which does not align with yours. Either way, SPF stops contributing to DMARC.
DKIM breaks when the message is modified
Plain forwarding usually leaves the message intact, so your DKIM signature survives and DMARC passes on DKIM alone. That is the main reason DKIM matters so much: it is the mechanism that survives forwarding.
Mailing lists are different. Common list behaviors that break DKIM signatures:
- Adding a tag to the Subject, such as
[project-dev]. - Appending a footer with unsubscribe instructions.
- Converting or stripping MIME parts and attachments.
- Changing headers that you signed.
Once DKIM breaks, the message has no aligned pass, and DMARC fails. If your policy is p=reject, receivers that honor it reject the list's copy, and list subscribers stop seeing your posts. Some list software then disables subscribers whose servers bounced the message, which is how one domain's DMARC policy can unsubscribe people from lists.
How mailing lists adapted
Most list software now handles DMARC in one of these ways:
- From rewriting. The list replaces the From header with its own address, such as
Alex via project-dev <[email protected]>, and puts the original author in Reply-To. The list then signs with its own domain, so DMARC evaluates against the list's domain and passes. - Not modifying messages. Some lists stop adding subject tags and footers so the original DKIM signature survives.
- Wrapping. Rarely, the original is attached inside a new message from the list.
From rewriting is the most common approach. It is not elegant, but it works.
Where ARC fits
ARC, Authenticated Received Chain, is defined in RFC 8617 as an Experimental protocol. It lets each intermediary record what authentication results it saw when the message arrived, and seal that record with its own signature.
An ARC set consists of three headers added by each intermediary:
- ARC-Authentication-Results: the SPF, DKIM and DMARC results the intermediary observed.
- ARC-Message-Signature: a DKIM-like signature over the message as the intermediary forwards it.
- ARC-Seal: a signature over the ARC headers so far, chaining them together.
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.example.org; s=arc1; h=from:to:subject; bh=...; b=...
ARC-Authentication-Results: i=1; lists.example.org; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=passThe final receiver can verify the chain and see that, when the message reached the list, it passed DMARC for your domain. If the receiver trusts that intermediary, it may choose to override a DMARC failure and deliver the message.
What ARC does not do
ARC is often misunderstood as a fix for forwarding. It is better understood as evidence:
- It does not make DMARC pass. The DMARC result is still fail. ARC gives the receiver information to make a local exception.
- It depends on trust. Anyone can add ARC headers. Receivers only act on chains from intermediaries they trust, and those trust decisions are internal to each receiver.
- Senders cannot add it to help themselves. ARC is added by intermediaries, not by the original sender.
What this means for your DMARC rollout
When reading aggregate reports, expect a background of failures from indirect flows:
| Report pattern | Likely cause |
|---|---|
| SPF fail, DKIM aligned pass | Plain forwarding; healthy |
| SPF fail, DKIM fail, source is a known list or university mail host | List or forwarder modified the message |
| SPF fail, DKIM fail, small counts from many big mailbox providers | User-configured forwarding plus modification |
These failures do not mean your setup is broken, and you cannot fix them by changing your DNS. What you can do:
- Sign every message with aligned DKIM. It is the mechanism that survives plain forwarding.
- Use relaxed body canonicalization so minor whitespace changes do not break signatures.
- Avoid fragile signing choices, such as signing headers that lists routinely change, beyond what security requires.
- Accept some loss at
p=reject. Most organizations that reach enforcement decide the protection against spoofing outweighs occasional list failures, especially now that list software widely rewrites From.
How to tell forwarding apart from spoofing
When a failing row appears in your reports, a few quick checks separate the harmless indirect flows from genuine abuse. Look up the source IP's PTR record and owner: a major mailbox provider, a university or a well-known list host points to forwarding. Check whether DKIM passed for your domain even though SPF failed, which strongly suggests an intact forwarded message. Compare volumes over time; forwarding produces small, steady counts that track your own sending, while spoofing tends to arrive in bursts unrelated to anything you sent.
Bottom line
Forwarders break SPF, and mailing lists that modify messages break DKIM, leaving DMARC without an aligned pass. Aligned DKIM keeps plain forwarding working, From rewriting keeps most mailing lists working, and ARC gives receivers evidence to make exceptions for trusted intermediaries. Treat the remaining indirect-flow failures in your reports as expected background, not as a configuration error.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
