What is the 'bh=' tag in an ARC-Message-Signature header?
Matthew Whittaker
Co-founder & CTO, Suped
Published 12 Mar 2025
Updated 26 Sep 2025
8 min read
The Authenticated Received Chain (ARC) protocol adds a crucial layer of trust to email authentication, particularly for messages that are forwarded. When an email passes through various mail servers or mailing lists, the original DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) authentication can often break. ARC addresses this by providing a verifiable chain of authentication results, ensuring that legitimate emails are not mistakenly marked as spam after being forwarded.
A key component of ARC is the ARC-Message-Signature header. This header contains a cryptographic signature of the email message at a specific point in its journey, ensuring its integrity as it moves from one server to another. Within this signature, various tags provide details about how the signature was generated and what it covers. One tag that often causes confusion is the bh= tag, which relates to the body hash.
Understanding what the bh= tag signifies and how it functions within the ARC-Message-Signature is key to grasping the full scope of ARC's email integrity protection. It helps verify that the email's content has not been altered by intermediaries, which is fundamental for maintaining trust in forwarded messages.
Understanding ARC-Message-Signature
Understanding ARC-Message-Signature
The ARC-Message-Signature (AMS) header is a critical part of the ARC protocol. Its primary role is to capture the state of a message's authentication results at each hop, or intermediary mail server, as it travels from sender to recipient. This signature helps to validate the integrity of the email, ensuring that the message content and critical headers haven't been tampered with by a forwarding server.
Unlike traditional DKIM signatures, which might only cover specific parts of the header and body, the ARC-Message-Signature aims to provide a comprehensive cryptographic checksum of the entire message as it passes through forwarding mail servers. This ensures that even if an email is forwarded multiple times, the original authentication results can be verified, preventing legitimate emails from failing DMARC due to benign modifications by intermediaries.
Key tags within the ARC-Message-Signature header include v= (version), a= (algorithm), i= (instance), s= (selector), b= (signature), and bh= (body hash). Each of these plays a vital role in constructing and validating the signature. For example, the s= tag identifies the specific DKIM key used for signing, similar to a DKIM signature. The c= tag also specifies canonicalization algorithms for headers and body.
When an email passes through a mail gateway that implements ARC, the gateway appends a new set of ARC headers. This includes an ARC-Authentication-Results header that summarizes the authentication results at that point, an ARC-Seal header which signs previous ARC headers, and the ARC-Message-Signature header, which signs the message itself. This chain allows receiving mail servers to trust the authentication results even if the original SPF or DKIM alignment breaks due to forwarding.
The 'bh=' tag's specific function
The 'bh=' tag's specific function
The bh= tag in an ARC-Message-Signature header is designed to hold a hash of the canonicalized message body. This body hash is a crucial component of the ARC system, as it provides a way to verify that the message body has not been altered during transit. While some RFCs, like RFC 8617, might state that the AMS header field does not *directly* cover the body of the message, the bh= tag serves as an essential reference point.
When an intermediary mail server processes an email and creates a new ARC set, it calculates a hash of the current message body and places it in the bh= tag. This hash is then used as part of the overall ARC-Message-Signature (b= tag) calculation. This ensures that any subsequent mail server can compare the body hash in the received ARC-Message-Signature with a newly calculated hash of the message body. If they match, it confirms the body's integrity at that specific hop.
It is important to distinguish this from the body hash in a standard DKIM signature. While both serve to verify the integrity of the message body, the context and calculation within ARC are specific to its chain-of-custody model. If you're encountering issues with the body hash, understanding what DKIM tag specifies the body hash and how to fix DKIM body hash mismatch failures can provide valuable context, even though ARC has its own distinct handling.
The bh= tag plays a crucial role in maintaining trust. Without it, a malicious actor could potentially alter the email body during forwarding, and the recipient mail server would have no way to detect the tampering while still validating the ARC chain. It's a key mechanism for ensuring the message's content fidelity as it passes through various mail transfer agents.
How 'bh=' protects email integrity through forwarding
How 'bh=' protects email integrity through forwarding
The primary benefit of the bh= tag, alongside the entire ARC protocol, lies in its ability to preserve email authentication results across forwarding services. Email forwarding often breaks traditional SPF and DKIM authentication. SPF can fail if the forwarding server's IP address isn't listed in the original sender's SPF record, and DKIM can fail if the forwarding server modifies the message in any way that invalidates the signature, such as adding a footer.
When an email is forwarded, the forwarding mail server adds a new ARC set, including a fresh ARC-Message-Signature with a new bh= value. This new signature effectively 'seals' the previous authentication results and the message state. The receiving mail server can then look at the entire ARC chain. Even if SPF or DKIM fail on the final hop, the ARC chain provides verifiable proof that the email was authenticated by the original sender and passed through trusted intermediaries without unauthorized modifications.
Without ARC's 'bh='
Vulnerability to tampering: Malicious alterations to the email body during forwarding go undetected.
Increased spam likelihood: Legitimate forwarded emails are more likely to be flagged as spam.
Broken authentication: SPF and DKIM authentication frequently fail for forwarded messages.
With ARC's 'bh='
Body integrity verification: Ensures the email body remains unchanged through intermediaries.
Improved deliverability: Reduces false positives for legitimate forwarded emails.
Maintained authentication chain: Provides a verifiable trust chain for SPF and DKIM results.
This mechanism is particularly important for services that frequently forward emails, like mailing lists or personal email forwarders. Without ARC, these legitimate emails would frequently end up in spam folders because their authentication status would appear invalid. As Proton Mail explains, ARC helps improve how DKIM and SPF results are passed from one mail server to the next. The bh= tag contributes directly to this by ensuring that the body of the message remains consistent and verifiable throughout its journey, enhancing overall email deliverability.
Ensuring consistent email authentication
Ensuring consistent email authentication
Implementing and correctly configuring email authentication protocols like SPF, DKIM, and DMARC is fundamental for modern email deliverability. ARC builds upon these foundational protocols, providing a vital layer of trust for forwarded messages. The bh= tag within the ARC-Message-Signature header is a testament to the granular detail required to maintain message integrity across complex email routing paths. For a broader overview of these protocols, consider reading a simple guide to DMARC, SPF, and DKIM.
For organizations sending emails, actively monitoring authentication results is not just a best practice, it's a necessity. Failures in SPF, DKIM, or ARC can lead to emails being blocked or sent to spam, directly impacting communication and business operations. A comprehensive understanding of each tag, including bh=, and its role within the authentication headers is vital for troubleshooting and maintaining a healthy email ecosystem.
Suped provides robust DMARC monitoring and reporting tools that offer deep insights into your email authentication performance, including ARC validation. Our platform's AI-powered recommendations translate complex data into clear, actionable steps, allowing you to quickly identify and fix issues related to your email flow. This helps secure your domain against spoofing and ensures high deliverability rates. Leveraging a platform that simplifies the complexities of email authentication, such as Suped, allows you to maintain consistent email authentication. Our unified platform brings together DMARC, SPF, and DKIM monitoring with blocklist and deliverability insights, providing a complete overview of your email health. The generous free plan makes advanced DMARC management accessible to everyone.