Email authentication is crucial for deliverability and combating spoofing, but traditional methods like SPF and DKIM can break when emails are forwarded or sent through mailing lists. This is where the Authenticated Received Chain (ARC) protocol comes into play, and central to its function is the ARC-Seal header. It acts as a digital signature, allowing mail servers to verify the authenticity of an email, even if it has undergone legitimate modifications by intermediate servers.
Essentially, the ARC-Seal provides a way to cryptographically attest to the email's authentication results at each hop it takes. Think of it as a chain of custody, ensuring that legitimate forwarding or processing by a mailing list doesn't inadvertently cause an email to fail authentication checks, which would otherwise lead to it being marked as spam or rejected.
The ARC-Seal header: A deeper dive
The necessity of ARC
Before ARC, a common problem arose when an email was forwarded. The original authentication, like SPF or DKIM, might pass for the initial sender. However, when an intermediate server (like a mailing list or a forwarding service) modifies the email's headers or routing path, SPF could fail because the forwarding server's IP address doesn't match the original sender's SPF record. Similarly, DKIM could break if the body content or certain headers were altered during transit. This often led to legitimate emails being flagged as suspicious or spam.
The core purpose of ARC is to preserve these authentication results across such intermediary steps. It creates a verifiable trail, allowing the final receiving mail server to see the original authentication status of an email, as well as any subsequent authentication results added by each intermediary. This is vital for DMARC to work correctly in complex email flows, as DMARC relies on SPF or DKIM alignment.
ARC achieves this by introducing three new email headers: ARC-Authentication-Results, ARC-Message-Signature, and the ARC-Seal header. Each one plays a specific part in building and verifying the chain of custody.
The ARC-Seal header: A deeper dive
The ARC-Seal header: A deeper dive
The ARC-Seal header is a cryptographically signed copy of the email's previous ARC-Authentication-Results header and certain message headers. This signature is crucial because it ensures the integrity of the authentication results as the message travels. When an intermediary mail server processes an email and adds its own ARC headers, it uses the ARC-Seal to vouch for the authentication state it observed. The ARC-Seal includes several tags that provide vital information for its validation.
Key tags within the ARC-Seal header are s= for the selector, which points to the DNS record containing the public key needed to verify the signature, and d= for the signing domain. These are fundamental for a receiving mail server to locate the appropriate public key and cryptographically validate the ARC-Seal, much like DKIM signatures.
Additionally, the i= tag indicates the instance of the ARC chain, helping to order multiple ARC-Seals in a forwarded message. The cv= tag, which stands for chain validation status, tells the receiver whether the prior ARC chain (if any) validated correctly at the point of signing. A cv=pass indicates that the preceding ARC chain was successfully verified by the current signing server.
Each time an email passes through a server that supports ARC, that server adds a new set of ARC headers. The server first validates the existing ARC chain (if any) and then creates its own ARC-Authentication-Results header based on its own checks. It then uses this result to generate a new ARC-Message-Signature and finally, an ARC-Seal. This process repeats with each ARC-enabled hop, forming a verifiable chain back to the original sender.
When an email reaches its final destination, the receiving mail server (like Gmail or Outlook) can validate the entire ARC chain. It starts by verifying the most recent ARC-Seal, then checks the one before it, and so on, working backward to the initial ARC-Seal. If all seals in the chain are valid and the chain's integrity is intact, the receiver can trust the original authentication results, even if SPF or DKIM failed due to forwarding. This mechanism is formally defined in RFC 8617.
Without ARC
SPF/DKIM break: Forwarded emails or messages from mailing lists often fail standard authentication checks like SPF and DKIM due to changes in headers or sending paths.
Increased spam risk: Legitimate emails can be misidentified as spam or phishing attempts, leading to poor deliverability.
Reputation damage: Domain reputation can suffer if legitimate emails are consistently rejected or sent to spam folders.
With ARC
Authentication preserved: ARC provides a verifiable chain of custody for emails, preserving the original authentication results through forwarding. You can learn more about this in Proton's blog.
Improved deliverability: Receiving servers can trust the authenticity of emails, reducing false positives and improving inbox placement.
Enhanced trust: A robust ARC implementation builds trust with recipient mail servers, helping to maintain a positive sender reputation.
Benefits and impact of ARC-Seal
Benefits and impact of ARC-Seal
The primary benefit of the ARC-Seal, and ARC in general, is significantly improved email deliverability for forwarded messages and mailing list subscribers. Without ARC, these emails would frequently fail DMARC checks, leading to rejection or placement in the spam folder. With ARC, the integrity of the original authentication is verifiable, ensuring that legitimate communication reaches its intended inbox, even after being handled by multiple intermediaries.
This enhancement not only boosts deliverability but also strengthens the overall trust in the email ecosystem. By allowing legitimate forwarding services to preserve authentication, ARC helps reduce false positives while still providing robust protection against malicious spoofing. This delicate balance is critical for the smooth functioning of email communication in today's complex landscape.
Best practices for ARC
Implement DMARC: Ensure your domain has a strong DMARC policy, as ARC works to support DMARC in complex scenarios.
Monitor ARC reports: Regularly review your DMARC aggregate reports for ARC data to understand how your emails are being authenticated after forwarding. This helps identify issues where ARC might not be properly implemented by intermediaries.
Verify ARC seals: If you operate a forwarding service, ensure your infrastructure correctly adds and validates ARC-Seals to preserve authentication.
For domains looking to achieve maximum deliverability and ensure their emails are always trusted, integrating ARC validation into their DMARC strategy is essential. Suped provides robust DMARC monitoring that includes insights into ARC performance, helping you understand how your emails are being authenticated across the internet. Our AI-powered recommendations help you to quickly diagnose issues and keep your email streams healthy.
Ensuring email trust
Ensuring email trust
The ARC-Seal header is a critical component of the ARC protocol, designed to solve a long-standing challenge in email authentication: preserving verification results when messages are legitimately modified in transit. By creating a cryptographic chain of custody, ARC allows mail servers to confidently assess the authenticity of an email, even if it has passed through various forwarding services or mailing lists.
This mechanism is indispensable for maintaining high deliverability rates and ensuring that legitimate emails reach their recipients without being mistakenly flagged as spam. For anyone serious about email security and deliverability, understanding and monitoring the ARC-Seal is as important as configuring SPF, DKIM, and DMARC.
Email authentication continues to evolve, and protocols like ARC provide the necessary layers of security and trust to navigate increasingly complex sending environments. The ARC-Seal is a testament to the ongoing efforts to ensure email remains a reliable and secure communication channel for everyone.