A perfectly authenticated invoice can fail DMARC after one forward. SPF evaluates the connecting IP against the envelope domain. When a mailing list, security gateway, or catch-all forwarder becomes the new sender, SPF fails. DKIM may also fail if the intermediary rewrites signed headers or the body. DMARC then has no aligned path and the message can be rejected or quarantined even though the original sender did everything right.
Authenticated Received Chain (ARC, RFC 8617) was designed to preserve authentication evidence across intermediaries. Receivers can still choose to trust or ignore an ARC chain. ARC does not replace SPF, DKIM, or DMARC and does not guarantee inbox placement.
How forwarding breaks SPF and sometimes DKIM
| Check | At origin | After forwarder |
|---|---|---|
| SPF | Pass (aligned) | Fail — new connecting IP is not authorized by the original MAIL FROM domain |
| DKIM | Pass (aligned) | May pass if body and signed headers are untouched; fails if subject, body, or signed headers change |
| DMARC | Pass | Fail if neither SPF nor DKIM remains aligned with the From domain |
SRS (Sender Rewriting Scheme) can repair SPF for the forwarder’s own envelope domain. It does not restore DMARC alignment with the original From domain.
What an ARC set contains
Each ARC hop adds three headers:
- ARC-Authentication-Results — the intermediate’s view of SPF, DKIM, and DMARC results at that hop.
- ARC-Message-Signature — a signature over the message as seen by that intermediary (similar in spirit to DKIM).
- ARC-Seal — a seal that covers the previous ARC headers and prevents undetected tampering with the chain.
A valid ARC chain gives a receiving system additional evidence that earlier authentication results existed. Whether the receiver trusts any particular sealer is an implementation decision. ARC is not a free pass into the inbox.
ARC’s status in 2026
RFC 8617 remains Experimental. In April 2026 the IETF DMARC working group published draft-ietf-dmarc-arc-to-historic-00 (expires 24 October 2026). The draft proposes reclassifying ARC as Historic and discourages new internet-wide deployments. It frames operational experience with ARC as input to ongoing work on DKIM2 rather than a reason to expand ARC further.
At the same time:
- Production forwarders and some mailbox-provider guidance still mention ARC.
- Google’s current sender guidelines continue to tell operators of forwarding services, mailing lists, and inbound gateways to add ARC headers.
- DMARCbis (RFC 9989) and the accompanying reporting RFCs (9990/9991) shipped in May 2026 and do not make ARC mandatory receiver behavior.
These facts can coexist. Operational advice to seal with ARC today does not contradict an active Internet-Draft that proposes ending the experiment. New mail systems should not treat ARC as a long-term architectural dependency.
What ArawaMail does (and does not) with ARC
ArawaMail documents DKIM CNAME records and a custom MAIL FROM when outbound sending is activated. Receiving publishes MX records and supports catch-all mailboxes. When a catch-all mailbox has verified forwarding destinations, messages are forwarded and a local copy is retained; the original envelope recipient is preserved on the stored message.
ArawaMail documentation does not describe ARC sealing, ARC verification, trusted ARC sealers, or an ARC status UI. Do not assume those features exist. Incoming mailbox webhooks notify on received mail; they are not ARC or DMARC report processors.
Related reading:
- SPF, DKIM, and DMARC explained
- How to read a DMARC report
- From, Reply-To, and Return-Path
- Catch-all inboxes
- SPF, DKIM, and DMARC on subdomains
- Two vendors, one From address
Practical takeaways
- Do not weaken your own DMARC policy to
p=nonesolely because forwarded mail fails. Fix the paths you control and educate partners that forward your mail. - When diagnosing failures, inspect both the final
Authentication-Resultsand any ARC headers before assuming spoofing. - For new systems, prefer clean origin authentication, careful handling of mailing lists, and monitoring of DMARC reports over dependence on ARC.
- Watch the IETF draft and any subsequent IESG action. The Historic proposal is still an Internet-Draft and may change before or after its October 2026 expiry.
FAQ
Does a valid ARC chain guarantee DMARC pass?
No. ARC provides evidence for receivers that choose to consider it. It does not force a DMARC pass or guarantee inbox placement.
Is ARC required by Google or Microsoft?
Google’s sender guidelines still recommend that certain forwarding services add ARC headers. That is operational guidance, not a universal requirement, and it coexists with the IETF proposal to reclassify ARC as Historic.
Should I implement ARC sealing on a new platform?
Only if you operate a high-volume forwarder or mailing list and have a clear need. The 2026 IETF direction points lessons toward DKIM2 rather than expanding ARC deployments.
Does ArawaMail add ARC headers when forwarding?
No ARC sealing or verification features are documented. Documented catch-all forwarding retains a local copy and forwards to verified destinations without claiming ARC involvement.
Forwarding will continue to break SPF and sometimes DKIM. ARC remains a useful diagnostic signal for receivers that trust it, but its long-term standards future is uncertain. Design origin authentication carefully and treat ARC as optional evidence, not a foundation.