This blog post explains the role and benefits of ARC sealing.
ARC (Authenticated Received Chain) is an email authentication protocol that preserves the authentication results of an email as it travels through multiple intermediaries, such as forwarding services.
Using ARC helps organizations handle the complexities of email authentication, especially when emails are forwarded. ARC involves multiple servers working together based on mutual trust.
ARC ensures that legitimate emails are less likely to be marked as spam or rejected, while fraudulent emails are more easily identified and filtered out. In this blog post, we will explore the basics of ARC, how it works, and the benefits it provides.
How ARC works
ARC (Authenticated Received Chain) sealing is a way to help ensure the authenticity of email messages as they pass through various email servers.
When you send an email message, it goes through your sending server and may be routed through an intermediate server (mailing lists or account forwarding services) before it reaches the receiving server. However, some legitimate mail services may modify messages before they’re delivered to the receiving server. Modifying incoming messages in transit can, and likely will, cause the following email authentication failures:
- SPF fails because of the new message source (IP address)
- SPF checks email messages against an authorized list of IP addresses. When email is forwarded, it passes through an intermediate server whose IP may not be on the sender’s SPF list. This results in unwanted SPF failures, even for legitimate email.
- DKIM fails because of content modification
- DKIM adds digital signatures to your emails that are encrypted using a private key from the sending server and can be verified using a public key published in DNS. If the email is modified during forwarding, such as by adding footers or changing headers, the DKIM signature may no longer match, causing verification to fail.
- DMARC fails because of the SPF and DKIM failures
- DMARC assumes that emails are completely unchanged throughout the delivery process.
Want to learn more about SPF, DKIM, and DMARC? You can read my previous blog post about these outbound authentication protocols.
ARC Headers
ARC helps preserve email authentication results and verifies the identity of intermediate server(s) that forward a message on to its final destination.
There are three key components to ARC:
- The
ARC-Authentication-Results
header: A header containing email authentication results like SPF, DKIM, and DMARC. - The
ARC-Message-Signature
header: This header takes a snapshot of the message header information, including To, From, Subject, and Body. - The
ARC-Seal
header: This header includes theARC-Message-Signature
andARC-Authentication-Results
header information and contains a tag called chain validationcv=
, which contains the result of the evaluation of the existing ARC chain. The value can benone
,fail
orpass
:none
: No ARC chain to validatefail
: ARC chain validation failedpass
: ARC chain validation succeeded
Each ARC header includes an i=
tag, which stands for ARC instance. This number indicates the position of the system in the forwarding chain and helps establish the order of trust.
For example:
i=1
is added by the first intermediary (e.g., the first system that receives and forwards the original message).i=2
is added by the next hop, which receives the message from the first forwarder and re-validates the earlier authentication results.i=3
and higher are added by subsequent intermediaries or the final destination mail server.
Each ARC instance adds its own set of headers:
ARC-Authentication-Results
(its own assessment of SPF, DKIM, DMARC, and possibly ARC).ARC-Message-Signature
(to cryptographically bind the message content and headers).ARC-Seal
(to seal the entire ARC package and validate the prior chain).
This system creates a verifiable chain of custody that helps the final recipient determine whether the authentication results can still be trusted, even if the message was forwarded or altered en route.
The ARC trust chain
When emails pass through multiple intermediaries, traditional authentication methods like SPF and DKIM can fail. That’s where ARC comes in, preserving the original authentication results across each hop. Below is an example of how ARC headers build up through multiple relays, including SendGrid, a security gateway, and finally Microsoft 365.
✉️ Message Flow
- Original Sender:
shaggy@vand3rlinden.com
(sent from a DMARC-compliant mail server forvand3rlinden.com
) - Hop 1: SendGrid (SMTP relay service acting as the intermediate server for
vand3rlinden.com
) - Hop 2: Security Gateway (e.g., Proofpoint)
- Final Recipient: Microsoft 365 user
📜 ARC Header Chain Example
✅ ARC Instance 1 (Added by SendGrid)
ARC-Authentication-Results: i=1; d=sendgrid.net;
spf=pass smtp.mailfrom=vand3rlinden.com;
dkim=pass header.d=vand3rlinden.com;
dmarc=pass header.from=vand3rlinden.com;
ARC-Message-Signature: i=1; a=rsa-sha256; d=sendgrid.net;
s=arc; h=from:to:subject:date;
bh=[body-hash]; b=[signature]
ARC-Seal: i=1; a=rsa-sha256; d=sendgrid.net; s=arc;
t=[timestamp]; cv=none; b=[seal-signature]
✅ ARC Instance 2 (Added by Security Gateway, e.g., Proofpoint)
ARC-Authentication-Results: i=2; d=securitygateway.com;
spf=pass; dkim=pass; dmarc=pass;
ARC-Message-Signature: i=2; a=rsa-sha256; d=securitygateway.com;
s=arc; h=from:to:subject:date;
bh=[body-hash]; b=[signature]
ARC-Seal: i=2; a=rsa-sha256; d=securitygateway.com; s=arc;
t=[timestamp]; cv=pass; b=[seal-signature]
✅ ARC Instance 3 (Added by Microsoft 365)
ARC-Authentication-Results: i=3; d=microsoft.com;
spf=pass; dkim=pass; dmarc=pass;
ARC-Message-Signature: i=3; a=rsa-sha256; d=microsoft.com;
s=arc; h=from:to:subject:date;
bh=[body-hash]; b=[signature]
ARC-Seal: i=3; a=rsa-sha256; d=microsoft.com; s=arc;
t=[timestamp]; cv=pass; b=[seal-signature]
Each instance (i=1
, i=2
, i=3
) seals the authentication results of the previous hop. By the time it reaches Microsoft 365 (i=3
), the entire trust chain can be evaluated, even if the original SPF or DKIM fails due to forwarding. This is the core benefit of ARC, preserving authentication integrity across multiple hops.
Mailbox providers that support ARC Sealers
ARC has already been adopted by major mailbox providers such as Google and Microsoft, and is likely to become a global standard.
Set ARC seals on your intermediate server
The commercial MTAs Halon and MailerQ include ARC sealing. For open source solutions, authentication_milter or OpenARC can be used to implement ARC with the Postfix, Oracle Communications Messaging Server, and Sendmail MTAs.
Accept trusted ARC sealers on your receiving server
An intermediate server’s ARC seal can be accepted by an administrator within their mailbox provider (receiving server). To do this, you need to add the trusted signing domain. This domain must match the domain that’s shown in the d
value in the ARC-Seal
and ARC-Message-Signature
headers in affected messages.
The steps to accept an ARC seal depend on your mailbox provider; for Microsoft 365, you can use this documentation.
To summarize
ARC ensures that email authentication results are preserved as messages pass through multiple hops, such as forwarding services and other intermediate services. The success of ARC really depends on email receivers trusting each other by applying the protocol.