Why Email Forwarding Breaks DMARC When ARC Goes Away

When you forward an email to someone, the authentication checks often break, even when the original message was fully legitimate. SPF fails. DKIM breaks. DMARC shows failures in aggregate reports that are hard to explain to non-technical stakeholders. If you've ever had to tell someone that their forwarded newsletter sign-up confirmation is being rejected because of authentication failures, you already know the problem.

This happens because forwarding changes the email's path in ways that authentication protocols were not designed to handle. The fix used to be ARC (Authenticated Received Chain). Now ARC is being retired. This article explains why forwarding breaks authentication, what ARC was doing, why it's going away, and what replaces it.

Why Email Forwarding Breaks DMARC

Email authentication, SPF, DKIM, and DMARC, each check a different part of the email's journey.

SPF checks whether the IP address sending the email is authorized to send for the sender's domain. When a mail server forwards a message, it becomes the new sending server. The forwarder's IP was never in the original sender's SPF record, so SPF fails.

DKIM attaches a cryptographic signature to an email that survives transit. But many forwarding services modify email headers or content slightly, adding list-ID headers, altering subject lines, or changing MIME structure. Any of these modifications invalidate the DKIM signature, even when the modification is benign.

DMARC requires that either SPF or DKIM passes and that the domain in the From: header aligns with the domain that authorized the sending. When a forwarder relays mail from `original-sender.com` through its own infrastructure, the auth results no longer align with `original-sender.com`'s DMARC policy. DMARC fails.

The practical consequence: forwarded mail from legitimate, well-configured senders gets flagged or rejected at the receiving mailbox provider, solely because of the forwarding path.

What ARC Does (And Why It Was Needed)

ARC was introduced to solve this problem. It works as a chain of signatures added by each server that handles a message after the initial delivery.

Here's how it works:

The original sending server adds an ARC header with its authentication results, SPF pass/fail, DKIM pass/fail, and the aligned domain.
When the forwarding server relays the message, it adds its own ARC header, capturing the authentication results as it observed them, before making any changes.
This chain survives transit, even when the forwarder modifies headers or content.

When the final recipient's server evaluates the message, it can look back through the ARC chain and see that the original sender's authentication was valid, even if the immediate sender's authentication is broken. ARC preserved the signal through transformation.

This made it possible for forwarding-heavy environments, mailing lists, email aliasing services, certain enterprise relay setups, to use SPF, DKIM, and DMARC without having every forwarded message rejected.

Why ARC Is Being Retired

ARC never reached widespread adoption. Most large mailbox providers did not implement ARC validation. The primary beneficiaries were specialized forwarding and mailing-list operators, not the broader email ecosystem.

The maintenance burden of a rarely-used protocol that nobody validates is hard to justify. The IETF working group that owned ARC was chartered for network infrastructure, not email, it effectively became unmaintained.

The other factor: DKIM2 is coming. The new DKIM standard, in IETF draft, has a fundamentally different approach to forwarding. Rather than trying to preserve authentication results through a chain, DKIM2 is designed so forwarders add their own signature to a message rather than being forced to break an existing one. The "chain of custody" model in DKIM2 is meant to replace what ARC was doing, without requiring a parallel protocol.

What Replaces ARC - DKIM2 and Forwarding Authentication

DKIM2 is the successor actively being standardized. The key difference in how it handles forwarding:

Current DKIM (RFC 6376): The original sender signs the message. Any server in the middle that modifies the message, even slightly, breaks that signature. Forwarders are forced to choose between forwarding faithfully and maintaining authentication.

DKIM2 (draft): The original sender signs. Forwarders add their own additional signature rather than replacing or breaking the original. Recipients check any signature in the chain, and the trust model is additive rather than destructive.

This means forwarded mail can carry a valid DKIM2 signature from the original sender and from the forwarder, rather than having the original signature destroyed by transit modifications.

DKIM2 is still in draft status. Early implementations exist, but full ecosystem adoption, particularly among major mailbox providers, is not yet in place. For operators running forwarding infrastructure today, the practical path forward involves either waiting for DKIM2 adoption or ensuring that forwarding is configured to minimize header modifications that break DKIM.

What Admins Need to Do Now

If you run forwarding infrastructure or a mailing list service, here's what to do:

Monitor your DMARC reports for forwarding-related failures. With ARC going away and DKIM2 not yet widespread, auth failures that were previously partially masked will become fully visible in aggregate reports. Using a DMARC report aggregator that parses source IPs and reason codes at scale makes this tractable, raw XML from hundreds of sending sources is time-consuming to triage manually. Companys like DMARCFlow surfaces forwarding patterns in structured form so you can distinguish forwarding-related failures from genuine spoofing by monitoring your DMARC reports, including forwarding-related failures and giving you a structured, actionable view. If you're seeing auth failures in your reports and can't explain them, this can help you identify the source.
Audit what your forwarder does to email headers. List-ID insertion, Subject modification, and Content-Type changes all break DKIM. Some of these are configurable; some are not. Knowing exactly what your forwarding service modifies is prerequisite to fixing it.
Review the DMARC policies of domains you're forwarding on behalf of. If those senders have `p=quarantine` or `p=reject`, forwarded mail will be flagged. This is not an error, it's a predictable consequence of how DMARC works.
Track DKIM2 adoption in your ecosystem. As mailbox providers implement DKIM2 support, the forwarding problem will ease. There is no urgent reason to change a currently working setup, but monitoring your auth reports and the standards track is practical ongoing work.
Consider whether forwarding is the right architecture for your use case. Some workflows that use forwarding could use a different pattern, a shared inbox with proper authentication, for instance, that sidesteps the forwarding authentication problem entirely without requiring workarounds.

How to Identify Forwarding Failures in DMARC Reports

A forwarding-related failure typically looks like this in your DMARC aggregate reports:

SPF fails because the forwarder's IP is not in the sender's SPF record
DKIM fails because the forwarder modified headers or content
DMARC fails because neither SPF nor DKIM aligns with the From: domain

The `source_type` and `reason` fields in a DMARC aggregate report help distinguish forwarding failures from genuine authentication problems. A high volume of failures from a consistent set of source IPs belonging to the same forwarding provider, with a `reason` field indicating alignment failures, is almost certainly forwarding-related, not malicious.

Parsing these signals at scale requires structured report processing. If you're reviewing raw XML RUA reports manually, you're likely missing the pattern.

Frequently Asked Questions

Is ARC already retired? ARC is not formally deprecated, but it is no longer actively maintained. The IETF working group that owned it is chartered for network infrastructure, not email. If you're running ARC-dependent infrastructure, plan for its eventual removal.

Will forwarded emails stop being delivered when ARC is gone? In most cases, not immediately. Most large mailbox providers never implemented ARC validation, so delivery was never ARC-dependent for most mail flows. The change mainly affects operators who were relying on ARC to maintain an authentication signal through their forwarding infrastructure.

Can I implement DKIM2 now? Early DKIM2 implementations exist, but full ecosystem adoption, especially among major mailbox providers, is not yet in place. You can begin testing DKIM2 signing if your email infrastructure supports it, but don't expect widespread validation until major providers add support.

Does DMARC `p=reject` affect forwarded mail? Yes. If a domain has `p=reject` and a forwarder relays that domain's mail without proper handling, the mail will be rejected at the receiving provider. Organizations with `p=reject` policies need to ensure their forwarding infrastructure is either excluded from DMARC evaluation or handled through a mechanism, such as mailing-list relays, that can maintain alignment.

What's the quickest operational fix for forwarding auth failures? Use a subdomain or dedicated sending domain for forwarded mail, with its own SPF record and a looser DMARC policy. This isolates forwarding traffic from your primary domain's authentication setup. Long-term, DKIM2 will reduce the need for these workarounds.

How do I know if forwarding is causing my DMARC failures? In your DMARC aggregate reports, look for a high volume of failures from a consistent set of source IPs that all belong to the same forwarding provider, with a `reason` field indicating alignment failures. That's the signature of forwarding-related auth breakdown. If you're not parsing RUA reports into structured source-level data, you'll likely miss this pattern in the raw XML.