Authenticated Received Chain (ARC) Explained: Forwarded Mail and DMARC

Authenticated Received Chain (ARC) is the standard that helps receivers evaluate mail after intermediaries. If you search for “authenticated received chain explained” or see ARC fail on a forwarded message, this is the concept behind that result.

You publish SPF, DKIM, and DMARC. Legitimate mail from your domain authenticates. Then a customer forwards an invoice to a personal Gmail, or a mailing list rewrites the message, or a security gateway touches the body — and suddenly the final inbox sees a DMARC failure on mail that started honest.

That is not always a misconfigured record. It is often broken authentication after intermediaries. ARC is how receivers can reconstruct trust when hops would otherwise destroy the original authentication story.

The problem in one picture

1. Your server sends mail with valid DKIM and SPF for brand.co.za.
2. An intermediate system forwards or modifies the message.
3. SPF no longer matches the new sending IP.
4. DKIM may fail if the body or critical headers changed.
5. The final receiver evaluates DMARC against what it sees now, not what was true at the first hop.

Without extra information, the final hop has little reason to trust the original authentication result. Forwarded mail becomes a deliverability and false-fail problem — especially painful for lists, helpdesks, and “send a copy to my other address” workflows.

What ARC is

ARC lets intermediate systems seal and forward the authentication results they observed, so a later receiver can consider that chain when making a trust decision.

In practice, ARC introduces header sets such as:

• ARC-Authentication-Results — what the intermediate claimed to see (SPF/DKIM/DMARC-like results at that hop)
• ARC-Message-Signature — a signature over the message state at that hop
• ARC-Seal — a seal binding the ARC sets in order (i=1, i=2, …)

A chain of these sets forms an Authenticated Received Chain. Receivers that implement ARC validation can decide whether to honour prior results when the current hop’s SPF/DKIM look broken.

ARC does not replace DMARC on your domain. It does not fix a missing SPF include for a marketing platform. It addresses a specific class of problem: legitimate multi-hop mail.

What ARC is not

• Not a reason to skip SPF, DKIM, or DMARC
• Not a free pass for spoofers (receivers still validate the chain carefully)
• Not something every small business must “turn on” as a DNS TXT the way DMARC is published
• Not a guarantee that every mailbox provider will treat forwarded mail the same way

Think of ARC as infrastructure behaviour for systems that relay or modify mail — list servers, some gateways, some forwarding services — plus validation logic at modern receivers.

Where you will notice ARC in real life

Mailing lists

Lists often rewrite Subject lines, add footers, or resend from list infrastructure. Classic SPF breaks; DKIM may break. ARC-aware list software can preserve a story the final receiver can evaluate.

Domain forwarding and “catch-all to Gmail”

Forwarders change the SMTP path. Users report “my domain mail fails DMARC when forwarded.” That may be expected without ARC-aware intermediaries and ARC-aware receivers.

Security and compliance gateways

Gateways that alter content for DLP or banners can invalidate body hashes. How the gateway signs and whether it participates in ARC matters for downstream reputation.

Mediated mail paths in large enterprises

Journaling, encryption gateways, and multi-hop relays create similar issues.

What domain owners should do

Most organisations do not start email security with “deploy ARC.” Start with:

1. Correct SPF / DKIM / DMARC for intentional senders
2. Prefer DKIM that survives common paths (aligned signatures from real platforms)
3. Avoid unnecessary body rewrites on brand mail
4. Prefer platforms that document forwarding behaviour and ARC support where relevant

Then, when you debug failures:

• Check whether the failing path is direct or forwarded
• Inspect Authentication-Results and any ARC-* headers on a sample message
• Separate “our SaaS is misconfigured” from “an intermediate broke the seal”

If your product or gateway sends or relays mail for customers, ARC participation is a product quality topic: receivers increasingly expect modern intermediaries to seal correctly.

Reading failures without overreacting

A DMARC fail on a single forwarded sample does not mean your domain should abandon p=reject.

Ask:

• Does direct mail from the same system pass for major receivers?
• Is the failure isolated to list or forward paths?
• Is volume in aggregate reports dominated by the real platform (pass) or by random spoof IPs (fail)?

Enforce against spoofing on the direct path. Treat forwarding edge cases as path design and intermediary capability — not as a reason to leave the domain permanently at p=none.

Practical checks

When a user says “authentication broke”:

1. Collect full headers of the failed message (not a screenshot of the body).
2. Note every Received hop and any ARC-Seal chain.
3. Compare with a direct message from the same From domain to the same receiver class.
4. Confirm DKIM d= and alignment for the originating platform.
5. Only then change DNS.

Many “ARC problems” are still ordinary missing DKIM on the ESP.

How this fits DMARC Shield’s world

Public DNS checkers answer: what did you publish?
Aggregate reports answer: who is sending and did alignment pass at receivers?
ARC answers a third question: did an intermediate preserve a trustworthy authentication history?

All three matter for mature email programmes. Most South African SMEs should prioritise SPF/DKIM hygiene and a real path to DMARC enforcement first. ARC becomes urgent when you operate list software, complex gateways, or multi-hop product mail at scale — or when you are debugging forwarding-specific fails after the basics already pass.

Takeaways

• Forwarding and modification break SPF easily and DKIM sometimes; DMARC at the final hop can fail even when the original send was good.
• ARC seals prior authentication results so capable receivers can evaluate multi-hop mail more fairly.
• Domain owners should still fix direct-path authentication before chasing ARC.
• Use headers and path comparison before relaxing DMARC policy.

For a quick public view of SPF, DKIM, DMARC, and related DNS on your domain, use free tools. For ongoing source-level visibility as you enforce policy, keep aggregate reporting pointed at a monitor someone actually reviews.