How to implement ARC (Authenticated Received Chain) and how does it affect DMARC failures from forwarding?
Matthew Whittaker
Co-founder & CTO, Suped
Published 21 Jul 2025
Updated 17 Aug 2025
8 min read
Email forwarding is incredibly common, yet it often causes headaches for DMARC implementation. I’ve heard many people express frustration when their legitimate emails, once forwarded, start failing DMARC authentication, leading to messages landing in spam or being rejected. It feels counterintuitive when you've diligently set up your SPF, DKIM, and DMARC records.
The core issue is that forwarding an email can modify its content or headers, which can invalidate the existing SPF and DKIM signatures. When SPF (Sender Policy Framework) checks are performed, they look at the IP address of the server sending the email. If an email is forwarded through an intermediary server, the IP address changes, causing SPF to fail.
Similarly, DKIM (DomainKeys Identified Mail) uses cryptographic signatures that are sensitive to changes in the email's headers or body. Even minor alterations by a forwarding server can break the DKIM signature, leading to authentication failures. Because DMARC (Domain-based Message Authentication, Reporting, and Conformance) relies on both SPF and DKIM passing *and* aligning with the From address, these breaks in authentication lead to DMARC failures.
This is where Authenticated Received Chain (ARC) comes into play. It's a protocol designed to preserve email authentication results across multiple hops (intermediary servers). If you're struggling with DMARC failures due to forwarding, understanding ARC is key, but the actual implementation might not be what you expect.
DMARC's primary goal is to prevent email spoofing and phishing. It achieves this by instructing recipient mail servers on how to handle emails that fail SPF or DKIM alignment. While this is crucial for security, it inadvertently flags legitimate forwarded emails as potentially fraudulent.
A common scenario is when a user forwards an email from their personal inbox to a work email. The work email server then checks DMARC against the original sender's domain. Since the email passed through the personal email provider's server, SPF will likely fail. If the forwarding also altered the message, DKIM could fail too. This leads to a DMARC failure.
DMARC is, in a sense, designed to break forwarding, because any server that modifies or re-transmits an email in a way that breaks authentication is treated as suspicious by default. This strictness is important for security but creates a challenge for legitimate email flows. This is also why many organizations, when they set their DMARC policy to p=reject or p=quarantine, might see an increase in legitimate forwarded emails being blocked or sent to spam.
To troubleshoot DMARC failures and understand their impact on deliverability, it is essential to monitor your DMARC reports. These reports provide invaluable insight into where your emails are failing and why, including instances related to forwarding. Understanding how email forwarding and DMARC policies affect delivery is a crucial step in maintaining good inbox placement.
How ARC (Authenticated Received Chain) works
ARC is designed to solve the problem of DMARC breaking legitimately forwarded emails. It provides a way for intermediary mail servers to attest to the original email's authentication results, even after modifications. Essentially, it creates a chain of custody for an email's authentication status.
When an ARC-enabled intermediary receives an email, it first verifies the original email's SPF, DKIM, and DMARC status. It then seals these results into new ARC headers and signs them. This signature ensures that the ARC headers themselves haven't been tampered with. The key ARC headers are:
ARC-Authentication-Results: Contains the authentication results (SPF, DKIM, DMARC) of the previous hop.
ARC-Message-Signature: A DKIM-like signature covering the ARC headers and other message parts, proving their integrity.
ARC-Seal: A signature that confirms the integrity of the entire ARC chain, including previous ARC-Seal headers.
When the final recipient mail server receives the email, it can validate the ARC chain. If the chain is intact and trustworthy, the receiver can then use the original authentication results, even if SPF or DKIM technically failed locally. This allows legitimate forwarded emails to pass DMARC and reach the inbox, instead of being incorrectly flagged as spam. The RFC 8617 document provides the full technical specification.
Who implements ARC?
A common point of confusion arises when senders (like you, if you're sending marketing or transactional emails directly to recipients) try to figure out how to implement ARC. The truth is, original senders do not implement ARC. Your responsibility as a sender is to ensure your emails are properly authenticated with SPF and DKIM. ARC is handled by the intermediary servers, such as mailing lists, email forwarding services, or even large mailbox providers like Google and Microsoft, if they decide to support it.
Think of it this way: ARC adds a layer of trust. The intermediary server, upon receiving your email, performs its own authentication checks. If those pass, and it's forwarding the email on, it attaches an ARC seal. This seal essentially says, "I received this email, verified its original authentication status, and I'm forwarding it now." The final recipient server can then choose to trust this seal.
Your role is to ensure that your emails are perfectly aligned for DMARC before they even reach a forwarding service. This means proper SPF and DKIM setup for your sending domain, with SPF alignment and a valid DKIM signature that matches your From domain. If your emails are correctly authenticated at the source, an ARC-enabled intermediary can then correctly attest to their legitimacy.
Focus on consistent alignment between your From header domain and your SPF/DKIM domains.
Monitor DMARC reports to identify forwarding-related failures.
The true implementation of ARC
For email forwarding to work seamlessly with DMARC, the intermediary service needs to be ARC-enabled. When a mail server acts as a forwarder (e.g., a personal email alias forwarding to another inbox, or a mailing list), it should, ideally, implement ARC sealing.
The implementation itself is complex and typically involves server-side configurations. It's not something you, as a domain owner or marketing professional, would configure directly in your DNS records or sending platform, unless your organization is an intermediary service.
For example, Mailgun has implemented ARC support for their email routing service, meaning if you use them for forwarding, they'll handle the ARC sealing. Similarly, major mailbox providers like Yahoo and Gmail (who enforce DMARC policies for incoming mail) also support validating ARC seals. This helps ensure that legitimate emails forwarded through their systems are not erroneously blocked. You can understand more about ARC's role in email delivery by reading their blog post on the topic.
If you are a sender and observe DMARC failures due to forwarding, the best approach is to continue ensuring your initial authentication is strong. If a recipient's mail server supports ARC, it will handle the authentication chain. If it doesn't, there isn't much you can do as the original sender to force that server to implement ARC.
Maintain pristine SPF and DKIM records for your sending domains to ensure the initial authentication is flawless.
Regularly review your DMARC aggregate reports to identify sources of DMARC failures, including those from forwarded emails.
Use a robust DMARC monitoring solution to gain granular insights into authentication results and policy overrides.
Common pitfalls
Mistakenly believing that ARC is something you, as the original sender, need to configure in your DNS.
Ignoring DMARC failures caused by forwarding, especially if your policy is at p=none, as this can still impact reputation.
Failing to understand that DMARC is designed to break authentication upon modification, which is its security feature.
Expert tips
If you operate a mailing list or email forwarding service, consider implementing ARC to preserve authentication results for your users.
Focus on achieving DMARC enforcement (p=quarantine or p=reject) to maximize the benefits of email authentication, even with forwarding challenges.
ARC helps with DMARC for forwarded messages, but strong SPF and DKIM are still the foundation for direct delivery.
Expert view
Expert from Email Geeks says ARC is implemented by the intermediary mail server, such as Google or Microsoft, and not by the original sender of the email.
2024-01-19 - Email Geeks
Expert view
Expert from Email Geeks says if you are a forwarder or manage a mailing list, you should implement ARC. If you are just sending emails and there's no hop before you, there's nothing for you to seal.
2024-01-19 - Email Geeks
Key takeaways for DMARC and ARC
While you, as an email sender, don't directly implement ARC, it's essential to understand its purpose and how it functions. It's a critical piece of the modern email authentication puzzle that helps mitigate the challenges posed by email forwarding and DMARC's strict alignment requirements. The main takeaway is to ensure your outgoing emails are impeccably authenticated at the source with SPF and DKIM.
By focusing on strong foundational authentication, you enable ARC-enabled intermediary servers to successfully preserve your email's legitimacy. This collaborative effort across the email ecosystem ensures that your messages reach their intended recipients, even after passing through multiple hops. Regularly reviewing your DMARC reports will help you monitor for any anomalies related to forwarding and maintain optimal deliverability.
Google and 
Microsoft, if they decide to support it.
Mailgun has implemented ARC support for their email routing service, meaning if you use them for forwarding, they'll handle the ARC sealing. Similarly, major mailbox providers like 
Yahoo and Gmail (who enforce DMARC policies for incoming mail) also support validating ARC seals. This helps ensure that legitimate emails forwarded through their systems are not erroneously blocked. You can understand more about ARC's role in email delivery by reading their blog post on the topic.
