How to troubleshoot DKIM implementation issues and understand ARC-Seal in email headers?
Matthew Whittaker
Co-founder & CTO, Suped
Published 20 Apr 2025
Updated 19 Aug 2025
11 min read
Dealing with email deliverability issues can be frustrating, especially when it comes to authentication protocols like DKIM. I've seen many situations where a domain owner believes they've correctly implemented DKIM, only to find their emails still landing in spam folders or displaying authentication failures in the headers. One common misconception is that simply adding a DNS record is enough for DKIM to work, but it's often more complex than that. Correct DKIM implementation requires both the DNS record and proper configuration on your sending mail server.
This can be particularly baffling when you inspect your email headers and see unexpected entries, such as a d=google.com value within an ARC-Seal. Understanding these headers is key to troubleshooting. ARC, or Authenticated Received Chain, plays a crucial role in maintaining email authentication results, especially when messages are forwarded through intermediaries. Let's delve into how to troubleshoot common DKIM problems and demystify the ARC-Seal header to ensure your emails reach their intended recipients.
When DKIM isn't working as expected, the first place to look is always the email headers. These headers contain vital clues about the email's journey and its authentication status. A common issue I encounter is a missing DKIM signature entirely, even if the DNS record for the public key exists. This indicates that the sending mail server or service isn't actually signing the outgoing emails. It's not enough to simply publish the _domainkey record, your email platform must be configured to use it.
Another frequent problem is a DKIM body hash mismatch. This happens when the email's content or headers are altered after the DKIM signature is applied but before it reaches the recipient. Even a minor change, like adding a footer or modifying line breaks, can invalidate the signature. This is why it's crucial to ensure that any intermediaries, such as email marketing platforms or forwarding services, are not modifying the message in a way that breaks DKIM. You can find more details on how to fix DKIM body hash mismatch failures in our guides.
Incorrect DKIM selector usage can also lead to issues. The selector is a specific string in the DKIM DNS record (e.g., s=selector1) that allows the receiving server to find the correct public key to verify the signature. If your sending system uses a different selector than the one published in your DNS, the verification will fail. Ensure that the selector configured in your sending software matches the s= tag in your email's DKIM-Signature header. Sometimes a DKIM permerror (no key for signature) is exactly this, a selector mismatch or an improperly published key.
Understanding ARC-Seal in email headers
Authenticated Received Chain (ARC) is an email authentication protocol designed to address the shortcomings of SPF and DKIM when emails are forwarded or modified in transit. Without ARC, an email that passes SPF and DKIM at the initial hop might fail these checks after being processed by a mailing list or forwarding service. This is because these intermediaries often modify the email, breaking its original SPF or DKIM signature. ARC provides a way to preserve the original authentication results, allowing recipient mail servers to make more informed delivery decisions.
The ARC-Seal header is a crucial component of the ARC protocol. It's essentially a digital signature applied by each intermediary server (or sealer) that processes the email. This seal cryptographically protects the previous ARC headers, including the ARC-Authentication-Results (AAR) header, which summarizes the authentication status at that point in the email's journey. When you see an ARC-Seal with d=google.com, it indicates that Google (or one of its servers) has received the email, verified its existing authentication results, and then re-sealed them before forwarding or delivering the message. This means even if SPF or DKIM subsequently fail due to transit modifications, the ARC-Seal can attest to their original validity.
Configuring ARC as a trusted sealer can be an advanced step, particularly for organizations that act as intermediaries, like mailing list operators. For example, Microsoft Defender documentation provides guidance on this. The presence of an ARC-Seal from a reputable domain like Google or Microsoft can significantly improve deliverability for forwarded emails, as it signals to the final recipient that the original authentication status was legitimate, even if current SPF or DKIM checks fail. If you're encountering DMARC failures specifically due to forwarding, understanding how ARC affects DMARC failures is essential.
The purpose of ARC
ARC helps maintain email authentication results (SPF, DKIM, DMARC) through multiple hops and intermediaries, like mailing lists or forwarding services. Without it, these authentication checks often break due to legitimate message alterations, leading to false negatives.
Interpreting email headers for diagnosis
The raw email headers are your diagnostic powerhouse. They provide a chronological record of every server an email passed through, along with the authentication results at each step. To view them, you'll typically look for an option like "Show original" or "View source" in your email client. What you'll find is a series of lines beginning with various tags like Received:, Authentication-Results:, DKIM-Signature:, and ARC-Seal:. Understanding these entries is key to diagnosing delivery issues.
For DKIM, specifically look for the DKIM-Signature header. If it's missing, or if the Authentication-Results header shows dkim=fail or dkim=permerror, this points to a DKIM configuration problem. We have a detailed guide on how to check authentication results in email headers for Gmail, which applies broadly to other providers too. Pay attention to the bh= (body hash) and b= (body hash of signed part) tags in the DKIM-Signature header, as mismatches here are common.
For ARC, you'll see a series of ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers. Each set represents a hop where ARC was applied. The ARC-Authentication-Results header will show the SPF, DKIM, and DMARC results as seen by that particular ARC sealer. The ARC-Seal itself includes important tags like i= (instance number), d= (signing domain), and s= (selector). The cv= (Chain Validation Status) is particularly important; cv=pass indicates the chain of ARC seals is valid according to RFC 8617.
The relationship between DKIM, DMARC, and ARC is interconnected. DMARC relies on SPF and DKIM alignment for authentication. When an email is forwarded, the SPF check often breaks because the IP address of the forwarding server doesn't match the original sender's SPF record. Similarly, DKIM can break if the message content or headers are altered by the intermediary. This is where ARC steps in, providing a chain of verified authentication results from previous hops, which DMARC can then use to make a more nuanced decision rather than simply failing the email.
If you're facing persistent DMARC failures, even with seemingly correct SPF and DKIM, the culprit might be intermediaries. ARC helps by creating a verifiable trail of authentication results. A final recipient server that supports ARC can validate the ARC chain, effectively restoring trust in a message that would otherwise fail DMARC. This is particularly relevant for mailing lists and automated forwarding rules, which are notorious for breaking standard email authentication.
For a comprehensive understanding, RFC 8617 details the Authenticated Received Chain protocol. It describes how ARC-Seal functions like a DKIM signature, applying a digital signature to the preceding ARC headers. This ensures the integrity of the authentication history. If you're encountering issues where emails are failing DMARC despite proper SPF and DKIM setup, it's worth investigating if ARC could be the missing piece in your deliverability puzzle.
Best practices for ensuring DKIM and ARC validity
When troubleshooting DKIM, remember that publishing the DNS record is only half the battle. Your sending infrastructure must also be configured to generate and attach the DKIM signature to outgoing emails. If you've just added the DNS record and headers haven't changed, it's a clear sign that the sending server isn't signing the mail. Work with your hosting provider or email service to ensure the signing process is active and correctly configured for your domain.
Regularly checking your email headers is an invaluable practice. This allows you to monitor your authentication status and catch issues early. Look for dkim=pass in the Authentication-Results header. If it shows fail or permerror, delve deeper into the DKIM-Signature header for specific reasons. Tools that analyze email headers can simplify this process, providing clear breakdowns of each authentication result. Remember to also check your overall SPF, DKIM, and DMARC setup.
DNS records: Ensure your DKIM DNS record (TXT or CNAME) is correctly published and includes the full public key without typos or formatting errors. Verify the selector matches what your sending service uses.
Sending server configuration: Confirm that your email sending service or server is actively signing emails with DKIM and using the correct domain and selector.
Content modification: Be aware of any systems that might alter email content or headers after DKIM signing, as this will invalidate the signature. This includes certain mailing list managers.
ARC adoption: While you might not implement ARC yourself, understanding its headers (ARC-Seal, ARC-Authentication-Results) helps interpret authentication results for forwarded emails.
Before correct DKIM
Authentication issues: Emails frequently fail DKIM authentication or lack a DKIM signature entirely.
Delivery impact: Messages often land in spam or are rejected by recipient servers.
Header analysis: No DKIM-Signature header present, or dkim=fail in Authentication-Results.
Improved deliverability: Higher inbox placement rates and fewer rejections.
Header analysis:DKIM-Signature header present and dkim=pass in Authentication-Results.
Views from the trenches
Best practices
Always verify your DKIM DNS record using an online checker after publication to ensure it's accessible and correct.
Ensure your email sending platform or MTA is configured to actually sign emails with the correct DKIM selector.
Regularly inspect email headers for authentication results to catch issues proactively before they impact deliverability.
If using forwarding or mailing lists, understand how ARC seals can preserve authentication status.
Common pitfalls
Assuming that just publishing a DKIM DNS record is sufficient for emails to be signed.
Not checking email headers for actual DKIM signatures and authentication results.
Failing to account for content modifications by intermediaries that can break DKIM signatures.
Ignoring ARC headers, which provide valuable context for forwarded or relayed emails.
Expert tips
Many web hosting companies may not have robust email hosting configurations, leading to DKIM signing issues.
A missing DKIM signature in email headers, despite a published DNS record, indicates the sending server is not signing messages.
The `d=` tag in an ARC-Seal header indicates the domain of the intermediary that applied the seal.
Small volume senders will build domain reputation slower, but consistent proper authentication helps.
Expert view
Expert from Email Geeks says there’s often no DKIM signature on mail if the sending system is not configured to sign it.
2019-03-21 - Email Geeks
Expert view
Expert from Email Geeks says the `d=google.com` in an ARC-Seal indicates Google applied the seal to preserve authentication results for forwarded mail.
2019-03-22 - Email Geeks
Keys to successful email authentication
Mastering DKIM implementation and understanding ARC-Seal headers are critical for maintaining strong email deliverability. By meticulously checking your DNS records, ensuring your sending infrastructure is properly configured to sign emails, and knowing how to interpret the various authentication headers, you can diagnose and resolve most DKIM-related issues.
Additionally, recognizing the role of ARC in preserving authentication results through intermediaries like mailing lists is vital for a robust email strategy, especially when dealing with DMARC policies. A comprehensive approach to email authentication, encompassing SPF, DKIM, and DMARC, complemented by an understanding of ARC, will significantly improve your inbox placement and overall email success.
Google (or one of its servers) has received the email, verified its existing authentication results, and then re-sealed them before forwarding or delivering the message. This means even if SPF or DKIM subsequently fail due to transit modifications, the ARC-Seal can attest to their original validity.
or Microsoft can significantly improve deliverability for forwarded emails, as it signals to the final recipient that the original authentication status was legitimate, even if current SPF or DKIM checks fail. If you're encountering DMARC failures specifically due to forwarding, understanding how ARC affects DMARC failures is essential.
