Email authentication protocols like SPF and DKIM are crucial for verifying sender identity and preventing spoofing. However, these protocols can break when an email is legitimately forwarded through an intermediary mail server, leading to potential DMARC authentication failures. This is where Authenticated Received Chain, or ARC, steps in as a critical solution.
ARC allows an intermediary mail server to assert the original authentication results of a message before it was modified, providing a chain of trust. This chain consists of three main header fields, each playing a specific role in maintaining the integrity of the email's authentication history. Understanding these components is key to effective email deliverability.
One such component is the ARC-Seal header, which contains a cryptographic signature of the message headers at the time the intermediary server processed it. Within this signature, a small but vital piece of information helps maintain order and continuity: the i= tag.
The role of ARC in email forwarding
When an email is forwarded, the intermediary server might alter the message headers or body, which can invalidate the original SPF and DKIM signatures. Without ARC, a receiving mail server, upon seeing these modifications, might deem the message fraudulent and move it to the spam folder, even if it originated from a legitimate sender. ARC prevents this by preserving the authentication history.
The Authenticated Received Chain involves three distinct headers: ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. Each of these headers is essential for forming a complete ARC set. The ARC-Seal header's purpose is to cryptographically sign the previous authentication results and message headers, sealing the chain of trust.
To ensure that all ARC headers belonging to a specific forwarding hop are grouped together and processed correctly, a unique identifier is needed. This is precisely the function of the i= tag.
Understanding the 'i=' tag (ARC instance)
The i= tag in an ARC-Seal header stands for 'instance'. It is a numerical sequence number that indicates the position of the ARC set within the forwarding chain. Each time an ARC-enabled intermediary server processes and re-signs a message, it adds a new set of ARC headers, and the i= tag increments by one.
For example, the first ARC-signing hop will have i=1, the second will have i=2, and so on. This sequential numbering allows the final receiving mail server to correctly identify and process all related ARC headers as a single, cohesive ARC set for a particular forwarding instance. You can find more details on this in RFC 8617.
The presence of the i= tag helps prevent tampering or reordering of ARC sets. If a malicious actor were to insert a fake ARC header, the incorrect i= value would immediately signal a discrepancy to the receiving server, leading to a failed ARC validation.
How the 'i=' tag ensures chain integrity
Mail receivers rely on the i= tag to validate the integrity of the ARC chain. When an email arrives, the receiver examines the ARC headers starting from the highest i= value and works downwards. Each ARC-Seal header's signature is checked against the previous ARC-Authentication-Results and ARC-Message-Signature headers in the chain.
If any i= value is missing, out of sequence, or if a signature fails to validate, the entire ARC chain is considered broken. This immediately flags the email as suspicious, potentially overriding any legitimate authentication results that might have been present at earlier hops. A key part of this validation is the cv tag's role which indicates the chain validation status.
Best practice for ARC validation
Verify each ARC-Seal signature sequentially from highest to lowest i= tag.
Ensure the i= values are continuous and unbroken.
Look for consistency in the s= (selector) and d= (domain) tags within each ARC set, as these link to the signing entity.
Beyond the i= tag, other parameters in the ARC-Seal header like the s= tag (selector) and the d= tag (domain) are also vital. The s= tag identifies the specific ARC signing entity, while the d= tag specifies the domain of that entity. Together, these tags provide a comprehensive snapshot of the email's authentication journey.
The practical implications for email deliverability
For email senders, correctly implemented ARC, with a properly incrementing i= tag, significantly improves email deliverability. It ensures that emails forwarded through legitimate services, such as mailing lists or support desk systems, do not fail DMARC authentication simply because of header modifications. This is especially crucial given the rise of DMARC adoption and stricter email security policies from providers like Google and Yahoo. Learn more about ARC's benefits.
Conversely, a broken ARC chain can lead to messages being marked as spam or even triggering blocklist (or blacklist) entries for the sending domain, hurting its reputation. Monitoring your email authentication, including ARC, is therefore not just a technicality, but a critical aspect of maintaining good sender reputation and ensuring your emails reach their intended recipients. If you're encountering DMARC verification failed errors, ARC issues could be a factor.
Good ARC implementation
Increases trust: Receiving servers can verify legitimate forwarding.
Email deliverability improves: Messages are less likely to be marked as spam.Protects sender reputation: Reduces the risk of domain being blocklisted (or blacklisted).
Decreases trust: Leads to suspicion and potential rejection.
Email deliverability suffers: Higher chances of emails landing in spam folders.Harms sender reputation: Risk of getting your domain on a blocklist or blacklist.
DMARC failures: Legitimate emails fail authentication, impacting your brand.
Managing ARC and DMARC can be complex, but tools are available to help. Suped offers comprehensive DMARC monitoring that provides visibility into your email authentication status, including ARC validation. Our AI-powered recommendations tell you exactly what actions to take to fix issues and strengthen your policy. With real-time alerts, a unified platform for DMARC, SPF, and DKIM, and features like SPF flattening, Suped simplifies email security for businesses of all sizes and for MSPs managing multiple clients.
Key takeaway
The i= tag in an ARC-Seal header is more than just a number; it's a vital component for ensuring the integrity of email authentication across forwarding hops. It acts as a sequence number, tying together all ARC headers related to a specific processing instance.
This seemingly small tag plays a significant role in helping legitimate emails bypass DMARC failures when they travel through intermediaries, ultimately contributing to better email deliverability. For senders, understanding and monitoring ARC is an essential part of a robust email security strategy.
Proactively managing your email authentication, including ARC, SPF, and DKIM, is crucial for maintaining sender reputation and ensuring your messages reliably reach the inbox. Continuous monitoring and swift action on authentication issues are key to success in today's email landscape.
Google and 
Yahoo. Learn more about ARC's benefits.
