How do I fix DKIM alignment errors and configure DKIM signing for a custom domain in Microsoft 365 and is include:spf.mtasv.net required for mailchimp?
Michael Ko
Co-founder & CEO, Suped
Published 20 Jun 2025
Updated 16 Aug 2025
9 min read
Email deliverability relies heavily on proper authentication. When you see DKIM alignment errors, particularly with a platform like Microsoft 365, it usually means your emails aren't being signed with your actual custom domain, but rather with a default .onmicrosoft.com domain. This discrepancy can severely impact your email's ability to reach the inbox, often leading to messages being flagged as spam or outright rejected.
Another common area of confusion arises when integrating third-party email service providers, like Mailchimp, with your domain's authentication records. Specifically, the question of whether include:spf.mtasv.net is a necessary part of your SPF record for Mailchimp often comes up. These are critical aspects of email authentication that require careful configuration.
In this guide, I will walk you through fixing DKIM alignment errors for your custom domain in Microsoft 365 and clarify the SPF requirements for Mailchimp. Understanding and implementing these configurations correctly is vital for maintaining a strong sender reputation and ensuring your emails land in the inbox.
DKIM alignment is a key component of DMARC authentication. It means that the domain in the d= tag of your DKIM signature must match your organizational domain, which is typically found in your email's "From" header. If these domains don't align, even if the DKIM signature itself is valid, DMARC will fail. For Microsoft 365 users, a common issue is that emails are automatically signed with the initial .onmicrosoft.com domain provided during setup, rather than your custom domain.
This default behavior can lead to apparent DKIM failures when checked by tools or DMARC policies. While the .onmicrosoft.com signature might pass authentication, it won't achieve DMARC alignment if your "From" address uses your custom domain. This is a crucial distinction, as DMARC requires alignment for both SPF and DKIM to consider an email legitimate. You can learn more about this by reading our article on how to fix DKIM from domain mismatch.
The impact of this misalignment isn't just theoretical, it directly affects your email deliverability and sender reputation. Recipients' mail servers, especially those enforcing strict DMARC policies like Microsoft and Yahoo, are more likely to quarantine or reject emails that fail DMARC, leading to messages ending up in spam folders or being bounced back. This is why ensuring that Microsoft 365 signs your emails with your custom domain is critical. If you're encountering issues, refer to our comprehensive guide on troubleshooting Office 365 DKIM and SPF failures.
The importance of fixing DKIM alignment
Ensuring proper DKIM alignment is not just about avoiding errors, it's about building trust with receiving email servers. When your DKIM signature aligns with your "From" domain, it tells the recipient that your organization genuinely sent the email and that it hasn't been tampered with in transit. This significantly improves your chances of inbox delivery and protects your brand from impersonation and phishing attempts. Ignoring these warnings can lead to your legitimate emails being blocked or sent to the spam folder, impacting your communication and marketing efforts.
Configuring DKIM signing for your custom domain in Microsoft 365
To correctly configure DKIM signing for your custom domain in Microsoft 365, you need to generate DKIM keys and publish them as CNAME records in your domain's DNS. This process ensures that Microsoft 365 can sign your outgoing emails with your domain, not the default .onmicrosoft.com domain. You can initiate this from the Microsoft 365 Defender portal.
The steps generally involve navigating to "Email & collaboration" > "Policies & rules" > "Threat policies" > "Anti-spam" in the Defender portal. From there, you'll find the DKIM settings where you can enable DKIM for your custom domain. Microsoft will then provide two CNAME records that you need to add to your public DNS. These records contain the public keys that recipients use to verify your emails.
Example DKIM CNAME Records for Microsoft 365DNS
Host name: selector1._domainkey
Points to: selector1-yourdomain-com._domainkey.yourtenantname.onmicrosoft.com
Host name: selector2._domainkey
Points to: selector2-yourdomain-com._domainkey.yourtenantname.onmicrosoft.com
Once these CNAME records are published and DNS has propagated, Microsoft 365 will begin signing your outgoing emails with your custom domain, ensuring proper DKIM alignment. It's also important to note that Microsoft 365 automatically rotates these DKIM keys for security, so you generally don't need to manually update them unless specifically instructed or if you encounter issues. For more in-depth troubleshooting specific to Microsoft DKIM failures, consult our article on why Microsoft DKIM is failing when Gmail passes.
Configuring DKIM is more than just publishing DNS records; it's about ensuring your email sending service (in this case, Microsoft 365) uses the correct keys for signing. If you're still experiencing issues, double-check that Microsoft 365 is indeed signing with your custom domain and not falling back to the .onmicrosoft.com domain. This is often the root cause of DKIM alignment errors reported by various online tools. For a broader understanding of email authentication, consider reviewing our guide on setting up SPF, DKIM, and DMARC for domain authentication.
Mailchimp SPF and DKIM: is include:spf.mtasv.net necessary?
When it comes to Mailchimp and SPF, a common query is whether you need to include include:spf.mtasv.net in your SPF TXT record. The answer is generally no. The reason is that Mailchimp sends emails using its own domains in the Mail From (also known as the RFC 5321.MailFrom or Return-Path) address, which is the domain checked by SPF. Because Mailchimp controls its own sending infrastructure, SPF passes based on their domain, not yours, for messages sent through their platform.
Instead of modifying your SPF record, Mailchimp requires you to add specific CNAME records to your DNS for DKIM authentication. These records enable Mailchimp to sign emails on your behalf, aligning the DKIM signature with your custom domain. This is crucial for DMARC alignment when sending campaigns from Mailchimp. To set up this authentication, Mailchimp provides precise instructions within your account settings, typically found under "Website" > "Domains" > "Verify Domain" or "Authenticate Domain." You can also refer to our guide on fixing DMARC issues with Mailchimp for more details.
The key takeaway for Mailchimp is that while they handle SPF authentication on their end for the Return-Path, DKIM authentication and its alignment with your From header domain remain your responsibility. This ensures that even with a third-party sender, your brand identity is maintained, and your emails pass DMARC checks, contributing to better deliverability and avoiding blocklists. You can get more information about this by reviewing Mailchimp's domain authentication guide.
When to include SPF records
Direct Sending: If you send emails directly from your own mail servers, your domain's SPF record should include their IP addresses.
Third-Party Senders: For email service providers (ESPs) that send emails using your domain as the Mail From address, you must include their SPF mechanism (e.g., include:esp.com) in your SPF record.
No Mail From Control: If an ESP uses its own Mail From domain (like Mailchimp often does), you do not need to include their SPF record in yours, as SPF will pass on their domain.
Troubleshooting common DKIM alignment issues
DKIM alignment errors can be frustrating, but they're often fixable with a systematic approach. The most common reason for DKIM alignment failure, especially with services like Microsoft 365, is simply not having DKIM configured for your custom domain, or having it enabled but with incorrect DNS records. This leads to emails being signed with the default .onmicrosoft.com domain, which fails DMARC alignment. Another potential cause is DNS propagation delays after you've made changes to your CNAME records.
Troubleshooting should start by verifying your DKIM records using a reliable DNS checker, ensuring that the CNAME records provided by Microsoft are correctly published. You should also check the Microsoft 365 Defender portal to confirm that DKIM is enabled for your custom domain and showing as healthy. If you're using DMARC, analyzing your DMARC reports is invaluable. These reports provide detailed insights into your email authentication results, showing which emails are passing or failing SPF and DKIM, and whether alignment is being achieved. This helps pinpoint the exact source of the problem.
Remember, the goal is to have both SPF and DKIM pass authentication and align with your "From" domain for optimal deliverability. While SPF alignment might be handled by your email service provider for certain sending scenarios, DKIM alignment for your custom domain is almost always something you need to configure directly with your email platform. For issues specifically with SPF and DMARC settings, you can find further assistance in our guide on troubleshooting SPF and DMARC settings.
Fixing common DKIM errors and configuration issues
Default Microsoft 365 DKIM
Emails are signed by default with your initial .onmicrosoft.com domain provided by Microsoft. This means the d= tag in the DKIM signature will show yourtenant.onmicrosoft.com.
Alignment & DMARC
Even if the DKIM signature itself passes validation, it will fail DMARC alignment if your emails are sent from your custom domain (e.g., yourdomain.com). This can lead to emails being rejected or sent to spam by DMARC-enforcing receivers. You can learn more about this by reading our article on Microsoft DMARC requirements.
Custom domain DKIM signing
You configure DKIM specifically for your custom domain within the Microsoft 365 Defender portal. This involves adding two CNAME records to your DNS that point to .onmicrosoft.com addresses where your public keys are hosted. The d= tag will then reflect your custom domain, e.g., yourdomain.com.
Alignment & DMARC
With the correct setup, your emails will be signed with your custom domain, ensuring that both DKIM authentication and DMARC alignment pass. This significantly improves email deliverability and helps protect your domain's reputation. Microsoft 365 automatically handles key rotation for these DKIM records.
Problem
Symptom
Solution
OnMicrosoft.com DKIM signing
DKIM verification tools show .onmicrosoft.com in the d= tag, not your custom domain. DMARC reports show DKIM alignment failures.
Configure DKIM for your custom domain in the Microsoft 365 Defender portal. Add the two CNAME records to your DNS as instructed.
Incorrect or missing CNAME records
DKIM validation tools report "No DKIM record found" or "DKIM record published, but no DKIM record found" errors.
Double-check the CNAME records against Microsoft's instructions. Ensure proper hostnames, values, and record types are used. Wait for DNS propagation.
DKIM body hash did not verify
Messages receive a "body hash did not verify" error from recipients, indicating content modification or an issue with the signing process.
This is less common with Microsoft 365, as they handle the signing process. If it occurs, review any transport rules or third-party email hygiene solutions that might be modifying the message body. See our guide on how to fix DKIM body hash did not verify errors.
Views from the trenches
Best practices
Always configure DKIM for your custom domain in Microsoft 365, even if you only use it for internal mail.
Utilize DMARC reports to continuously monitor your authentication and alignment status.
Regularly review your DNS records to ensure they are correct and have propagated globally.
Common pitfalls
Relying solely on external tools for DKIM verification without cross-referencing Microsoft 365 settings.
Assuming SPF includes are needed for all third-party senders, even when they handle SPF on their end.
Forgetting to verify DKIM CNAME records after publishing them or after making DNS provider changes.
Expert tips
For Microsoft 365, the issue is rarely with the DNS records themselves but with Microsoft's internal signing configuration.
Mailchimp uses its own domain for SPF validation, so adding 'spf.mtasv.net' to your SPF record is unnecessary.
DKIM is a handshake: a public key in DNS and a private key held by the sending server (Microsoft 365 or Mailchimp).
Expert view
Expert from Email Geeks says that MXToolbox’s DKIM verification can often be inaccurate, so it's best not to rely solely on it for definitive results.
2022-08-31 - Email Geeks
Expert view
Expert from Email Geeks says DKIM alignment problems with Office 365 stem from the system signing with onmicrosoft.com instead of the custom domain. Users need to follow Office 365's specific instructions to sign with their own domain.
2022-08-31 - Email Geeks
Key takeaways for reliable email authentication
Proper DKIM alignment and SPF configuration are fundamental pillars of modern email deliverability. For Microsoft 365, the key is to move beyond the default .onmicrosoft.com signing and actively configure DKIM for your custom domain via the Defender portal. This ensures that your emails are signed with your brand's true identity, satisfying DMARC requirements and building recipient trust.
When using a third-party sender like Mailchimp, remember that SPF verification often happens on their domain, so specific SPF includes like include:spf.mtasv.net are typically unnecessary for your SPF record. Instead, focus on authenticating your custom domain's DKIM through their platform, which is what achieves DMARC alignment and boosts your campaign deliverability.
By diligently setting up and monitoring these authentication protocols, you can significantly reduce the chances of your emails landing in spam folders, prevent impersonation, and safeguard your sender reputation. Regular monitoring of DMARC reports will provide ongoing insights, helping you to quickly identify and resolve any emerging authentication issues.
Microsoft 365, it usually means your emails aren't being signed with your actual custom domain, but rather with a default .onmicrosoft.com domain. This discrepancy can severely impact your email's ability to reach the inbox, often leading to messages being flagged as spam or outright rejected.
Mailchimp, with your domain's authentication records. Specifically, the question of whether include:spf.mtasv.net is a necessary part of your SPF record for Mailchimp often comes up. These are critical aspects of email authentication that require careful configuration.
