Suped

Summary

Troubleshooting Office 365 DKIM and SPF email authentication failures primarily involves meticulously checking DNS configurations and understanding potential internal Microsoft-related issues. Common culprits include incorrect or missing DNS records, such as the SPF TXT record lacking 'spf.protection.outlook.com' or having multiple SPF entries, and misconfigured or unpropagated DKIM CNAME records. Additionally, internal Microsoft issues, such as incorrect IP evaluation for SPF or email body tampering leading to DKIM breaks, have been reported. Specific sending practices, like starting a line with a period or encoding issues, can also disrupt DKIM. For a holistic approach, it's essential to verify both SPF and DKIM settings via the Microsoft 365 Defender portal or PowerShell, ensure proper inclusion of third-party senders in SPF, and analyze DMARC reports to identify specific authentication failures and sources. Recognizing that DNS propagation delays can cause intermittent issues and that Microsoft might sign outbound mail with an 'onmicrosoft.com' DKIM identifier (affecting DMARC alignment) is also crucial. Regularly reviewing and validating these configurations is vital for robust email deliverability and security.

Key findings

  • Internal Microsoft Issues: Office 365 has historically experienced internal issues that can cause DKIM and SPF failures, including potentially pulling the wrong IP from headers for SPF evaluation or tampering with the email body, leading to DKIM breaks.
  • DKIM Breaking Factors: Encoding problems, particularly with special characters, and starting a line with a period can cause DKIM signing and authentication to fail, especially with Microsoft MTAs.
  • SRS and DMARC Alignment: Using Sender Rewriting Scheme (SRS) for internal Microsoft forwarding is ill-advised as it can break email authentication, specifically DMARC, if an aligned DKIM key is not used for signing.
  • Misaligned DKIM Signing: A common cause of DMARC non-alignment is Office 365 signing outbound mail with a 'dkim=domainkey' identifier of 'onmicrosoft.com' instead of the organization's primary domain.
  • Importance of DMARC Reports: DMARC aggregate and forensic reports are invaluable for identifying specific SPF and DKIM failures, the exact reasons for those failures, and the sending sources, which helps in pinpointing misconfigurations.

Key considerations

  • DNS Record Verification: Thoroughly verify your DNS records. For SPF, ensure a single TXT record includes 'spf.protection.outlook.com' and has a correct '~all' or '-all' mechanism, avoiding the 10-lookup limit. For DKIM, confirm the two specific CNAME records for your domain are correctly published and propagated, using tools like MXToolbox for validation.
  • Office 365 Configuration Checks: Within Office 365, use the Microsoft 365 Defender portal or PowerShell commands like Get-DkimSigningConfig to confirm DKIM signing is enabled for your domains. Ensure that custom domains are properly configured for DKIM, as Microsoft sometimes signs outbound mail with an 'onmicrosoft.com' identifier, causing alignment issues.
  • Third-Party Senders and Hybrid Environments: If using third-party services to send emails on behalf of your domain, ensure their SPF and DKIM settings are correctly configured and included in your domain's SPF record. In hybrid email environments, verify proper SPF alignment across all sending paths, as routing through other services can cause failures.
  • Troubleshooting Tools and Data: Utilize online tools like MXToolbox, Google's Admin Toolbox, or EasyDMARC to check DNS record syntax, propagation, and identify common errors. Analyzing DMARC reports is crucial for identifying authentication failures, pinpointing specific reasons (SPF or DKIM), and identifying misconfigured sending sources.
  • Addressing Common Pitfalls: Be aware of specific issues that can break authentication, such as encoding problems, starting a line with a period, or Microsoft's internal use of Sender Rewriting Scheme (SRS) for internal forwarding, which can interfere with DMARC alignment. Always check mail headers of failed emails for detailed authentication failure information.

What email marketers say

11 marketer opinions

Troubleshooting Office 365 DKIM and SPF authentication failures often boils down to diligent DNS record management and specific platform configurations. A primary cause is incorrect or missing DNS records, whether it's an SPF TXT record with syntax errors, multiple entries, exceeding the 10-lookup limit, or the omission of spf.protection.outlook.com. Similarly, misconfigured or unpropagated DKIM CNAME records are frequent culprits. It's crucial to verify that DKIM signing is enabled for your domain within the Microsoft 365 Defender portal or via PowerShell. When third-party sending services are involved, their SPF and DKIM settings must also be correctly integrated into your domain's DNS. Effective troubleshooting relies on using online tools like MXToolbox to validate DNS records and analyzing mail headers of failed emails for specific error details. DMARC reports are invaluable for identifying the exact nature of authentication failures and their sources. Administrators should also account for DNS propagation delays, as newly updated records take time to become globally visible, potentially causing intermittent issues. Regular review of these configurations is vital for robust email deliverability and security, protecting against spoofing and phishing attempts.

Key opinions

  • Common DNS Misconfigurations: Incorrect, missing, or syntactically flawed DNS records for SPF - e.g., multiple SPF records, exceeding the 10-lookup limit, or missing spf.protection.outlook.com - and DKIM - missing or incorrect CNAME records - are the most frequent causes of authentication failures.
  • Office 365 Internal Enablement: DKIM signing for custom domains must be explicitly enabled within the Microsoft 365 Defender portal or via PowerShell, beyond just publishing DNS records.
  • Third-Party Sender Impact: Emails sent through third-party services often fail SPF/DKIM if those services' settings are not correctly configured and included in the main domain's SPF record.
  • DNS Propagation Delays: Changes to DNS records require time to propagate globally, leading to intermittent failures even after correct configuration until propagation is complete.
  • Value of Diagnostic Data: Mail headers of failed emails provide direct insights into authentication failure reasons, while DMARC aggregate and forensic reports are essential for identifying the scope and source of failures.
  • Content-Related DKIM Issues: Specific content formatting, such as starting a line with a period or improper character encoding, can inadvertently break DKIM signatures, particularly with Microsoft MTAs.

Key considerations

  • Meticulous DNS Record Verification: Always start by meticulously verifying SPF TXT records for correct syntax, a single v=spf1 entry, inclusion of spf.protection.outlook.com, and adherence to the 10-lookup limit. For DKIM, confirm the exact publication and propagation of the two Microsoft-provided CNAME records.
  • Office 365 Platform Configuration: Ensure DKIM signing is actively enabled for your domain within the Microsoft 365 Defender portal, or confirm its status using PowerShell commands, as DNS records alone are not sufficient.
  • Comprehensive Third-Party Service Integration: If using external email sending platforms, verify that their SPF and DKIM configurations are properly set up and accounted for within your primary domain's DNS records.
  • Leveraging Online Troubleshooting Tools: Utilize tools like MXToolbox or Google's Admin Toolbox for validating DNS records, and always analyze DMARC reports for a holistic view of authentication success and failure patterns across all sending sources.
  • Patience with DNS Propagation: After making DNS changes, allow sufficient time for global propagation. Use DNS lookup tools to confirm changes are visible from various locations before concluding a fix has failed.
  • Regular Security and Deliverability Audits: Periodically review your SPF and DKIM configurations to ensure they remain current, accurate, and robust against evolving threats, which is crucial for both email deliverability and overall organizational security.

Marketer view

Email marketer from Email Geeks shares experience with DKIM failing due to encoding issues, particularly when special characters are improperly translated to HTML.

1 Mar 2023 - Email Geeks

Marketer view

Email marketer from Email Geeks advises that starting a line with a period can break DKIM signing and authentication, specifically with Microsoft MTAs.

26 Dec 2024 - Email Geeks

What the experts say

3 expert opinions

Troubleshooting Office 365 DKIM and SPF authentication failures often points to internal Microsoft processes, DNS misconfigurations, and how emails are routed. Experts indicate that Office 365 has faced internal issues that can lead to authentication breaks, such as incorrect IP evaluation for SPF or unintended email body modifications affecting DKIM. A common problem is Office 365 signing outbound mail with an 'onmicrosoft.com' DKIM identifier instead of the sender's primary domain, which results in DMARC non-alignment. Additionally, SPF can fail when emails are routed through services external to Office 365. It is also ill-advised to use Sender Rewriting Scheme (SRS) for internal Microsoft forwarding, as this can severely disrupt DMARC if a proper aligned DKIM key isn't used. Resolving these issues requires verifying custom domain DKIM configurations within Office 365 and ensuring SPF alignment across all email sending paths, particularly in complex hybrid environments.

Key opinions

  • Internal O365 Quirks: Office 365 has previously exhibited internal issues, potentially including incorrect IP evaluations for SPF or modifications to email bodies, which can directly cause DKIM and SPF authentication failures.
  • DKIM Signing Misalignment: A frequent cause of DMARC non-alignment is Office 365 signing outbound messages with a 'dkim=domainkey' identifier tied to 'onmicrosoft.com' rather than the organization's configured primary domain.
  • SPF Failure in Hybrid Routing: SPF authentication can fail when email is routed through services other than Office 365 before reaching the recipient, especially common in hybrid email setups.
  • SRS Impact on Authentication: Using Sender Rewriting Scheme (SRS) for internal Microsoft forwarding is problematic; it can disrupt DMARC alignment if an aligned DKIM key is not used for signing.

Key considerations

  • Configure Custom DKIM: Ensure custom domains are correctly configured for DKIM within Office 365 to prevent the default 'onmicrosoft.com' signing and maintain proper DMARC alignment.
  • Verify SPF in Hybrid Setups: In environments where email is routed through multiple services, verify SPF alignment meticulously across all sending paths to prevent authentication failures.
  • Avoid SRS for Internal Handoffs: Refrain from using Sender Rewriting Scheme (SRS) for internal Microsoft forwarding, as it can inadvertently break email authentication, particularly DMARC.

Expert view

Expert from Email Geeks responds that Office 365 has had internal issues causing DKIM and SPF failures in the past. She explains that they might be pulling the wrong IP from headers for SPF evaluation and potentially tampering with the email body, leading to DKIM breaks or indicating a wonky encoding problem.

25 Dec 2021 - Email Geeks

Expert view

Expert from Email Geeks explains that using Sender Rewriting Scheme (SRS) for internal Microsoft forwarding is ill-advised. She states that Microsoft should simply ignore internal handoffs, as SRS can break email authentication, specifically DMARC, if an aligned DKIM key is not used for signing.

20 Jul 2023 - Email Geeks

What the documentation says

3 technical articles

Effective troubleshooting for Office 365 DKIM and SPF authentication failures focuses on verifying critical DNS configurations and leveraging specific platform tools. Administrators need to ensure DKIM is actively enabled for their domains, confirm accurate CNAME record publication, and use PowerShell to check signing status. For SPF, the focus is on the correct inclusion of 'spf.protection.outlook.com,' maintaining a single SPF record, and not exceeding the DNS lookup limit. A holistic approach to email authentication also emphasizes the critical alignment of SPF, DKIM, and DMARC, necessitating careful review of all records and analysis of DMARC reports to identify and resolve authentication discrepancies.

Key findings

  • DKIM Verification Procedures: Troubleshooting DKIM failures in Office 365 requires administrators to first verify DKIM is enabled for their domains, check CNAME records for correct publication and propagation, and confirm signing status via PowerShell.
  • SPF Record Compliance: For SPF, it's essential to verify the TXT record includes 'include:spf.protection.outlook.com,' has a correct mechanism like '~all' or '-all,' maintains only one SPF record per domain, and adheres to the 10-lookup limit.
  • External Sender Authentication Needs: Third-party services or custom senders transmitting email on behalf of your domain may require their own specific DKIM setup or inclusion in your domain's SPF record to ensure successful authentication.
  • Holistic Authentication Alignment: A comprehensive approach to email authentication involves ensuring that SPF, DKIM, and DMARC are all correctly configured and aligned, working in concert to validate legitimate email.
  • DMARC Report Utility: DMARC reports provide vital data for identifying email authentication failures and their sources, allowing administrators to make informed adjustments to SPF and DKIM configurations for improved deliverability and security.

Key considerations

  • Confirm DKIM Status and Records: Systematically verify DKIM enablement for your domains, confirm that the necessary CNAME records are correctly published and propagated in your DNS, and use PowerShell commands like Get-DkimSigningConfig to validate the signing status and configuration.
  • Validate SPF Record Integrity: Meticulously check your SPF TXT record to ensure it includes 'include:spf.protection.outlook.com,' that there is only one SPF record per domain, and that it does not exceed the 10-lookup limit. Utilize online tools for syntax validation and propagation confirmation.
  • Integrate Third-Party Senders: If using custom senders or third-party services to send emails on behalf of your domain, ensure they have their own DKIM setup or that their sending IPs are properly included in your domain's SPF record to prevent authentication failures.
  • Leverage DMARC for Diagnostics: Implement DMARC and actively analyze DMARC reports. These reports are crucial for identifying specific authentication failures, pinpointing the sources of non-compliance, and guiding necessary adjustments to your SPF and DKIM configurations to achieve proper alignment.

Technical article

Documentation from Microsoft Learn explains that when troubleshooting DKIM failures in Office 365, administrators should first verify that DKIM is enabled for their domains, check the CNAME records in their DNS to ensure they are correctly published and propagated, and use PowerShell commands like Get-DkimSigningConfig to confirm the signing status and configuration. It also advises checking for any custom senders or third-party services that might be sending on behalf of the domain, as they may require their own DKIM setup or specific exclusions.

25 Mar 2024 - Microsoft Learn

Technical article

Documentation from Microsoft Learn shares that troubleshooting SPF failures in Office 365 involves verifying the SPF TXT record for the domain includes "include:spf.protection.outlook.com" and has a correct "~all" or "-all" mechanism. It emphasizes that a domain should only have one SPF record and exceeding the 10-lookup limit can cause failures. Administrators should use tools to validate the record syntax and propagation and ensure all legitimate sending sources, including third-party senders, are included in the SPF record to prevent legitimate emails from being marked as spam.

19 May 2025 - Microsoft Learn

Start improving your email deliverability today

Sign up