Why Email Forwarding Breaks DMARC (And What Happens Whe

Why Email Forwarding Breaks DMARC

If you forward an email from one account to another, there's a good chance the forwarded copy fails SPF, DKIM, or DMARC at the destination - even if the original message was fully authenticated. This catches a lot of admins off guard.

The reason forwarding breaks authentication comes down to how SPF, DKIM, and DMARC work.

SPF checks the envelope-from domain against the sending server's IP. When a forwarder re-sends the message from its own servers, the envelope-from domain is now the forwarder's domain, not the original sender's. The forwarder's IP won't match the original sender's SPF record. SPF fails.

DKIM adds a cryptographic signature covering the message body and specific headers. Most forwarding chains modify the message in transit - adding headers, altering the body, or re-wrapping the message. These modifications break the DKIM signature. DKIM fails.

DMARC requires at least one of SPF or DKIM to pass, and for the domain in the RFC5322.From header to align with the domain used in SPF or DKIM. After forwarding, neither SPF nor DKIM typically passes, and even if one did, the alignment would likely fail because the forwarder's domain doesn't match the original sender's domain.

So a legitimate forwarded email can fail all three checks. For individual users this is mostly invisible - forwarded mail just lands in spam or disappears. For mailing lists, alias services, and enterprise forwarding infrastructure, this is a real operational problem.

What ARC Does (And Why It Was Needed)

ARC (Authenticated Received Chain) was designed to solve the forwarding authentication problem. It works by creating a chain of signatures that records each step in the forwarding path.

When a forwarder (say, a mailing list server) receives and re-sends a message, it adds an ARC header set containing:

ARC-Seal - a seal proving this server handled the message
ARC-Message-Signature - a copy of the original DKIM signature (and other authentication results) at this step
ARC-Authentication-Results - a record of the SPF, DKIM, and DMARC results the forwarder observed

Each subsequent server in the chain can see the full ARC history. When the message finally reaches its destination, the receiving server can evaluate the ARC chain and understand that yes, this message was authenticated at origin, and these intermediate steps are documented.

In practice, ARC let forwarding services, mailing lists, and email alias platforms participate in the authentication chain without breaking it. Google, Yahoo, and several major mailing list operators implemented ARC support.

Why ARC Is Being Retired

ARC was always a workaround - a layer on top of a system that wasn't designed for forwarding. The critical weakness: ARC only worked if all parties in the forwarding chain implemented it. If even one hop didn't support ARC, the chain broke.

RFC 8617 (published 2019) defined ARC as an experimental extension. It never became a standard requirement, and adoption beyond major providers remained thin. Most small-to-medium mailing list services, self-hosted forwarders, and enterprise email gateways never implemented it.

The email ecosystem has increasingly moved toward a different solution: DKIM2, which is designed from the ground up to handle multi-hop forwarding without needing a parallel authentication chain.

What Replaces ARC - DKIM2 and Forwarding Authentication

DKIM2 is an IETF draft standard that changes how DKIM signatures work in forwarding scenarios. The current DKIM model is: the originating mail server signs the message once, and any modification in transit breaks that signature.

DKIM2 introduces a "chain of custody" model. Instead of one signature that breaks when anything changes, DKIM2 allows intermediate servers to add their own signatures to the chain. A mailing list or forwarder can sign the message at its hop without invalidating the original signature. The destination server can verify all signatures in the chain.

This is architecturally cleaner than ARC because:

It uses the same DKIM infrastructure, not a separate protocol
Each hop adds a signature rather than creating a workaround chain
No middlebox needs to understand a separate "ARC header" concept

DKIM2 is still a draft standard (as of 2026). Full implementation across major mail providers is in progress but not complete. For operators running forwarding infrastructure today, this means: ARC is going away before DKIM2 is fully deployed. There is a gap period.

What Admins Need to Do Now

If you run mailing list software, an email aliasing service, or any forwarding infrastructure that depends on ARC:

Check whether your current software supports DKIM2. Many major platforms (Google, Yahoo, some SEG vendors) are implementing DKIM2 support. Your vendor's roadmap page or release notes should say.
Monitor DMARC reports more closely during the transition. Without ARC, forwarding failures will be more visible in your DMARC aggregate reports. Previously, ARC may have masked forwarding auth failures from downstream receivers. Now those failures show up as SPF/DKIM failures - which means your data gets more accurate, but you may see more noise.
Review your forwarding architecture for unnecessary hops. If a forwarded email passes through three middleboxes before reaching its destination, each one is an opportunity for auth to break. Reducing hop count reduces failure surface.
Document which forwarding services your domain depends on. If you rely on third-party forwarding services (vacation auto-responders, email-to-SMS gateways, legacy alias systems), confirm they have a plan for the post-ARC world.
Watch the DKIM2 rollout from your major receiving partners. When Google and Microsoft fully support DKIM2 verification on the receiving side, the forwarding problem changes significantly. Check their postmaster tools pages for DKIM2 status.

How to Monitor Forwarding-Related DMARC Failures

Diferent DMARC providers can help monitor and visualise.

Forwarding-related DMARC failures show up in your aggregate reports as sources that pass neither SPF nor DKIM. If you see a consistent source IP that fails authentication but you know it's a legitimate forwarding service, that's a forwarding auth gap in your data. Most Providers for DMARC have agregated reports but not all go into such indepth detail.

We used DMARCFlow for 2 weeks to see what it detects here: When ARC was active, some forwarding failures were handled silently by receiving servers that understood ARC but didn't always report the underlying auth failure upstream. Now that ARC is being retired, those failures show up in your DMARC data - which means you may suddenly see more failures from forwarding sources you thought were working correctly. DMARCFlow's aggregate report parsing surfaces these patterns: sources with zero authentication results, or sources where SPF and DKIM both fail consistently despite your domain having correct records. That pattern is a signal that either a forwarder is breaking your auth, or you have a configuration gap you weren't aware of. The post-ARC world gives you more honest data, but only if your monitoring actually shows you the failures.

Frequently Asked Questions

Does ARC retirement affect whether my forwarded emails pass DMARC?

It doesn't change the technical behavior of DMARC checking. What changes is how receiving servers handle forwarded mail that fails authentication. ARC gave receiving servers a way to still accept forwarded mail that would otherwise fail. Without ARC, a receiving server that strictly enforces DMARC may reject forwarded mail it previously accepted.

Will DKIM2 fix forwarding authentication completely?

DKIM2 is designed to fix this, but it's not fully deployed yet. The timeline depends on when major mail providers (Google, Microsoft, Yahoo) enable DKIM2 verification on both signing and receiving. As of 2026, the draft is advancing but the ecosystem is in transition.

Should I remove my ARC headers now?

No. Keep ARC headers in place for now - many receiving servers still process them and it won't hurt. The retirement is on the receiving side (servers no longer evaluating ARC), not a requirement to strip headers from your forwarded mail.

What about SRS (Sender Rewriting Scheme)?

SRS is another approach to the forwarding problem. It rewrites the envelope-from address so SPF passes at the destination. SRS has operational tradeoffs - it adds complexity, and it doesn't help with DKIM. Most modern deployments are watching DKIM2 closely as the preferred long-term solution.

My mailing list is still using ARC. What should I do today?

Check with your mailing list software vendor for a DKIM2 roadmap. In the meantime, nothing changes immediately - ARC headers are still harmless to include, and the receiving-side retirement will be gradual. But don't wait until DKIM2 is fully deployed to start planning your migration.