If you run a mailing list or any kind of forwarder and some of your subscribers quietly stopped receiving mail, DMARC is probably why. This is one of those problems baked into how the standards interact, not a bug you can configure away, and ARC is the patch the industry reached for. It helps less than people expect. Here is the whole picture.
Why lists break DMARC in the first place
DMARC passes when at least one of SPF or DKIM both verifies and aligns with the domain in the visible From header. A mailing list breaks both sides of that.
It resends the message from its own servers, so an SPF check now sees the list’s IP against the author’s SPF record, which fails. Even if it passed, the list’s domain is not the author’s, so it would not align.
And it modifies the message. A subject tag like [list-name], a footer with unsubscribe links, an added List-Id header. Any of that changes bytes the author’s DKIM signature covered, so the signature no longer verifies.
Now the author’s message arrives at the subscriber with SPF failing and DKIM broken. If the author’s domain publishes p=reject, the receiver does exactly what it was told: it rejects the list’s copy, and the subscriber never sees it.
This is not hypothetical. When Yahoo and then AOL flipped their consumer domains to p=reject in 2014, mailing lists worldwide started bouncing their own members, because a Yahoo user posting to a list meant every other member’s server saw a p=reject message that failed DMARC. That is the event that forced this whole conversation.
Option one: rewrite the From (munging)
The blunt, universal fix is to stop pretending the mail is from the author. The list rewrites the From header to something like Anne Person via BigList <biglist@example.org> and drops the real author into Reply-To. Now the From domain is the list’s own domain, the list signs it with its own DKIM, and it aligns. DMARC passes everywhere, because you have made the mail genuinely be from the list.
Working at every receiver is its great virtue. The cost is that you have rewritten the author’s identity. Reply-to-author gets fiddly, some clients show the wrong name, threading tools get confused, and address books fill up with via BigList entries. It is ugly, and it is also the only thing that reliably works.
Option two: ARC
ARC (Authenticated Received Chain, RFC 8617) tries to preserve the author’s identity instead of overwriting it. The idea is that the list, as a trusted intermediary, vouches for what it saw: when the message arrived, it passed DMARC. ARC lets the list record that fact in a tamper-evident way and pass it downstream.
It does this with three header fields, each stamped with an instance number so a chain can build across multiple hops:
ARC-Authentication-Results: the auth results the list observed when it received the message.ARC-Message-Signature: a DKIM-like signature over the message as the list is about to forward it.ARC-Seal: a signature over the ARC headers themselves, chaining to any previous ARC set.
A receiver that trusts the chain can reason: this message fails DMARC now because the list modified it, but the list’s ARC seal says it passed DMARC before the list touched it, and I trust this list, so I will deliver it. The author’s From stays intact.
The catch nobody mentions up front
ARC sounds like it solves the problem. In practice it solves a slice of it, for two reasons.
First, ARC only helps at receivers that actually evaluate it, and plenty do not. If the receiving server ignores ARC, you are back to broken DKIM, failing SPF, and a p=reject, and the mail is rejected.
Second, and this is the part that trips people up: there is no global registry of trusted ARC sealers. A seal is only worth something if the receiver trusts the domain that made it. The big mailbox providers, Gmail and Microsoft, do use ARC, but they build reputation on the sealing domain automatically, the same way they build reputation on any sender. A large, long-running list accrues that trust over time. A small internal list, or one you spun up last week, has no reputation, so its seal buys nothing. ARC is not a switch you flip to get delivery; it is a reputation you earn slowly, and only some receivers are even looking.
There is also a way to make things worse. DKIM lets you oversign a header, listing it in the signature one extra time so that adding another instance breaks the signature. That is a good anti-spoofing move for a header like From. But if you oversign a header a list legitimately adds, such as List-Id, then every message sent through a list breaks its own signature on purpose. Do not oversign the headers that intermediaries are allowed to touch.
What to actually do
Run both, and let them cover for each other.
Turn on ARC sealing so the receivers that honor it, which includes the ones most of your subscribers use, can keep the author’s identity intact. Then keep From-munging as the safety net, but apply it conditionally: only munge when the author’s domain actually publishes p=quarantine or p=reject. Mailman 3 does exactly this with dmarc_mitigate_action = munge_from and dmarc_mitigate_unconditionally left off, so authors on lenient domains keep their clean From and only the strict ones get rewritten.
The uncomfortable truth is that DMARC and intermediaries are in a fundamental tension. DMARC is a promise that mail from a domain will not be modified in transit, and a mailing list’s entire job is to modify mail in transit. ARC is a good-faith patch over that contradiction, and a genuinely useful one at the receivers that implement it. It is just not the complete fix it is often sold as. From-munging is the thing that always works, and the honest setup is to run the elegant option and the reliable option side by side.