What Is ARC (Authenticated Received Chain)? Forwarding and SPF

ARC (Authenticated Received Chain) is an email authentication mechanism that lets each server which forwards or relays a message record the SPF, DKIM and DMARC results it observed, then sign that record so the final receiver can trust it. It exists because forwarding and mailing lists routinely break SPF, and sometimes DKIM, causing legitimate mail to fail DMARC at its final destination.

Quick summary

• The first intermediary verifies SPF, DKIM and DMARC on arrival and writes the results into ARC-authentication (proof that email really comes from your company)-Results with instance i=1.
• It signs the message headers with ARC-Message-Signature and seals the whole ARC set with ARC-Seal, using its own DKIM-style key in DNS.
• The next hop verifies the seal, adds its own set as i=2, and so on. cv=pass in the seal means the previous chain validated.
• The final receiver checks the chain. If it trusts the sealing domains and the chain is intact, it can use the original i=1 results instead of its own broken SPF result.
• That trust is at the receiver discretion. Gmail, Outlook and Yahoo honour ARC from known good intermediaries; unknown sealers add little.

Why forwarding breaks SPF

SPF checks whether the IP that delivered a message is authorised by the envelope sender domain. When you send to alice@olddomain.com and her mailbox forwards to alice@gmail.com, Gmail receives the message from the olddomain.com server, but the envelope sender still says yourdomain.com. That IP is not in your SPF record, so SPF fails. DKIM usually survives because the signature covers the content, but a mailing list that adds a footer or rewrites the subject breaks DKIM too. With both broken, DMARC fails and a p=reject policy causes your genuine mail to be dropped.

Example ARC headers on a forwarded message

ARC-Seal: i=1; a=rsa-sha256; t=1783501540; cv=none;
  d=forwarder.example; s=arc-2026; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
  d=forwarder.example; s=arc-2026; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; forwarder.example;
  spf=pass smtp.mailfrom=yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

At Gmail after forwarding:
Authentication-Results: mx.google.com; spf=fail ...; dkim=pass ...; dmarc=pass ...; arc=pass (i=1 spf=pass dkim=pass dmarc=pass)

How ARC works, hop by hop

1. The first intermediary verifies SPF, DKIM and DMARC on arrival and writes the results into ARC-authentication (proof that email really comes from your company)-Results with instance i=1.
2. It signs the message headers with ARC-Message-Signature and seals the whole ARC set with ARC-Seal, using its own DKIM-style key in DNS.
3. The next hop verifies the seal, adds its own set as i=2, and so on. cv=pass in the seal means the previous chain validated.
4. The final receiver checks the chain. If it trusts the sealing domains and the chain is intact, it can use the original i=1 results instead of its own broken SPF result.
5. That trust is at the receiver discretion. Gmail, Outlook and Yahoo honour ARC from known good intermediaries; unknown sealers add little.

The other fix: SRS

• Sender Rewriting Scheme changes the envelope sender to the forwarder domain, for example SRS0=hash=TT=yourdomain.com=you@forwarder.example.
• SPF then passes for the forwarder domain, but it no longer aligns with your From, so DMARC relies on DKIM.
• SRS fixes SPF rejections; ARC preserves the original verdict. Well-run forwarders do both.

What this means for your own domain

• Always sign with DKIM. It is the only identifier that reliably survives a simple forward.
• Do not move to p=reject until DMARC reports show forwarded mail is either DKIM-passing or ARC-sealed by trusted hops.
• If you forward inbound mail from an old address to a new mailbox, expect SPF to fail on the forwarded copy; that is normal and not your DNS problem.
• Mailing lists you post to may rewrite From to the list address for exactly this reason.

ARC and OquMail

Mail you send from OquMail is DKIM-signed for your domain, which keeps DMARC passing through most forwarders even when SPF breaks. On the receiving side, OquMail evaluates SPF, DKIM and DMARC on inbound mail and records the results in authentication (proof that email really comes from your company)-Results, so a forwarded message that fails SPF but passes DKIM is still recognised. Rather than chaining forwarders, give each teammate a real OquMail mailbox and let old addresses forward once, keeping the chain short.

Common questions

Do I need to publish anything for ARC?

No. ARC is done by intermediaries and receivers. As a sender, aligned DKIM is your contribution.

Does ARC replace DMARC?

No. ARC helps receivers make a DMARC decision when the direct checks were broken by an intermediary. DMARC policy still applies.

Why did my forwarded email go to spam even with ARC?

The receiver may not trust the sealing domain, or the forwarder may have modified the body. Check arc= in authentication (proof that email really comes from your company)-Results; cv=fail or an unknown sealer explains it.