Does ARC perform its own SPF or DKIM lookups?

No, ARC does not perform its own SPF or DKIM lookups. Instead, it captures the SPF and DKIM authentication results that were obtained by the upstream mail server. ARC then signs these existing results to ensure their integrity as the email is forwarded, rather than re-running the authentication process itself.

Why is DNS important for ARC if ARC doesn't query it?

DNS is crucial for ARC because ARC relies on the authentication results from SPF and DKIM, both of which heavily depend on DNS queries. Without properly configured SPF and DKIM DNS records, the initial authentication will fail, and ARC will have no valid results to preserve. Additionally, ARC signers need to publish their public keys in DNS.

What is the purpose of the ARC-Seal header?

The ARC-Seal header provides a cryptographic signature over the previous ARC-Authentication-Results and ARC-Message-Signature headers, along with specific fields from the email. Its purpose is to verify that the authentication results have not been altered since the last ARC-aware server processed the email, thus maintaining the chain of trust. This helps email receivers validate the path taken by the email.

Does ARC use DNS queries for validation? - ARC - Email authentication - Knowledge base

Q: Does ARC replace DMARC or SPF/DKIM?

No, ARC does not replace DMARC, SPF, or DKIM. Instead, ARC complements these protocols by providing a mechanism to preserve authentication results across forwarding services and mailing lists. This ensures that DMARC policies can still pass for legitimate emails that would otherwise fail due to intermediate changes, preventing them from being falsely rejected or marked as spam.

An illustration showing an email being processed by a mail server, with DNS queries for SPF and DKIM validation happening before ARC.

The question of whether ARC (Authenticated Received Chain) directly uses DNS queries for its validation process is a common point of confusion. Many email authentication protocols, such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail), are heavily reliant on DNS for their functionality. These protocols query DNS records to verify sender legitimacy and message integrity. ARC, however, operates at a different layer, building upon the results of these underlying authentication mechanisms.

ARC's primary role is to preserve authentication results across forwarding chains and mailing lists, which often break traditional SPF and DKIM checks. It does this by adding a chain of authenticated results and seals to an email as it passes through trusted intermediaries. This allows recipient mail servers to re-evaluate the email's authenticity, even if the original authentication data would otherwise fail due to legitimate modifications or forwarding practices. The core of ARC's own validation is about checking these cryptographic seals, not performing fresh DNS lookups itself.

While ARC itself does not directly perform new DNS queries for its own chain validation, it critically depends on the DNS lookups that SPF and DKIM perform. Essentially, ARC acts as a wrapper for these authentication results, vouching for their integrity as an email traverses multiple servers. Understanding this distinction is key to grasping how ARC contributes to a more robust email authentication ecosystem, particularly for domains utilizing DMARC monitoring.

So, while ARC doesn't query DNS directly, its effectiveness is intrinsically tied to the proper configuration of DNS records for SPF and DKIM, which form the foundation of the authentication results it preserves.

ARC's reliance on existing authentication results

The role of DNS in email authentication

To fully understand ARC's relationship with DNS, it's essential to first review how traditional email authentication protocols utilize it. SPF records are published in DNS as TXT records, listing authorized sending IP addresses for a domain. When an email server receives a message, it performs a DNS query to check the sender's domain SPF record against the connecting IP address.

Similarly, DKIM relies on DNS to retrieve public cryptographic keys. A sending server signs an email with a private key, and the recipient server uses a DNS query to find the corresponding public key, published as a TXT record for the sending domain (e.g., selector._domainkey.example.com). This public key is then used to verify the email's digital signature. Without these DNS records, SPF and DKIM authentication would be impossible, leading to authentication failures and potential delivery issues.

The proper configuration and availability of these DNS records are paramount for email deliverability. Incorrectly configured or missing DNS records can cause legitimate emails to fail authentication, increasing the likelihood of them being marked as spam or rejected outright. This is where tools like Suped's DMARC monitoring become invaluable, providing visibility into your email authentication results and helping identify issues stemming from DNS configuration.

DNS configuration is critical

Properly configured SPF and DKIM DNS records are the bedrock of email authentication. Without them, even ARC cannot effectively vouch for an email's integrity. Ensure your DNS records are correctly published and maintained to support robust email security.

SPF DNS records: Specify authorized sending hosts via TXT records.
DKIM DNS records: Public keys for signature verification are stored as TXT records.
DMARC policy records: Published in DNS as TXT records, dictating how recipients should handle emails that fail SPF or DKIM. Use our free DMARC record generator.

ARC's validation mechanism

How ARC processes authentication results

ARC's primary function is to capture and transmit the authentication results (SPF, DKIM, and DMARC) at each hop an email makes. When an email passes through an ARC-aware intermediary, that intermediary will examine the existing authentication results. If the email passes authentication at that point, the intermediary will then sign those results and the message headers, adding them as new ARC headers to the email. These headers include the ARC-Authentication-Results (AAR), ARC-Message-Signature (AMS), and ARC-Seal (AS) headers.

The recipient mail server, upon receiving an email with ARC headers, can then validate the ARC chain. This involves verifying the cryptographic signatures (the ARC-Seal and ARC-Message-Signature) within the headers themselves. The validation process ensures that the authentication results stored in the ARC-Authentication-Results header have not been tampered with since they were last signed by a trusted ARC participant. This validation does not require new DNS queries for ARC's internal logic; instead, it's about checking the integrity of the chain of trust established by the signatures.

The critical point is that ARC acts as an attestation service, not a primary authenticator. It takes the results of SPF, DKIM, and DMARC (which do use DNS) and certifies that these results were valid at a specific point in the email's journey. So, while ARC doesn't query DNS directly, it's a testament to the fact that DNS-based authentication was successfully performed earlier in the chain. This is crucial for maintaining deliverability for emails sent via forwarding services and mailing lists, which typically cause SPF/DKIM to break due to changes in the sending path. You can learn more about how this works with our guide on how to implement ARC.

Example ARC headers

ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of user@example.com designates 192.0.2.1 as permitted sender) smtp.mailfrom=user@example.com; dkim=pass (signature was verified) header.d=example.com header.i=@example.com header.s=s1; arc=pass (i=1);
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=arc-verifier.example; s=s2;
ARC-Seal: i=1; a=rsa-sha256; t=1678886400; cv=pass; d=arc-verifier.example; s=s2;

ARC's relationship with DNS queries

DNS and ARC setup

While ARC doesn't use DNS for validating the chain, implementing ARC does require some interaction with DNS, specifically for publishing the ARC-Seal signing domain's public key. When a mail server acts as an ARC signer, it must publish a public key in its DNS records so that subsequent recipients can verify its ARC-Seal. This is similar to how DKIM keys are published, but it's for the ARC intermediary's domain, not the original sender's domain. Therefore, an ARC-signing entity needs to configure its DNS records correctly to enable other mail servers to validate the ARC chain. This process is distinct from the regular DNS queries performed for SPF and DKIM. If you're wondering if ARC requires a DNS record for setup, the answer is yes, for ARC signers.

The key here is that any entity signing an ARC-Seal needs to have a public key discoverable via DNS. This allows subsequent receiving mail servers to cryptographically verify the ARC-Seal, ensuring the integrity of the forwarded authentication results. Without this DNS record, the ARC chain cannot be properly validated, negating its purpose. This is a critical component for the secure operation of ARC, establishing trust in the intermediary's attestation.

A padlock symbolizing email security, connected to a chain of SPF, DKIM, and DMARC icons, with a DNS server in the background.

For senders, this means ensuring your primary SPF and DKIM DNS records are always in order. For intermediaries (like mailing list operators or forwarding services), it means properly configuring ARC signing keys in their DNS. The LuxSci blog on ARC further elaborates on how a sending MTA will query DNS as part of its normal processing, which is the foundational action ARC relies on.

ARC's contribution to deliverability

ARC and overall email security

ARC doesn't replace existing authentication protocols, nor does it perform new DNS lookups for validation. Instead, it complements them by providing a verifiable chain of custody for email authentication results. This allows DMARC policies to pass for legitimate emails that would otherwise fail due to forwarding, significantly improving deliverability for senders using complex email routing. Ultimately, ARC helps maintain the integrity of email authentication signals, making it harder for phishers and spammers to exploit forwarding services.

Direct DNS query by SPF/DKIM

SPF and DKIM directly query DNS to verify sender legitimacy and message integrity. They need these DNS records to function at all.

SPF: Retrieves TXT record for authorized sending IPs.
DKIM: Fetches public key from DNS for signature verification.

ARC's validation process

ARC validates the chain of cryptographic signatures within its headers. It trusts the prior authentication results and ensures they haven't been tampered with.

No new DNS queries: ARC does not perform new DNS lookups for existing SPF/DKIM records during its chain validation. It does re-authenticate in a sense, by validating the seals.
Relies on prior results: The SPF and DKIM results enclosed in ARC headers are derived from initial DNS queries.

For organizations serious about email security and deliverability, adopting DMARC with ARC support is a crucial step. It helps to ensure that legitimate emails reach the inbox while preventing spoofing and phishing attacks that rely on breaking authentication. Tools like Suped provide detailed insights into your DMARC reports, allowing you to monitor ARC validation status and troubleshoot any issues efficiently.

In conclusion, while ARC itself does not perform DNS queries for its validation, it is deeply intertwined with DNS through its reliance on SPF and DKIM. These underlying protocols use DNS extensively to establish the initial authenticity of an email. ARC then builds on these results, ensuring their integrity through forwarding chains without needing to re-query DNS itself. Maintaining accurate DNS records for your email authentication is therefore fundamental to ARC's success and overall email deliverability. For a comprehensive overview, read this ARC setup guide.