Why does DKIM fail for Outlook.com and Hotmail.com?

Key findings

• Body hash mismatch: The most frequent cause of DKIM failure (signature not verified) is a mismatch between the email's actual body content and the hash recorded in the DKIM signature. This can occur if the email content is altered in transit or if the signing process doesn't account for minor formatting changes.
• Header canonicalization: Microsoft's stricter interpretation of header canonicalization (how headers are prepared before signing) can lead to mismatches if not handled with a relaxed/relaxed policy or if there are unexpected modifications by intermediate mail transfer agents (MTAs).
• Temporary errors (temperror): A DKIM temperror often indicates a transient issue, such as a DNS lookup problem, when Microsoft attempts to retrieve your DKIM public key. While temporary, frequent temperror rates suggest underlying DNS or infrastructure instability.
• DMARC policy impact: Even if DKIM passes, DMARC can still fail if the 'From' domain does not align with the DKIM signing domain. Microsoft's stricter policies (including their new sender requirements) emphasize authentication alignment to prevent spoofing and phishing.

Key considerations

• Debugging: When encountering DKIM failure, particularly signature did not verify, investigate potential changes to the email body or headers between signing and receipt. This is a common factor in cases where Outlook/Hotmail explicitly rejects emails, sometimes with a Microsoft 550 5.7.515 access denied bounce.
• Canonicalization standards: Ensure your DKIM signing process uses relaxed/relaxed canonicalization to be more tolerant of whitespace or minor reformatting by email systems. This often resolves body hash mismatch failures.
• DNS stability: Monitor your DNS for reliability and speed. Frequent temperror results in DMARC reports might indicate DNS lookup issues on your end, or Microsoft's. More information on Microsoft's authentication requirements can be found on the Microsoft Tech Community blog.
• DMARC reporting: Utilize DMARC reports to gain visibility into your email authentication results from Microsoft, including specific DKIM failure reasons, and use this data to refine your sending practices.

Key opinions

• Complex issue: Many marketers find DKIM failures with Microsoft properties to be a complex and frustrating issue, often requiring deep dives into email headers and server logs to diagnose accurately.
• Encoding inconsistencies: One prominent theory is that email encoding, specifically how the message body is handled before and after signing, can lead to subtle alterations that cause the DKIM signature to invalidate.
• Canonicalization choice: The choice of DKIM canonicalization, especially relaxed/relaxed, is frequently discussed as a way to mitigate issues arising from minor modifications during transit, making the signature more forgiving.
• Domain alignment: Marketers also highlight the importance of the DKIM signing domain aligning with the 'From' domain, as this is a key factor for Hotmail/Outlook.com's authentication validation, influencing DMARC compliance and general Outlook deliverability.

Key considerations

• Thorough testing: Before sending large campaigns, marketers recommend sending test emails to Outlook.com and Hotmail.com addresses and analyzing authentication headers to pinpoint the exact failure reason. For more on the fundamentals, see our simple guide to DMARC, SPF, and DKIM.
• ESP configuration: If using an Email Service Provider (ESP), confirm their DKIM signing practices. Some ESPs might reformat emails or have specific requirements that impact DKIM validation on the recipient's end.
• Monitoring DMARC reports: Regularly reviewing DMARC reports provides granular insights into authentication failures, including those specific to Microsoft domains. This data is invaluable for troubleshooting and maintaining a healthy sender reputation.
• Content and encoding: Pay close attention to email content, especially when including dynamic elements, and ensure character encoding (e.g., UTF-8) is consistent to prevent body alterations. One specific example of this issue has been highlighted in discussions on GitHub.

Key opinions

• Microsoft's strictness: Experts commonly observe that Microsoft's authentication mechanisms can be particularly strict, often leading to failures that might pass elsewhere. This includes subtle handling of email body formatting.
• Transcoding issues: Changes to email content, such as transcoding (conversion between character encodings) or whitespace modifications by intermediate systems, are frequently cited as causes for DKIM body hash mismatches.
• DNS temperrors: A common 'DKIM temperror' with Microsoft often points to DNS lookup problems for the DKIM record itself. This could be due to network latency or transient issues on either end. Our article on decoding DKIM temperror provides more detail.
• Interaction with DMARC: Experts emphasize that even if DKIM technically passes, DMARC can still fail if the 'From' domain doesn't align with the DKIM signing domain, leading to rejection by Outlook/Hotmail under their stricter DMARC policies.

Key considerations

• Canonicalization choice: Always recommend using relaxed/relaxed canonicalization to provide the most flexibility and tolerance for minor email modifications, which is crucial for interoperation with varying mail systems, including Microsoft's. This also helps in diagnosing and reducing DKIM temporary error rates with Microsoft.
• Content modification: Advise senders to minimize any server-side or ESP-side modifications to the email body or headers after the DKIM signature has been applied. Every change, no matter how small, can invalidate the signature.
• Regular validation: Encourage regular testing of DKIM validity to major mailbox providers, especially Outlook/Hotmail. This proactive approach helps identify issues quickly before they impact deliverability. Mailgun, for example, shares observations on Outlook's specific rejection behaviors.
• DMARC reports analysis: Leveraging DMARC aggregate reports is crucial for identifying trends in DKIM failures and understanding the scope of the problem across different recipients.

Key findings

• Body hash corruption: Documentation confirms that E-Mail was modified or signature did not verify errors indicate a mismatch between the email body's calculated hash and the one signed, often due to unexpected content changes.
• DKIM temperror meaning: The 'temperror' status in DMARC reports specifically denotes a transient issue during DKIM validation, typically a problem with performing a DNS lookup for the DKIM public key.
• Microsoft's alignment expectations: Microsoft's systems expect the DKIM signing domain to align (match or be a subdomain of) the 'From' address domain, impacting DMARC policy enforcement.
• New sender requirements: Microsoft's updated requirements for high-volume senders place a greater emphasis on consistent authentication, including SPF, DKIM, and DMARC, to reduce spam and phishing.

Key considerations

• Canonicalization adherence: Refer to RFC 6376 (DKIM) for canonicalization methods, understanding that 'relaxed' is more robust against minor message alterations. For detailed guidance on DMARC policy, consider how to implement DMARC p=reject safely.
• DNS health: Maintain robust DNS infrastructure to ensure DKIM records are consistently available and resolvable. Issues with DNS can lead to intermittent 'temperror' results.
• DMARC reporting analysis: Analyze DMARC aggregate reports from Outlook.com to identify patterns in DKIM failures and gain insights into specific rejection reasons, which can be crucial for troubleshooting. You can find out more on understanding and troubleshooting DMARC reports.
• Content encoding standards: Ensure that email content encoding (e.g., UTF-8) is consistently applied throughout the email creation and sending process to prevent unexpected body hash mismatches, as documented in various technical forums and GitHub discussions.