What does an Authentication Results Header contain when DKIM passes but DomainKeys fail?
Michael Ko
Co-founder & CEO, Suped
Published 15 Jul 2025
Updated 16 Aug 2025
6 min read
When diagnosing email deliverability issues, one of the first places I look is the Authentication-Results header. It's a goldmine of information about how a receiving mail server authenticated an incoming message. Sometimes, you might encounter a peculiar entry: dkim=pass alongside domainkeys=fail. This seemingly contradictory result can be puzzling, but it tells an interesting story about email authentication history and current practices.
Understanding this specific header status requires a look back at the evolution of email authentication protocols and how different mail servers handle them. While it might seem like a major problem, often it's just a relic of older systems. Let's break down what this header means and why you might see this combination.
The Authentication-Results header is crucial for email security. It acts as a report card from the receiving mail server, detailing all the authentication checks it performed on an inbound message, including SPF, DKIM, DMARC, and sometimes, the older DomainKeys. This header provides transparency on how a message was authenticated, which helps in checking authentication results in email headers and diagnosing delivery issues. You can find more technical details in the RFC 7601 specification for this header.
When you see dkim=pass, it indicates that the DomainKeys Identified Mail (DKIM) digital signature attached to the email is valid. This means the message originated from the claimed domain and has not been tampered with since it was signed. DKIM is a critical authentication method, helping to prevent email spoofing and phishing attacks.
Here's an example of what such a header might look like, highlighting the DKIM and DomainKeys results:
Example Authentication-Results header
Authentication-Results: amavis.wordtothewise.com (amavisd-new); dkim=pass (1024-bit key) header.d=ontraport.com; domainkeys=fail (1024-bit key) reason="fail (message has been altered)"
The legacy of DomainKeys
Before DKIM became the widely adopted standard, there was DomainKeys. It was an earlier email authentication system developed by Yahoo! (which now uses both blocklists and blacklists in their mail systems) to verify the sender of an email and ensure the message hadn't been altered in transit. Its core concept was similar to DKIM, relying on cryptographic signatures and DNS records, but it had stricter rules regarding message modification.
DKIM, or DomainKeys Identified Mail, emerged as an evolution of DomainKeys. It refined the protocol, making it more robust and flexible to account for common modifications emails undergo during transit through various mail servers and mailing lists. This evolution is why DKIM is now the industry standard, widely supported by major email providers like Gmail, Yahoo, and Microsoft (Outlook.com). You can find the base specification for DKIM on dkim.org.
DomainKeys
Origin: Developed by Yahoo! as an early email authentication protocol.
Status: Largely deprecated; replaced by DKIM. Still supported by some older systems.
Sensitivity: Highly sensitive to message alteration, even minor modifications can break the signature.
DKIM (DomainKeys Identified Mail)
Origin: An evolution of DomainKeys, standardized by the IETF.
Status: Current industry standard for email signing and verification.
Flexibility: More resilient to transit modifications due to canonicalization algorithms.
Why DKIM passes while DomainKeys fail
The most common reason for this scenario is subtle message alteration during transit. DomainKeys has a very strict canonicalization algorithm, meaning even minor changes to the email headers or body, like differences in whitespace or line endings introduced by an intermediate mail server, can invalidate its signature. DKIM, on the other hand, offers more flexible canonicalization options (e.g., 'relaxed' mode) that are designed to tolerate these minor changes, allowing the signature to remain valid.
Another factor is the presence of older email infrastructure. Some mail servers, including those using systems like amavisd-new, might still perform checks against the older DomainKeys protocol even if the sender has fully transitioned to DKIM. This means an email signed only with a DKIM signature might still be subjected to an outdated DomainKeys verification, leading to a 'fail' result because no DomainKeys signature was present or because the message was altered in a way that DomainKeys, but not DKIM, would flag.
Key reasons for discrepancy
Strict canonicalization: DomainKeys is less tolerant of changes, leading to failures from minor modifications.
Protocol evolution: DKIM superseded DomainKeys, offering more robust and flexible authentication.
Outdated systems: Some legacy systems still check for DomainKeys, even if the sender uses only DKIM.
Practical implications and troubleshooting
The good news is that if your DKIM passes, the DomainKeys failure typically has minimal impact on your email deliverability. Most modern receiving mail servers prioritize DKIM (and SPF, and DMARC) for authentication. A domainkeys=fail result is often just an informational note from an older system, indicating an outdated check was performed. It's unlikely to cause your emails to land in spam or be placed on a blocklist (or blacklist), as long as your DKIM and SPF are passing and DMARC is aligned.
If you encounter this scenario, the best course of action is to inspect the full email headers. This helps you identify which specific server added the Authentication-Results header and the exact reason cited for the DomainKeys failure, such as 'message has been altered'. For comprehensive authentication, ensure your DMARC authentication passes consistently. A solid foundation in DMARC, SPF, and DKIM is essential for modern email.
Inconsistent results across different providers, such as DKIM failing for Outlook.com but passing elsewhere, suggest provider-specific quirks or outdated systems on the receiving end. Focus your troubleshooting on ensuring your DKIM records are correctly configured and that messages aren't being altered by your sending infrastructure. Remember, while SPF and DKIM failures can sometimes occur despite correct setup, a passing DKIM is generally sufficient for modern mail systems.
Views from the trenches
Best practices
Regularly review your Authentication-Results headers to catch authentication discrepancies early.
Ensure your DKIM canonicalization is set to 'relaxed' to accommodate minor transit modifications.
Prioritize monitoring DKIM, SPF, and DMARC results over legacy protocols like DomainKeys for modern deliverability.
Keep your email sending infrastructure updated to avoid issues with outdated authentication checks.
Common pitfalls
Over-focusing on DomainKeys failures when DKIM is passing, as it often has minimal impact.
Not accounting for message alteration by intermediate servers or mailing lists which can break strict authentication.
Assuming all mail servers interpret authentication results uniformly; discrepancies between providers are common.
Using outdated mail transfer agents (MTAs) that still perform unnecessary DomainKeys checks.
Expert tips
Use DMARC reports to get a holistic view of your authentication results across various receivers.
When troubleshooting, always check the raw email headers to see the full authentication chain.
Don't chase a DomainKeys fail if your DKIM and DMARC are consistently passing; it's often a non-issue.
Be aware that specific providers, like Microsoft, sometimes have unique handling rules that can affect authentication.
Expert view
Expert from Email Geeks says (November 15, 2021): My assumption was that Microsoft was emitting invalid emails, and older versions of OpenDKIM weren’t handling the canonicalization correctly in those rare cases.
November 15, 2021 - Email Geeks
Expert view
Expert from Email Geeks says (November 15, 2021): There have been occasional instances where an older version of OpenDKIM couldn’t process some rare emails from Microsoft, though the exact reason was never fully narrowed down.
November 15, 2021 - Email Geeks
Conclusion
The appearance of dkim=pass alongside domainkeys=fail in an Authentication-Results header is usually a benign diagnostic anomaly. It signifies that the modern, more resilient DKIM authentication successfully passed, while its older, stricter predecessor (DomainKeys) failed, often due to minor and common message alterations during email transmission.
For robust email deliverability, your primary focus should remain on properly implementing and maintaining DKIM, SPF, and DMARC. These three protocols are the cornerstone of modern email authentication and are essential for building and protecting your sender reputation and ensuring your emails reach the inbox, rather than being flagged as spam or ending up on a email blacklist or blocklist.
Yahoo! (which now uses both blocklists and blacklists in their mail systems) to verify the sender of an email and ensure the message hadn't been altered in transit. Its core concept was similar to DKIM, relying on cryptographic signatures and DNS records, but it had stricter rules regarding message modification.
Gmail, Yahoo, and 
Microsoft (Outlook.com). You can find the base specification for DKIM on dkim.org.
