Yes, Authenticated Received Chain (ARC) absolutely uses DNS queries as a core part of its validation process. To understand why, it's helpful to first understand what ARC is and what problem it solves. In short, ARC is an email authentication protocol designed to preserve the original authentication results (like SPF and DKIM) of an email as it gets forwarded through various mail servers, such as mailing lists or forwarding services.
As AutoSPF notes, ARC lets the recipient's mail server check the authentication results of forwarded or relayed emails. This is crucial because forwarding can often break SPF and DKIM alignment, causing legitimate emails to fail DMARC checks.
How ARC validation works
When an email travels from its origin to a final recipient, it can pass through several intermediary servers. A common example is a mailing list server. When the mailing list server receives the email, it might make slight changes to the content, like adding a footer, which would break the original DKIM signature. The mailing list server's IP address will also not match the original sender's SPF record, causing SPF to fail.
To solve this, an ARC-supporting intermediary server will:
- Verify the incoming email's SPF, DKIM, and DMARC status.
- Preserve these original authentication results.
- Sign the email with its own ARC "seal" before forwarding it. This seal is a cryptographic signature added to the email headers, attesting to the original results.
This creates a "chain of custody." Each server in the path can add its own seal, creating a sequence that the final recipient can inspect to understand the email's journey and original authentication status.
The role of DNS in ARC validation
The cryptographic signature at the heart of the ARC seal functions very much like a DKIM signature. To validate that the seal is authentic and hasn't been tampered with, the receiving mail server must verify it using a public key. This public key is published in the DNS by the sealing server (for example, the mailing list's domain).
Therefore, for every ARC seal a recipient server needs to validate, it must perform a DNS query to fetch the corresponding public key. This is explicitly stated in the official IETF specification for ARC, RFC 8617.
This means if an email passes through three different forwarding servers that each add an ARC seal, the final mail server might need to make up to six DNS queries just to validate the ARC chain, in addition to any lookups for the final SPF and DKIM checks.
Why this matters for email deliverability
Without ARC, a perfectly legitimate email sent to a mailing list would likely have its DMARC authentication fail by the time it reaches the final recipients' inboxes. The original SPF check would break due to the new sending server, and the DKIM signature would break if the mailing list software added a prefix to the subject line or a footer to the message body.
Such a failure could cause the email to be rejected or sent to the spam folder, and in some cases, could contribute to the sending domain's reputation being harmed, potentially landing it on a blacklist. ARC provides the necessary context for the receiving server to make a more informed decision. It can see the 'fail' result from the final DMARC check but also see the trusted ARC chain showing the message was originally authenticated. This prevents legitimate mail from being blocked and improves overall deliverability for complex mail flows, helping you stay off a blocklist (or blacklist).
So, while ARC adds a few more DNS lookups to the email validation process, it plays a vital role in maintaining the integrity of DMARC and ensuring that emails that go through intermediaries are still delivered reliably.
