Who is responsible for setting up ARC DNS records?

The intermediaries, often email service providers, mailing list operators, or forwarding services, are responsible for setting up ARC DNS records. These records (ARC-Set TXT records) contain the public keys used to verify the ARC seals they apply to emails.

Can I use ARC without SPF and DKIM?

No, ARC does not function independently. It is built upon SPF and DKIM. ARC's purpose is to preserve the authentication results from these protocols as emails pass through intermediaries. Therefore, SPF and DKIM must be enabled and properly configured for ARC to be effective.

How does ARC help with DMARC compliance?

ARC helps with DMARC compliance by allowing legitimate emails to pass DMARC checks even after being modified by trusted intermediaries. Without ARC, these modifications would cause SPF or DKIM to fail, leading to DMARC failure. ARC provides a chain of custody, enabling receiving servers to validate the original authentication status, thereby preventing false DMARC negatives.

What happens if an intermediary doesn't have ARC DNS records?

If an intermediary acts as an ARC sealer but doesn't have correctly configured ARC DNS records, receiving mail servers will be unable to verify the ARC seals. This means the ARC chain will be broken, and the benefits of ARC will be lost. Emails might then be subjected to standard DMARC checks, which could lead to them failing authentication and potentially being marked as spam.

Does ARC require a DNS record for setup? - ARC - Email authentication - Knowledge base

An illustration of email authentication, showing an envelope with authentication symbols and a chain, representing ARC.

When delving into email authentication protocols, it's common to wonder about the underlying requirements. Specifically, for Authenticated Received Chain (ARC), a frequent question arises: does ARC require its own DNS record for proper setup and operation? The answer is nuanced, as ARC functions as an enhancement to existing authentication methods rather than a standalone protocol that requires a completely new set of DNS records in the same way SPF or DKIM do for initial domain authorization.

ARC's primary role is to preserve authentication results through intermediaries, such as mailing lists and forwarders. Without ARC, valid emails can often fail SPF and DKIM checks after being altered or re-sent by these intermediaries, leading to them being marked as spam or rejected. This is where ARC steps in, providing a verifiable chain of custody for email authentication states.

Understanding ARC's relationship with DNS is crucial for anyone managing email deliverability and security. While it doesn't always mandate entirely new, distinct DNS record types for every domain in the same manner as SPF or DKIM, it certainly relies heavily on DNS for its cryptographic sealing mechanism. Let's explore how ARC leverages DNS and what's involved in its implementation.

Understanding the role of ARC

The purpose of ARC in email authentication

ARC, or Authenticated Received Chain, acts as a stamp of authenticity for email, specifically designed to bridge the gap in email authentication when messages pass through legitimate intermediaries. When an email is forwarded or sent via a mailing list, its headers can be modified, often breaking the original SPF and DKIM signatures. This can incorrectly flag a legitimate email as fraudulent. As we've explored, ARC re-authenticates an email by adding a new set of headers that attest to the email's authentication status at each hop.

These headers form a chain, where each participating server (or 'sealer') adds its own 'ARC-Seal' and 'ARC-Message-Signature' headers, along with an 'ARC-Authentication-Results' header summarizing the results of the authentication checks it performed. This cryptographic chain allows the final receiving mail server to verify the authenticity of the message as it existed before the last hop, even if the SPF or DKIM checks would otherwise fail due to intermediate modifications. This helps prevent legitimate emails from being incorrectly quarantined or rejected.

ARC does not replace DMARC or SPF/DKIM

It's important to clarify that ARC does not replace DMARC, SPF, or DKIM. Instead, it complements them. ARC builds upon these foundational authentication protocols, providing a mechanism for trusted intermediaries to pass along authentication results without invalidating the sender's original policy. This makes it a crucial component for ensuring consistent email deliverability in complex sending environments, especially where emails are frequently forwarded or sent through mailing lists.

Essentially, ARC ensures that the email's journey from the original sender to the final recipient remains transparent and verifiable, even through multiple hops. This transparency is key for DMARC, as it allows DMARC policies to be applied correctly even after legitimate forwarding, preventing false negatives. A simple guide to DMARC, SPF, and DKIM provides more context on these core protocols.

ARC-Set DNS TXT records

How ARC utilizes DNS records

While ARC itself doesn't introduce a new, primary DNS record type that every sender needs to configure directly on their main domain, it does rely on DNS for its cryptographic validation process. Specifically, an ARC 'sealer' (an intermediary server that adds ARC headers) needs to publish an ARC-Set DNS TXT record. This record contains the public key used to verify the ARC-Seal header, much like a DKIM record contains a public key for verifying DKIM signatures. You can review specific documentation on enabling ARC signing.

Traditional SPF/DKIM validation

Direct validation: Receiving server checks SPF and DKIM directly against the sending domain's DNS records.
Fragile with intermediaries: Forwarding or mailing list modifications often break existing authentication.

ARC-enhanced validation

Chain of trust: Intermediaries add cryptographic 'seals' and authentication results. ARC uses DNS queries for validation.
Preserves authentication: Allows receiving servers to validate the original sender's authentication status.

The ARC-Set record is a TXT record typically located at a specific subdomain, such as arc._domainkey.yourdomain.com. This record contains parameters like the public key and the ARC version. When a receiving server encounters an ARC-sealed message, it looks up this DNS record for the domain specified in the ARC-Seal to verify the signature. This is similar to how DKIM selectors work, where the selector points to the specific DNS TXT record containing the public key.

Example ARC-Set DNS TXT recordDNS

arc._domainkey.example.com. IN TXT "v=ARC1; s=arc-selector; d=example.com; c=relaxed/simple; i=1; a=rsa-sha256; h=from:to:subject:date; bh=; b=..."

ARC setup for intermediaries

Configuring ARC for trusted intermediaries

For email service providers or mail servers acting as intermediaries (e.g., mailing list servers, forwarders), configuring ARC involves generating cryptographic keys and publishing the corresponding public key in a DNS TXT record, as mentioned. This record signals to other mail servers that this intermediary is a trusted ARC sealer. Without this DNS record, other servers would not be able to verify the ARC signatures applied by the intermediary, rendering the ARC chain invalid.

Therefore, while end-senders typically don't directly manage ARC DNS records (they set up SPF, DKIM, and DMARC), any entity that legitimately modifies or forwards emails and wants to maintain authentication integrity needs to implement ARC, which includes setting up these specific DNS records and cryptographic keys. This is why it's crucial to ensure that any mail infrastructure you use, especially if it involves forwarding, supports and correctly implements ARC. cPanel, for instance, offers experimental ARC support, indicating its growing importance.

An illustration depicting the interconnected network of DNS servers and email systems that ARC relies on for authentication.

Component	Description	Purpose
Selector	Often 'arc' or similar, identifies the specific ARC record.	Points to the correct public key in DNS.
Domain	The intermediary's domain that is sealing the message.	Used by receivers to look up the ARC-Set record.
Public Key	Contained within the TXT record, used for cryptographic verification.	Validates the ARC-Seal header's signature.

The accurate configuration of these DNS records for ARC is vital for intermediaries. If the records are incorrectly published or missing, mail servers trying to validate the ARC chain will fail to retrieve the public key, thus nullifying ARC's benefits and potentially impacting the deliverability of otherwise legitimate emails. This highlights the ongoing importance of proper DNS record management for email.

ARC, DMARC, and email deliverability

The broader impact on DMARC and deliverability

Ultimately, the DNS records required for ARC are part of a larger ecosystem designed to bolster email security and deliverability. By providing a trusted means for intermediaries to forward authentication results, ARC helps DMARC policies function as intended, even for emails that undergo legitimate modifications. This is especially important for domains with a strong DMARC policy in place, ensuring that their legitimate emails aren't penalized.

For email senders, while you might not directly configure ARC DNS records, it's beneficial to be aware of ARC's role and ensure that any third-party services you use (ESPs, marketing automation platforms, etc.) support it. Proper ARC implementation by intermediaries contributes to a healthier email ecosystem, reducing the likelihood of your emails ending up in the spam folder due to forwarding issues. This proactive approach helps boost email deliverability rates.

Monitoring DMARC with Suped

AI-powered recommendations: Suped doesn’t just show data; it provides actionable steps to fix issues and strengthen your DMARC policy.
Unified platform: Consolidate DMARC, SPF, DKIM monitoring, plus SPF flattening and deliverability insights into one interface.
Real-time alerts: Get instant notifications for authentication failures or potential threats.
Free plan: Suped offers a generous free plan, making DMARC accessible to everyone.
MSP and multi-tenancy dashboard: Ideal for managing multiple domains from a single, intuitive interface. Start your DMARC monitoring journey today.

Implementing a robust email authentication strategy requires a comprehensive approach. While ARC specifically addresses the challenge of authentication through intermediaries, it works hand-in-hand with SPF, DKIM, and DMARC to ensure your emails are delivered securely and reliably. Tools like Suped provide DMARC monitoring and insights, helping you navigate these complexities and optimize your email deliverability.

Summary

In conclusion, ARC does require DNS records, specifically ARC-Set TXT records, but these are primarily configured by email intermediaries (sealers) rather than every individual sender. These records are crucial for the cryptographic sealing and verification process that allows ARC to maintain email authentication integrity across multiple hops. Understanding this distinction is key to comprehending ARC's role in the broader email security landscape.