Who owns the private key used for ARC signing?

The private key used for ARC signing is owned and managed by the ARC-Sealer, which is typically an intermediate mail server or a mailing list service, not the original sending domain. Each ARC-Sealer along the chain uses its own key pair to sign its respective ARC-Seal.

How does ARC validation use public keys?

Recipient mail servers validate the ARC chain by retrieving the public key from the ARC-Sealer's DNS records. This public key is then used to decrypt the ARC-Seal and verify the integrity of the chain of authentication results . A valid signature confirms that the message has not been tampered with since that ARC-Sealer processed it.

Is the private key for ARC the same as for DKIM?

No, the private key for ARC is not the same as for DKIM. DKIM uses a private key owned by the original sending domain to sign the email. ARC uses separate private keys owned by each intermediate ARC-Sealer to sign the authentication results at their specific point in the email's journey.

Does ARC require a private key for signing? - ARC - Email authentication - Knowledge base

Q: What is the primary function of a private key in ARC?

In ARC, a private key is used by an ARC-Sealer (an intermediate mail server or forwarding service) to create an ARC-Seal . This cryptographic signature verifies the message's authentication state at that specific point in its journey, ensuring integrity as it travels through different hops. The corresponding public key is published in DNS for validation.

A hand holding a key, surrounded by digital security icons, illustrating the concept of private key usage in email authentication.

The Authenticated Received Chain (ARC) is a crucial email authentication protocol designed to preserve the authentication results of a message as it traverses multiple intermediate mail servers. Its primary purpose is to help recipient mail servers, especially those implementing DMARC policies, trust email that might otherwise fail authentication due to legitimate changes made by forwarding services or mailing lists.

The question of whether ARC requires a private key for signing is often raised because of its close relationship with DKIM (DomainKeys Identified Mail). While ARC leverages similar cryptographic principles to maintain message integrity, its role and the specific use of private keys differ from how DKIM utilizes them.

Ultimately, yes, ARC does involve the use of private keys, but it is important to understand in what context. An ARC-Sealer, typically an intermediate mail server or a mailing list, uses its own private key to create an ARC-Seal. This seal verifies the message's authentication state at that specific point in its journey, ensuring that any subsequent server can validate the chain of authentications.

The role of keys in ARC signing

ARC itself does not introduce a new domain-specific authentication mechanism that requires the original sender to generate and manage a new private key. Instead, ARC acts as an authentication wrapper for existing protocols like SPF and DKIM. When an email passes through an intermediate server that is an ARC-Sealer (such as a mailing list or a forwarding service), this server assesses the email's current authentication status.

The ARC-Sealer then creates an ARC-Seal, which is a cryptographic signature over the message's current state, including the original authentication results and specific header fields. This signature is generated using a private key controlled by the ARC-Sealer's domain. The corresponding public key is published in the ARC-Sealer's DNS records, allowing subsequent recipient servers to verify the integrity of the ARC chain. You can learn more about how ARC functions by reading about the ARC 'chain' concept.

The critical element here is the ARC-Message-Signature header. This header contains the digital signature created by the ARC-Sealer. Much like DKIM, it includes tags such as s= (selector) and d= (signing domain) to indicate where the public key can be found. This specific use of cryptographic keys allows ARC to provide tamper-proof assurance of an email's authentication history.

A key component of ARC is the ARC-Authentication-Results header. This header captures a snapshot of the email's authentication status (SPF, DKIM, DMARC) at the moment it was processed by the ARC-Sealer. This information is critical for downstream receivers to determine if the email's authentication failures are due to legitimate transit modifications or malicious activity.

How ARC signatures are generated and validated

When an email passes through an ARC-enabled intermediary, the intermediary acts as an ARC-Sealer. It generates an ARC-Seal by taking a cryptographic hash of relevant email headers and the message body, along with the current authentication results. This hash is then encrypted with the ARC-Sealer's private key. The resulting signature is placed into the ARC-Message-Signature header.

Upon receiving an email with an ARC chain, the final recipient server performs a validation process. It retrieves the ARC-Sealer's public key from DNS records by querying ARC DNS records. This public key is then used to decrypt the ARC-Seal and verify the message's integrity. If the signature is valid, it confirms that the message's headers and body, as well as the authentication results, have not been tampered with since they were last sealed. This ensures that the message hasn't been altered after signing.

Stylized gears labeled DKIM and ARC, illustrating their interconnected functionality in email authentication with a digital signature.

The private key, in this context, is vital for establishing trust in the ARC chain. Without it, any intermediary could claim to be an ARC-Sealer and forge authentication results, undermining the entire purpose of ARC. The cryptographic signing process ensures that only authorized entities (those possessing the private key) can create a valid ARC-Seal for their domain, thereby preserving email sender authenticity.

Distinguishing ARC from DKIM and DMARC

DKIM key usage

Primary purpose: Ensures the original sender's domain authorized the email and that content hasn't changed in transit.
Key ownership: The sending domain owns and manages the private key for signing outbound emails.
Signature scope: Applies to the original message directly from the source.

ARC key usage

Primary purpose: Preserves the email's authentication results across intermediaries. ARC re-authenticates an email indirectly.
Key ownership: Each ARC-Sealer (intermediate server) generates and manages its own private key.
Signature scope: Applies to the authentication state as the message passes through a specific relay.

While DKIM uses private keys for the initial sender authentication, ARC uses private keys at each hop in the mail delivery chain where an ARC-Sealer is present. This is crucial because ARC does not replace SPF or DKIM. Instead, it provides a trusted chain of custody for their results. You can read more about this relationship in the article Does ARC replace DMARC or SPF/DKIM?.

DMARC, in turn, relies on SPF and DKIM authentication to make policy decisions. When an email fails DMARC due to legitimate forwarding, ARC provides the necessary context for the recipient server to override a quarantine or reject policy, helping to prevent email spoofing while allowing legitimate mail to pass.

Monitoring ARC and email authentication

Understanding ARC and its reliance on private keys at each sealing point is crucial for maintaining robust email deliverability. For organizations implementing DMARC, monitoring ARC results provides valuable insights into how legitimate forwarded emails are being handled. While you don't manage the ARC-Sealer's private key directly, ensuring your DMARC reports show a healthy ARC chain is important for deliverability.

Properly configured email authentication, including SPF, DKIM, and DMARC, is the foundation for email security and deliverability. Tools like Suped provide DMARC monitoring and reporting capabilities that can help you understand your ARC compliance, identify issues, and receive actionable recommendations. Our platform helps unify DMARC, SPF, and DKIM monitoring, offering real-time alerts and AI-powered recommendations to strengthen your email policies. This is particularly beneficial for MSPs and businesses managing multiple domains.

ARC's clever use of cryptographic signatures allows it to act as a bridge of trust for forwarded email, ensuring that legitimate messages reach their intended recipients without being flagged as spam or phishing attempts. By understanding the role of private keys in this process, you can better appreciate the complex mechanisms that safeguard email communication today. For more details on ARC signing, refer to the TitanHQ documentation on ARC signing or Sympa's guide on DKIM and ARC key pair setup.