Understanding How ARC (Authenticated Received Chain) Ensures Email Authentication Through Forwarding
Overview
ARC (Authenticated Received Chain) is an email authentication system designed to address issues that arise when email is forwarded. While SPF and DKIM validate the origin of an email, forwarding can break these authentication mechanisms, causing the email to fail checks when it reaches the final destination. ARC provides a solution by allowing each entity that handles the email (such as forwarders) to preserve the authentication results from earlier checks. This ensures that the final recipient can trace and verify the original authentication status of the message.
Workflow
- Sending System: The original sender sends an email that undergoes standard email authentication checks like SPF, DKIM, or DMARC.
- Forwarding System: When the message passes through an intermediate mail server (e.g., a mailing list or forwarder), this system may break SPF/DKIM validation by modifying headers or changing the IP address.
- The forwarding system applies ARC headers, which contain a signed record of the authentication results from the previous mail server.
- Final Recipient's Mail Server:
- When the message reaches its final destination, the recipient's mail server can verify the ARC chain, which contains the results of earlier SPF/DKIM checks, even if the forwarding process would have otherwise caused them to fail.
- This allows the recipient's mail server to make an informed decision based on the complete history of the email's authentication.
Pros
- Preserves Authentication: ARC allows authentication results to be preserved when an email is forwarded, preventing the message from failing SPF or DKIM checks due to legitimate forwarding.
- Improves DMARC Reporting: ARC works in tandem with DMARC to ensure that forwarded messages maintain their authenticity, enhancing DMARC's effectiveness.
- Email Traceability: By including a chain of authenticated entities, ARC provides transparency about the path the email took, helping the final recipient trust or reject the message based on a full record of its journey.
Cons
- Complexity: ARC introduces additional complexity in the email authentication process. It requires all intermediate servers to properly implement ARC for it to function effectively.
- Limited Adoption: Although ARC solves forwarding issues, it is not yet widely adopted across all email service providers, meaning it might not always be effective.
- Trusting Intermediate Servers: ARC requires that recipients trust the integrity of intermediate servers. If a malicious server in the chain modifies the ARC headers, the entire chain could be compromised.
Details
ARC Headers
ARC works by adding three new headers to the email at each hop (forwarding server). These headers are signed and must be validated by the next hop and the final recipient.
ARC-Authentication-Results (AAR)
This header records the results of the email authentication checks (such as SPF, DKIM, and DMARC) as performed by the intermediate mail server.
Example:
ARC-Authentication-Results: i=1; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com
| Field | Description |
|---|---|
i= | The "instance" number, which represents the number of hops the email has gone through. Each forwarding system increments this value. |
spf= | The result of the SPF check (e.g., pass, fail, neutral). |
dkim= | The result of the DKIM check (e.g., pass, fail, none). |
header.d= | The domain name used in the DKIM signature. |
ARC-Message-Signature (AMS)
The ARC-Message-Signature header contains a cryptographic signature of the message, which allows the recipient to verify that the email was not altered between hops.
Example:
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; s=arcselector; bh=Y9PmG9RRk67sd9ZJ5sdXfX6uMSdshe5hTr==; b=Y5Usduf9sdsfoN9SdoffGtdfuh9asdfa+==
| Field | Description |
|---|---|
i= | The instance number. It must match the instance in the other ARC headers. |
a= | The algorithm used for the digital signature (e.g., rsa-sha256). |
d= | The domain name of the forwarding entity that signs the message. |
s= | The selector used to identify the signing key in the DNS. |
bh= | The hash of the canonicalized body. |
b= | The actual cryptographic signature of the message. |
ARC-Seal (AS)
The ARC-Seal header contains a cryptographic signature that ensures the integrity of the ARC headers added by each server. It acts as a seal that covers the entire ARC chain, preventing unauthorized modifications to the headers.
Example:
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=arcselector; t=1613144111; cv=pass; b=Q9GsfT9f8PsffTFsf8hsfnsf8aTT==
| Field | Description |
|---|---|
i= | The instance number, matching the instance in the other ARC headers. |
a= | The algorithm used for the seal (e.g., rsa-sha256). |
d= | The domain of the forwarding system signing the seal. |
s= | The selector identifying the signing key in the DNS. |
t= | The timestamp indicating when the seal was created. |
cv= | The result of validating the previous ARC chain (pass, fail). |
b= | The cryptographic signature of the seal, covering the ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal from the previous instance. |
Example of ARC Headers
When an email is forwarded, ARC headers are added by each forwarding entity. Here's an example of how ARC headers might look after an email has been forwarded twice:
First Forwarder:
ARC-Authentication-Results: i=1; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder1.com; s=selector1; bh=abc123; b=signature1
ARC-Seal: i=1; a=rsa-sha256; d=forwarder1.com; s=selector1; t=1613144111; cv=none; b=seal1
Second Forwarder:
ARC-Authentication-Results: i=2; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com
ARC-Message-Signature: i=2; a=rsa-sha256; d=forwarder2.com; s=selector2; bh=def456; b=signature2
ARC-Seal: i=2; a=rsa-sha256; d=forwarder2.com; s=selector2; t=1613144211; cv=pass; b=seal2
How ARC Works with SPF, DKIM, and DMARC
ARC does not replace SPF, DKIM, or DMARC; instead, it complements them. ARC provides a mechanism to preserve authentication results as an email passes through multiple servers, which can be helpful when DMARC would otherwise fail due to changes made by intermediate servers.
- SPF: ARC ensures that SPF results are passed along, even if the forwarding server changes the IP address or SMTP envelope, which would otherwise cause SPF to fail.
- DKIM: ARC preserves DKIM signatures, even if the email is modified in transit.
- DMARC: ARC works with DMARC to ensure that legitimate forwarded messages aren't rejected due to SPF or DKIM failures, maintaining the trust chain.