ARC: Solving the DMARC Problem with Email Forwarding

The Forwarding Problem

Email authentication was designed for direct delivery (sender → recipient). Forwarding introduces intermediaries that break the model:

DIRECT (works fine):
You → Recipient's server
SPF: checks your IP → PASS ✓
DKIM: verifies your signature → PASS ✓
DMARC: aligned → PASS ✓

FORWARDED (breaks):
You → Recipient's server → Forwarded to another server
SPF: checks forwarding server's IP → FAIL ✗ (not in your SPF)
DKIM: may fail if body modified → FAIL ✗ (if mailing list added footer)
DMARC: neither passes with alignment → FAIL ✗

How ARC Solves It

ARC creates a chain of authentication checkpoints:

1. You send email. SPF PASS, DKIM PASS, DMARC PASS.

2. Mailing list receives it. Records:
   ARC-Authentication-Results: spf=pass, dkim=pass, dmarc=pass
   ARC-Seal: (signed by mailing list)
   ARC-Message-Signature: (signature of current message state)

3. Mailing list adds footer (modifies body) and forwards.
   SPF: FAIL (mailing list IP, not yours)
   DKIM: FAIL (body was modified)

4. Recipient's server receives it:
   - SPF FAIL, DKIM FAIL → normally DMARC FAIL
   - But ARC chain shows: original SPF PASS, DKIM PASS
   - ARC seal is valid (trusted intermediary)
   - Decision: trust ARC → treat as authenticated ✓

ARC Headers

ARC adds three headers at each hop:

ARC-Authentication-Results: The authentication results as seen by this intermediary.

ARC-Authentication-Results: i=1; mx.google.com;
  spf=pass; dkim=pass; dmarc=pass

ARC-Seal: A signature by the intermediary, vouching for the ARC chain.

ARC-Seal: i=1; a=rsa-sha256; d=google.com; s=arc-20160816; ...

ARC-Message-Signature: A DKIM-like signature of the message at this point in the chain.

ARC-Message-Signature: i=1; a=rsa-sha256; d=google.com; ...

The i= value increments at each hop (i=1, i=2, etc.), creating the chain.

Who Supports ARC

Sealers (intermediaries that add ARC):

• Gmail/Google (Google Groups, Gmail forwarding)
• Microsoft 365 (forwarding rules)
• Mailman (mailing list software)
• Many major forwarding services

Evaluators (receiving servers that read ARC):

• Gmail
• Microsoft 365/Outlook
• Yahoo
• Many major email providers

What you need to do as a sender: Nothing specific. Ensure DKIM is configured (it's the most likely to survive forwarding intact). ARC is handled by intermediaries and evaluators.

Practical Impact

For most senders, forwarding is a small percentage of total email. Focus your energy on:

1. DKIM configuration (survives forwarding better than SPF)
2. DMARC with relaxed alignment (allows subdomain matching)
3. Direct delivery optimization (the 95%+ of your email that isn't forwarded)

ARC handles the edge cases where forwarding breaks authentication. It's a background protocol that improves the ecosystem — not something you actively manage.

When ARC Matters More

• Mailing list operators: If you run a mailing list, configure ARC sealing on your list server (Mailman 3+ supports ARC).
• Email forwarding services: If you provide forwarding, seal with ARC.
• University/organization email: Many institutions forward email. ARC preserves authentication through forwarding chains.

Practitioner note: ARC is the "it just works" protocol. You don't configure it on your sending side. Gmail and Microsoft handle it automatically on forwarded mail. The practical advice: make sure DKIM is rock-solid (it's the authentication most likely to survive forwarding), and don't worry about ARC unless you run mailing lists.

Practitioner note: If DMARC reports show legitimate forwarded email failing, ARC is the reason it's not causing worse problems. The failures appear in reports (because SPF/DKIM technically failed) but Gmail/Microsoft evaluate ARC and often deliver anyway. Don't panic about forwarding failures in DMARC reports if the email is actually being delivered.

If you need authentication designed to handle forwarding scenarios, schedule a consultation.

Sources

• RFC 8617: Authenticated Received Chain (ARC)
• Google: ARC Support

---

v1.0 · March 2026