Yes, technically, Authenticated Received Chain (ARC) does add a small amount of overhead to email processing. Any additional step in a system will inherently introduce some level of processing and data overhead. However, the crucial point is that this overhead is generally considered negligible when weighed against the significant benefits ARC provides for email deliverability.
Let's break down what ARC is, the type of overhead it introduces, and why it's a worthwhile trade-off for any modern email system, especially for those using mailing lists or forwarders.
What is ARC and why is it necessary?
Authenticated Received Chain is an email authentication protocol designed to solve a common problem created by SPF and DMARC. When an email is sent through an intermediary, like a mailing list or a forwarding service, that intermediary often modifies the email in a way that breaks the original sender's authentication. For example, the mailing list server becomes the new sending server, causing an SPF alignment failure. This can lead to legitimate emails being marked as spam or rejected outright.
ARC works by adding a new set of headers to the message. These headers effectively create a chain of trust, preserving the initial authentication results as the email travels through different servers.
The types of overhead introduced by ARC
The overhead from ARC can be split into two categories: computational and data.
- Computational Overhead: When an intermediary mail server processes an email, it must perform cryptographic operations to generate and sign the ARC headers. This involves creating a hash of the message headers and body and then signing it. Similarly, the final receiving mail server must perform cryptographic operations to verify the ARC signatures. This requires CPU cycles on both the intermediary and receiving servers.
- Data Overhead: ARC adds three new headers to every email that passes through an ARC-enabled intermediary. As AutoSPF points out, these headers create a trusted chain. The headers are: ARC-Authentication-Results (AAR), ARC-Seal (AS), and ARC-Message-Signature (AMS). While these headers increase the total size of the email, the increase is very small, usually just a few kilobytes.
Is the overhead significant?
For virtually all modern mail servers, the answer is no. The overhead is not significant.
The cryptographic calculations are lightweight and are a minor part of the overall work a mail server does. Tasks like content filtering, virus scanning, and processing other complex rules consume far more resources than verifying an ARC signature. The additional data from the headers is trivial compared to the size of typical emails, especially those containing attachments or rich HTML content.
The key takeaway is that the problem ARC solves is far more impactful than the resources it consumes. As Bento notes, ARC significantly improves email deliverability by giving the final mail server a trusted history of an email's authentication journey. Without ARC, a perfectly valid email could be rejected simply because it was sent through a mailing list. With ARC, that email is much more likely to be delivered successfully.
Conclusion
In summary, while ARC does introduce a slight, measurable overhead in both computation and data size, this cost is minimal. The functionality it provides is essential for maintaining email deliverability in complex mail flows involving intermediaries. The risk of legitimate emails failing authentication without ARC presents a much greater operational cost than the tiny amount of processing power and bandwidth ARC requires. Therefore, implementing ARC is a highly recommended practice, and its overhead should not be a concern for system administrators.
