Summary
ARC (Authenticated Received Chain) is a critical email authentication standard designed to preserve email authentication results, particularly when messages are forwarded or pass through intermediary servers. Without ARC, DMARC validation can frequently fail for legitimate emails that undergo forwarding, as the forwarding process often modifies the message in ways that break SPF and DKIM signatures. This results in the receiving server seeing a DMARC failure, even if the original message was authenticated correctly. Implementing ARC helps email senders, forwarders, and recipients maintain the integrity of email authentication across multiple hops, ensuring that legitimate emails are not unnecessarily blocked or flagged as spam.
Key findings
- Intermediary role: ARC is primarily implemented by intermediary mail servers and mail transfer agents (MTAs), not by the original sender's email service provider (ESP) or domain owner.
- DMARC preservation: Its main purpose is to allow DMARC to validate emails successfully even after they've been altered by forwarding, by providing a chain of authentication results.
- Mechanism: ARC adds a new set of headers (ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal) to the email, cryptographically signing the previous authentication status and message headers.
- Preventing spoofing: While helping legitimate forwarding, ARC also ensures that these forwarded messages haven't been tampered with, adding another layer of security against spoofing.
- Mailbox provider adoption: Major mailbox providers like Google and Microsoft widely support ARC, processing its headers to inform their DMARC validation decisions.
Key considerations
- Sender responsibility: As a sender, you generally do not implement ARC directly on your outbound mail stream. Your focus should be on proper SPF, DKIM, and DMARC configuration, allowing intermediary servers to apply ARC if they support it.
- Forwarding impact: Understand that email forwarding inherently challenges DMARC, as it often breaks SPF (due to changed sending IP) and DKIM (if the message body or headers are altered). ARC helps mitigate this.
- Policy enforcement: If you are monitoring DMARC reports, you may observe DMARC failures for forwarded emails. ARC-aware receivers can override these failures based on the ARC chain's validity. This is especially relevant when transitioning to p=quarantine or p=reject.
- RFC 8617: The technical specifications for ARC are detailed in RFC 8617, which outlines the protocol for ARC sealing and validation.
What email marketers say
Email marketers often encounter DMARC failures when their legitimate emails are forwarded, leading to confusion about deliverability. Many initially seek to implement ARC themselves, unaware that ARC is typically managed by intermediary mail servers rather than the original sender's infrastructure. While the concept of ARC is understood to help preserve authentication, the practical implications for senders, especially concerning DMARC policy enforcement (like using a p=reject policy), remain a common area of inquiry.
Key opinions
- Frustration with DMARC failures: Marketers frequently report DMARC failures for forwarded emails and are actively looking for solutions to resolve these issues.
- Misconception about ARC control: There's a common belief among marketers that ARC is something they need to set up or configure on their end, similar to SPF or DKIM.
- Seeking technical guidance: Many are keen to understand the technical implementation of ARC and how it interacts with existing email authentication protocols.
- Impact on deliverability: Marketers are concerned about how DMARC failures from forwarding might negatively affect their overall email deliverability rates.
Key considerations
- Focus on DMARC: Instead of implementing ARC, marketers should ensure their SPF and DKIM records are correctly configured and aligned with their DMARC policy. This lays the foundation for ARC to function effectively when intermediaries forward mail.
- Monitoring DMARC reports: Leverage DMARC aggregate and forensic reports to identify patterns of forwarding and DMARC failures. These reports can provide insights into how your emails are being handled by various receiving servers, even when ARC is involved. Tools for understanding DMARC reports are very helpful.
- Policy adjustments: Be aware that setting a DMARC policy to p=reject might increase the visibility of DMARC failures for forwarded mail, but ARC-aware recipients should mitigate this.
- Understanding limitations: Accept that DMARC is designed to break forwarding in certain scenarios. While ARC aims to fix this, not all forwarders or receivers may fully support it, leading to occasional, unavoidable failures.
Marketer view
Email marketer from Email Geeks indicates they are actively looking to implement ARC because they've noticed a significant number of their emails are being automatically forwarded and subsequently failing DMARC authentication. They believe that ARC could be the solution to prevent these legitimate emails from being marked as unauthenticated.
Marketer view
Marketer from a Reddit forum suggests that DMARC reports often show numerous failures attributed to email forwarding, making it difficult to distinguish legitimate issues from those caused by benign mail flow. They express a desire for more granular control or clearer insights into these specific failure types.
What the experts say
Experts consistently clarify that ARC is not a protocol for senders to implement but rather a mechanism for intermediary mail servers. They emphasize that DMARC's design inherently causes authentication failures for forwarded emails, and ARC serves to mitigate this by providing a verifiable chain of authentication. The general consensus is that if you are the original sender, your responsibility lies in proper SPF and DKIM setup, while the forwarding server handles the ARC sealing.
Key opinions
- Sender non-involvement: Senders (like those using an ESP for outbound mail) typically do not implement ARC. It's the responsibility of the intermediary mail server or mail forwarding service.
- DMARC and forwarding: DMARC is designed to detect and block email spoofing, and this often means that legitimate forwarded emails will fail DMARC checks because the forwarding process can break SPF and DKIM.
- Purpose of ARC: ARC exists to provide a mechanism for receiving mail servers to validate the original authentication results of an email that has passed through one or more intermediaries.
- Specific use cases: ARC implementation is relevant for entities that act as intermediaries, such as mailing list operators or email forwarding services, to preserve authentication details.
- Policy overrides: Even with DMARC failures for forwarded mail, receivers that support ARC may apply policy overrides based on the valid ARC chain, allowing the email to pass.
Key considerations
- Architectural understanding: It's crucial to understand the roles of different parties in the email flow. Senders are responsible for initial authentication (SPF, DKIM, DMARC), while intermediaries are responsible for maintaining the ARC chain. For more on this, check out our guide on how email authentication standards work.
- Expected failures: Acknowledge that some DMARC failures, particularly those due to forwarding, are an expected outcome of the DMARC protocol working as intended. ARC aims to provide context, not to eliminate all such failures from DMARC reports.
- DMARC policy impact: When moving to stricter DMARC policies like p=quarantine or p=reject, the importance of ARC by intermediaries for forwarded emails becomes even more pronounced. Understanding DMARC enforcement strategies is key.
- Reporting analysis: Pay close attention to policy override flags within DMARC reports, as these indicate that an ARC-aware receiver may have successfully validated an otherwise failing message.
Expert view
Expert from Email Geeks states definitively that senders do not directly implement ARC; it is the responsibility of the intermediary mail server, such as major providers like Google or Microsoft. This clarifies a common misunderstanding among email professionals.
Expert view
Expert from Word to the Wise suggests that DMARC was intentionally designed to disrupt email forwarding in certain scenarios, particularly when the forwarded message’s authentication no longer aligns with the original sender’s domain. They emphasize that ARC steps in to resolve this specific issue.
What the documentation says
Official documentation, notably RFC 8617, establishes ARC as a standard method for preserving email authentication results across intermediary message handling. It defines the specific headers and cryptographic processes involved in ARC sealing and validation. The documentation clarifies that ARC is designed for forwarding services, mailing lists, and other intermediaries to provide a reliable chain of custody for email authentication data. This ensures that DMARC-aligned messages do not fail authentication when processed by subsequent hops.
Key findings
- Standardization: ARC is an IETF standard defined in RFC 8617, providing a formal framework for its implementation and use.
- Chain of custody: It creates a verifiable 'chain' of authentication results, allowing a final receiver to trust the initial authentication status despite intervening modifications.
- Header components: The protocol specifies three headers: ARC-Authentication-Results (AAR), ARC-Message-Signature (AMS), and ARC-Seal (AS), which are added by each participating intermediary.
- Validation process: Receiving mail servers validate the ARC chain by verifying each signature, ensuring the message hasn't been tampered with since the last ARC-Seal.
- Addressing DMARC failures: ARC directly addresses the issue of DMARC authentication failures that arise from legitimate forwarding by allowing receiving domains to re-evaluate the DMARC status contextually.
Key considerations
- Role of intermediaries: Documentation specifies that ARC is for "participating ARC intermediaries" (IETF Datatracker, RFC 8617), not the initial email sender.
- Signature requirements: Each intermediary in the chain must add its own ARC-Seal, signing the current state of the message and the authentication results it observed.
- DKIM and SPF preservation: ARC provides a way for recipients to assess the validity of an email's original SPF and DKIM authentication even after modifications that would normally cause these to fail.
- DMARC alignment: The ultimate goal of ARC is to allow a DMARC-enforcing receiver to accept messages that would otherwise fail DMARC because of forwarding, provided the ARC chain is valid. Our guide on DMARC implementation has more details.
Technical article
Documentation from IETF Datatracker, RFC 8617, outlines ARC as a protocol for passing email authentication results across intermediary mail servers that might alter messages in ways that invalidate standard authentication. It ensures that the original authentication results can be verified by the final recipient.
Technical article
Documentation from Proton states that ARC builds upon existing SPF, DKIM, and DMARC authentication by solving the problem of email authentication failures when emails are forwarded or otherwise processed by intermediary systems. It aims to preserve the authenticity of the sender's domain.
Related resources
10 resources
Related pages
Why does DMARC authentication fail when SPF and DKIM pass, and how can it be fixed?
How to troubleshoot DKIM implementation issues and understand ARC-Seal in email headers?
How to troubleshoot DMARC failures and their impact on email deliverability?
How do email forwarding and DMARC policies affect email delivery and reporting?
How does ARC impact email deliverability for DMARC-enforced domains, and what are the best practices for marketers?
How do SPF, DKIM, and DMARC email authentication standards work?
How should I roll out DMARC enforcement while considering forwarded emails and DKIM issues?
How does email forwarding affect SPF, DKIM, and DMARC validation?
Understanding and troubleshooting DMARC reports from Google and Yahoo
An advanced guide to email authentication - beyond the basics
