Why ARC exists
Before ARC, a legitimate mailing-list post from a DMARC-strict sender (p=reject) would arrive at subscribers stripped of valid auth and get dropped. Mailing-list operators worked around this with header rewriting hacks (changing From: to the list address), which broke conversation threading and lost original-sender attribution.
How ARC works
Each ARC-participating intermediate adds three headers as it forwards: ARC-Authentication-Results (what auth results it saw), ARC-Message-Signature (a DKIM-style signature of the message at this hop), and ARC-Seal (a cryptographic chain back to the previous hop).
The final receiver inspects the chain. If the message arrived with broken SPF/DKIM but the chain is intact and the upstream ARC verdict was clean, the receiver can choose to honour the upstream verdict instead of dropping the message.
ARC is a receiver-side decision
ARC does not override DMARC unilaterally. The receiver decides whether to trust an ARC chain based on its policies — typically by maintaining an allow-list of trusted ARC signers (Gmail, Outlook, well-known mailing-list services).
What this means for senders
You do not need to do anything to participate in ARC as a sender — your job is to sign with DKIM and publish DMARC, both of which you already do. ARC is built and consumed by intermediates and receivers. If your mail goes through a known-trusted ARC chain, your DMARC posture survives intermediate handling.