What Is ARC and Why Email Still Fails Even When SPF, DKIM, and DMARC Pass

Most business owners feel relief once SPF, DKIM, and DMARC are set up correctly — and for good reason. Those three records make up the foundation of modern email authentication. But many people discover something confusing after everything is “green” on paper:

🔴 Forwarded emails still go to spam.

🔴 Gmail still shows warning banners.

🔴 Authentication still “fails” even though everything is configured correctly.

That’s where ARC comes in.

ARC stands for Authenticated Received Chain, and it solves one of the most frustrating and misunderstood problems in email: authentication breaking when mail passes through intermediaries like forwarding systems, spam filters, security gateways, or shared mailboxes.

Let’s break down what ARC really does, why it matters, and how it ties into the deliverability work we do at Stonegate Security.

The Problem ARC Was Built to Solve

Email isn’t always a straight line from sender to recipient. Messages often pass through:

Forwarding rules (info@ → [email protected])
Security gateways (Proofpoint, Mimecast, Barracuda, etc.)
Spam filters
Shared mailboxes
Ticketing systems
List servers

Any one of these “middle layers” can change the message enough to break SPF or DKIM, even when the domain is configured perfectly.

For example:

You send an email from Outlook using your custom domain

↓

Microsoft 365 signs and authenticates the message correctly

↓

Proofpoint receives and scans the message

↓

Proofpoint modifies or forwards the message to the next hop

↓

Message now appears to come from Proofpoint instead of Microsoft 365

↓

SPF fails at the receiving mailbox

↓

Email lands in spam or receives a warning banner

This leads to the classic frustration: “But my SPF and DKIM are correct — why is this still failing?”

ARC exists for this exact scenario.

What ARC Actually Does

ARC is a way for intermediaries to “seal” the authentication results they observed when they first received the message. This creates a chain of trust from hop to hop.

ARC does this with three components:

1. ARC-Authentication-Results

A copy of the authentication results before forwarding or filtering broke anything.

2. ARC-Message-Signature

A signature of the message as the intermediary saw it.

3. ARC-Seal

A cryptographic seal confirming the intermediary vouches for the previous two pieces.

Together, these tell the final recipient:

“We know SPF and DKIM may not pass now, but here’s proof they DID pass before we forwarded the message.”

That’s why ARC is so important for businesses using forwarding, help desks, distribution lists, or security gateways.

The Most Common Misunderstanding About ARC

A lot of people — including IT providers — think ARC fails if DKIM is removed or modified by an intermediary.

But that’s not how ARC works.

ARC does not require the original DKIM-Signature header to remain untouched. It doesn’t break when forwarding strips or changes DKIM. It doesn’t depend on the original DKIM at all.

ARC signs the authentication results, not the DKIM header.

This is intentional. If ARC broke the moment DKIM changed, ARC would be useless — because forwarding regularly breaks or removes DKIM.

Why ARC Matters for Real Businesses

ARC improves deliverability in situations like:

Microsoft 365 → Proofpoint → Gmail recipients
Outlook forwarding rules
Contact forms sending to external mailboxes
Shared mailboxes forwarding to personal inboxes
Systems that rewrite or re-sign mail
Ticketing/helpdesk systems that receive and re-send messages

If your messages pass through any middle layer, ARC can be the difference between:

Inbox — or Spam / Reject / Warning Banner.

What ARC Doesn’t Fix

ARC is powerful, but it’s not magic.

ARC does not replace SPF, DKIM, or DMARC. ARC does not sign your original message. ARC does not grant permission to unauthorized senders. ARC does not repair a bad SPF or broken DKIM setup.

ARC is a preservation tool, not an authentication method.

You must still have:

Proper SPF alignment
Working DKIM
A DMARC policy that matches your needs

ARC takes that good setup and makes it durable when your message travels through other systems.

How Stonegate Diagnoses ARC Problems

What I Analyze	Why It Matters / What It Fixes
The full ARC chain in the raw headers	Reveals how every server along the path treated your message and where trust was added or lost.
Where authentication results changed between hops	Pinpoints the exact server causing SPF, DKIM, or DMARC to fail — especially after forwarding.
Whether a gateway or forwarding rule is breaking DKIM	Many intermediaries rewrite messages, silently destroying DKIM alignment. This identifies who’s doing it.
Whether ARC-Seal is valid	Confirms whether an intermediary actually vouched for the message and preserved prior authentication.
Whether ARC-Message-Signature is intact	Shows whether downstream systems can trust the intermediary’s handling — critical for inbox placement.
Whether your domain is aligned correctly before forwarding happens	Prevents the “some people get it, some don’t” problem caused by DMARC failing at the final destination.

Once we pinpoint the break, I can recommend:

Adjustments to forwarding rules
Changes to how contact forms send mail
Fixes for SPF or DKIM alignment
DMARC policy changes
Updating gateway handling modes * Reducing unnecessary “hops”

It’s highly technical work, but the outcome is simple: your email stops failing in places you can’t see.

The Bottom Line

Even if your SPF, DKIM, and DMARC are perfect, your emails can still fail once they move through the modern email ecosystem.

ARC is the protocol that keeps your authentication intact through those multiple hops, and it plays a major role in making sure your messages reach the people they’re supposed to.

If you forward mail, use a security gateway, or run any system that “touches” email on its way to the recipient, ARC matters more than you think.

Want Help Fixing ARC or Deliverability?

If you’re dealing with unexplained spam placement, odd failures after forwarding, or authentication results that “flip” between hops, I can help diagnose and fix that.

Most fixes take me 4–8 hours spread over 2–3 days. I only take 8–10 clients per month so I can over-deliver for each one.

Ready to get your emails into the inbox (not spam) in the next 72 hours?

Fix My Email Deliverability