What is the primary function of the ARC 's=' tag?

The primary function of the ARC s= tag is to specify the ARC selector. This selector is part of the domain name used to query DNS for the public key required to verify the ARC-Message-Signature .

How does the ARC 's=' tag relate to DKIM?

The ARC s= tag is analogous to the DKIM 's=' tag . Both tags specify a selector that points to a public key in DNS, allowing for the verification of a cryptographic signature.

What happens if the 's=' tag is missing or incorrect in an ARC-Message-Signature?

If the s= tag is missing or points to an invalid DNS record, the receiving server will be unable to retrieve the correct public key. This will cause the ARC signature verification to fail, potentially leading to the email being flagged as suspicious or blocked, negatively impacting deliverability.

Can different intermediaries use different 's=' tags?

Yes, each intermediary (ARC sealer) in the email's forwarding path will typically use its own unique s= tag and signing domain. This allows the receiving server to verify each step in the chain of custody independently, ensuring the integrity of the message at every hop.

What is the 's=' tag in an ARC-Message-Signature header? - ARC - Email authentication - Knowledge base

An abstract illustration showing email messages being signed as they pass between servers, representing the Authenticated Received Chain.

Email forwarding, mailing lists, and other legitimate intermediaries can often break standard email authentication protocols like SPF and DKIM. This happens because these services might alter parts of an email, such as the 'From' address or message body, which invalidates existing signatures.

This is where the Authenticated Received Chain (ARC) comes into play. ARC acts as a 'chain of custody', providing a way for intermediaries to vouch for the authenticity of an email as it passes through their systems, even if the message undergoes modifications.

Within the ARC framework, the ARC-Message-Signature header contains several important tags. One critical tag is s=, which identifies the signing domain or the entity that generated the ARC signature for that specific hop in the email's journey.

The authenticated received chain (ARC) and message integrity

The Authenticated Received Chain (ARC) is a protocol designed to preserve email authentication results through intermediate mail servers and mailing lists. It creates a verifiable chain of custody, ensuring that DMARC authentication can still pass even after legitimate modifications by intermediaries. This is formally defined in RFC 8617, a key standard in email security.

The ARC-Message-Signature header (AMS) is the core of ARC. It contains a cryptographic signature of the entire email message, including the message headers and body, as they appeared when the ARC signer processed the message. This signature is similar in concept to a DKIM signature, but it applies to the message's state at each hop.

Beyond the s= tag, other important tags within the AMS header include bh= (body hash), h= (signed headers), b= (signature data), and c= (canonicalization algorithms). These work together to ensure the integrity of the signed message.

How ARC protects email authentication

When an email passes through an intermediary like a mailing list or a forwarding service, legitimate changes can occur, such as adding a footer or modifying the subject line. These changes often cause SPF or DKIM to fail, which can lead to DMARC failures and messages being sent to spam or blocked entirely. ARC provides a solution by:

Maintaining context: It carries forward the original authentication results in a verifiable way.
Cryptographic sealing: Each intermediary adds an ARC seal, including a signature, to confirm that it has not introduced any malicious alterations.
Recipient verification: The final recipient can validate the chain of ARC seals to determine if the message truly originated from the initial sender, despite intermediate changes.

Unpacking the 's=' tag

The s= tag within an ARC-Message-Signature header identifies the ARC selector for that particular ARC signature. Think of it as a pointer to the specific DNS record where the public key needed to verify the ARC signature is published. Each intermediary that applies an ARC seal (a signature) will use its own unique selector.

This functionality is quite similar to the s= tag found in DKIM signatures, which points to the DKIM selector. Just as with DKIM, the selector helps ensure that multiple entities can sign mail from the same domain without interfering with each other's keys.

When a receiving mail server processes an email with ARC headers, it uses the s= tag, along with the d= tag (signing domain), to locate the correct public key in the DNS. This key is then used to decrypt and verify the ARC signature, confirming that the message content has not been tampered with since that particular ARC signer handled it.

Example ARC-Message-Signature headeremail-header

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=example.org; s=arcselector; t=1678886400;
bh=2jmj7l5rSw0yJb/QytTsKt/axgJ6/M/S/V2jQc5w9A=;
h=From:Subject:Date:To:Message-ID:Content-Type:MIME-Version;
b=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/ABCDEF
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/ABCDEF
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/ABCDEF
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/ABCDEF

In the example above, s=arcselector indicates that the public key for verifying this ARC signature would be found in a DNS record named arcselector._arc.example.org.

A hand using a magnifying glass to inspect a digital signature, highlighting the process of verification.

Why the 's=' tag matters for email deliverability

The s= tag, in conjunction with other ARC components, is crucial for maintaining email deliverability, especially when emails pass through legitimate forwarding paths. Without ARC, DMARC validation would frequently fail for forwarded messages, causing them to be treated as suspicious.

Mailbox providers, like Microsoft, increasingly rely on ARC to make informed delivery decisions. If a message comes from a trusted ARC sealer, its original DMARC authentication results can be re-evaluated, potentially preventing it from being incorrectly flagged as spam or phishing. This is particularly important for domains enforcing a strict DMARC policy like p=quarantine or p=reject.

To effectively manage and monitor ARC, DMARC, SPF, and DKIM, platforms like Suped provide comprehensive DMARC monitoring and reporting solutions. Our AI-powered recommendations help you fix issues and strengthen your email authentication policies, ensuring your legitimate emails reach the inbox consistently.

Email forwarding without ARC

Authentication breaks: SPF and DKIM often fail due to message alterations by intermediaries.
DMARC failure risk: Messages frequently fail DMARC checks at the receiving end, leading to non-delivery.
Reduced deliverability: Higher chance of emails landing in spam folders or being blocked, especially with strict DMARC policies.
Brand impact: Senders lose control over their brand's email reputation when authentication fails.

Email forwarding with ARC

Authentication preserved: ARC provides a chain of verified authentication results despite message changes.
DMARC resilience: Legitimate forwarded messages can pass DMARC, reducing false positives.
Improved deliverability: Senders maintain higher inbox placement rates for their forwarded emails.
Enhanced trust: Recipients can trust the authenticity of emails, even when forwarded.

Maintaining trust in email forwarding

Ultimately, the s= tag in an ARC-Message-Signature header is a vital component in preserving trust and ensuring deliverability across the complex landscape of email forwarding. It provides a clear, verifiable link to the entity responsible for that particular step in the email's journey.

By correctly identifying the ARC selector, receiving mail servers can confidently validate the cryptographic chain, allowing DMARC to pass for messages that might otherwise fail due to legitimate modifications. This mechanism is especially important for organizations that send emails through mailing lists or rely on forwarding services.

Implementing and monitoring ARC ensures that your email authentication remains robust, protecting your domain's reputation and ensuring your messages reach their intended recipients without being caught in spam filters or blocked.