ARC and forwarding — what it is (and why it rarely fixes Gmail)

ARC (Authenticated Received Chain) is often described as “the fix for forwarding.” In practice, ARC is mainly a mechanism for email security gateways and other intermediaries to pass along what they observed when they first received a message. Some receivers may use it as a signal, but it is not a universal override.

Why forwarding breaks in the first place

Modern receivers evaluate email using SPF, DKIM, and DMARC. Classic forwarding can cause SPF to fail (because the forwarder’s IP isn’t authorized) and can break DKIM (because the forwarder or a gateway modifies the message). When both fail, DMARC often fails, and the receiver may reject or heavily filter the message.

Background: Mail security: SPF, DKIM, DMARC — and why forwarding can break it

What ARC is (at a high level)

ARC lets an intermediary add a signed “receipt” that says, roughly:

• What authentication results it observed when it received the message (SPF/DKIM/DMARC results).
• Which intermediary handled the message at each step (a chain), with each step signed.

The goal is to help the final receiver distinguish: “this message originally authenticated, but got modified/relayed by trusted infrastructure” from: “this is just a random spoof that fails auth.”

What ARC is actually used for

ARC is most useful in environments with a security email gateway or similar intermediary that:

• Receives mail first, runs security scanning, and sometimes rewrites content (banners, disclaimers, attachments).
• Then forwards or re-delivers the message onward.

In those flows, the gateway can record that the message passed authentication at the first hop, then sign that assertion. Downstream receivers can choose to consider that evidence.

Why ARC rarely “fixes forwarding to Gmail”

ARC only helps if the final receiver decides to rely on it. Large mailbox providers (including Gmail) generally treat ARC as just one input among many, and they may not accept ARC from arbitrary forwarders.

Also, ARC is not a magic repair for broken DKIM or failing SPF. It does not change the underlying fact that forwarding can make a message look like a spoof.

When ARC can help

ARC can help in narrower cases—typically when:

• The intermediary is well-operated and consistently signs ARC correctly.
• The receiver has a reason to trust that intermediary’s ARC assertions.
• The receiver’s overall spam/phishing signals remain favorable.

Even then, ARC is best thought of as a mitigation that may improve deliverability in some flows, not as a guaranteed fix.

Better patterns if your goal is reliability

If you’re trying to keep a unified inbox, the most reliable approaches avoid looking like “a third-party SMTP sender”:

• Direct delivery (change where mail is delivered so there is no forwarding hop).
• Inbox injection (that’s what we do here): copy/append the message into the destination mailbox via IMAP or provider APIs instead of re-sending via SMTP.

  More details: Gmail is ending POP3 access — what are my options?

The bottom line

ARC is real and useful, but it’s primarily designed for managed intermediary systems (security gateways and large mail operators) and it only helps when the final receiver chooses to trust the ARC chain. For “forwarding to Gmail,” ARC often doesn’t move the needle because Gmail isn’t obligated to treat ARC as authoritative.