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?
Updated on 19 Oct 2026: We clarified Microsoft 365 DKIM setup and message-header checks, and confirmed the Mailchimp authentication requirements.
Fix the DKIM alignment error by making Microsoft 365 sign outbound mail with the same custom domain that appears in the visible From address. If your message is From user@example.com but the DKIM signature has d=tenant.onmicrosoft.com, that signature can pass DKIM authentication without satisfying DMARC alignment. DMARC still passes if another DKIM signature or SPF passes with domain alignment. The fix requires Microsoft 365's tenant-specific selector values, the matching public DNS records, and DKIM signing enabled for the custom domain.
For Mailchimp, include:spf.mtasv.net is not required for normal Mailchimp Marketing domain authentication. Mailchimp Marketing commonly uses its own envelope sender domain, so adding that SPF include to your domain does not create an SPF-aligned DMARC pass for the visible From domain. Current manual domain authentication supplies two DKIM CNAME records and one DMARC TXT record. Keep requirements for other sending services separate; Mailchimp Transactional has its own domain authentication setup.
- Publish both tenant-provided selector CNAME records, enable DKIM signing for the custom domain, then send a new test message.
- Do not delete existing DKIM records blindly. Confirm the selector and signing domain, then check the record type and exact CNAME targets.
- Use the authentication records Mailchimp provides. Do not add include:spf.mtasv.net for normal Mailchimp Marketing authentication.
- Investigate a DKIM body hash failure as a change to the signed body or an altered test sample, separately from domain alignment.
Why Microsoft 365 shows DKIM alignment errors
DKIM has two separate results that people mix together. First, the cryptographic signature needs to verify. Second, the domain in the DKIM signature needs alignment with the visible From domain under DMARC. A valid signature can still be unaligned.
DMARC uses relaxed DKIM alignment by default, shown as adkim=r. Under relaxed alignment, the DKIM d= domain and visible From domain can be different subdomains of the same organizational domain. Strict alignment, adkim=s, requires an exact domain match. A tenant domain such as tenant.onmicrosoft.com does not match example.com under either mode.
Microsoft 365 gives every tenant an onmicrosoft.com domain. Mail sent from that initial domain is signed automatically. Each custom domain or subdomain that sends mail needs its own DKIM configuration. Microsoft's DKIM setup documentation explains that each custom domain or subdomain sending through Microsoft 365 needs its own two CNAME records and DKIM signing enabled. Enabling Microsoft 365 DKIM does not sign messages sent directly by Mailchimp; authenticate that mail stream in Mailchimp separately.
A common mistake is fixing only the public DNS record. Microsoft 365 has to sign the message with the right domain. DNS only tells receivers where to find the public key used to verify that signature.
- Check whether the DKIM signature has d=tenant.onmicrosoft.com while the From domain is your custom domain.
- Enable DKIM signing in Microsoft 365 for the custom domain used by that message.
- Do not assume that a published selector record means Microsoft has started using that selector.
- Retest with a new outbound message after Microsoft shows the domain as enabled and valid.
DKIM alignment compares the signing domain with the visible From domain for DMARC.
How to configure DKIM signing for a Microsoft 365 custom domain
The Microsoft 365 fix has a predictable order. Confirm that the custom domain is added and accepted in Microsoft 365, create or open its DKIM configuration, and copy the tenant-specific selector CNAME values. Publish both CNAME records in public DNS, enable signing, then inspect a new message header. Use an account with permissions to manage the DKIM configuration and access to the authoritative DNS zone.
Microsoft 365 does not require you to upload a private DKIM key for the normal custom-domain setup. Microsoft controls the private keys and provides CNAME targets that point to the public-key locations. Copy the values shown for your tenant instead of constructing them. Existing configurations can retain the earlier onmicrosoft.com target format. New custom-domain configurations use the format introduced in May 2025, with a dynamic target under dkim.mail.microsoft. The old and new target formats cannot coexist for the same selector.
Find the Microsoft 365 DKIM selector valuespowershell
Connect-ExchangeOnline # Confirm that the custom domain is accepted in Microsoft 365. Get-AcceptedDomain -Identity example.com Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME # Run only if example.com is not listed above. New-DkimSigningConfig -DomainName example.com -Enabled $false -KeySize 2048 Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
DNS CNAME shapedns
selector1._domainkey.example.com. CNAME <Selector1CNAME from Microsoft> selector2._domainkey.example.com. CNAME <Selector2CNAME from Microsoft>
- In the Microsoft Defender portal, open Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then select the DKIM tab.
- Choose the exact custom domain or subdomain used in the visible From address, rather than the initial tenant domain.
- If the status is NoDKIMKeys, try enabling the domain to generate its configuration. The expected Client error dialog supplies the CNAME values; close it and reopen the domain details after the status changes to CnameMissing.
- Copy both selector CNAME values from the Publish CNAMEs section, including every dynamic target segment.
- Create both CNAME records at the authoritative DNS provider for the custom domain.
- Turn on DKIM signing after Microsoft detects the CNAME records. PowerShell should show Enabled: True and Status: Valid.
- Send a new message to a recipient outside your Microsoft 365 organization and inspect its headers. The DKIM d= value should be the custom domain and Authentication-Results should show a DKIM pass.
Enable signing after publishing both CNAME recordspowershell
# Run after both tenant-provided CNAME records resolve in public DNS. Set-DkimSigningConfig -Identity example.com -Enabled $true Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status
DKIM checker
Check selector records and public key configuration.
?/7tests passed
After DNS is live, a focused DKIM checker helps confirm that each selector resolves and the record syntax is valid. A live email header check is still required because valid DNS does not prove that Microsoft 365 has enabled signing for the domain.
Microsoft Defender DKIM settings with signing enabled for the example.com custom domain.
How to fix CnameMissing in Microsoft 365
CnameMissing means Microsoft 365 cannot detect the expected selector CNAME configuration. It is a DNS detection problem, not proof that the private signing key is broken. Compare public DNS with the current Selector1CNAME and Selector2CNAME values in the tenant, and verify both selectors even if signing already works with one.
- Check the host field. Many DNS panels append the zone automatically. Entering the full name can create selector1._domainkey.example.com.example.com.
- Publish both selector1 and selector2 even though only one selector signs a given message; the other is needed for key rotation.
- Create CNAME records at the selector hosts. Do not paste Microsoft's CNAME targets into TXT records, and resolve any conflicting record at the same selector hostname before adding its CNAME.
- Copy the exact tenant-provided targets. Do not remove dynamic characters, change dashes, or reuse values copied from another domain or tenant.
- Check how the DNS provider handles fully qualified CNAME targets and trailing dots so it does not append the zone to the target value.
- Keep DKIM CNAME records in DNS-only mode if the DNS provider offers a web proxy. Confirm that public DNS returns the expected CNAME targets.
- Query public DNS and the authoritative nameservers instead of relying only on the DNS control panel or an internal DNS answer.
Query both DKIM selector CNAME recordsbash
dig CNAME selector1._domainkey.example.com +short dig CNAME selector2._domainkey.example.com +short nslookup -type=CNAME selector1._domainkey.example.com nslookup -type=CNAME selector2._domainkey.example.com # Trace the public DNS delegation if local answers differ. dig +trace selector1._domainkey.example.com CNAME dig +trace selector2._domainkey.example.com CNAME
DNS visibility depends on cached answers and TTL, including cached missing-record responses. Once both public queries return the exact tenant-provided targets, retry the signing toggle or recheck the domain. Keep both selector CNAME records published during key rotation. Microsoft documents a four-day (96-hour) delay before a requested rotation switches the active signing key; check RotateOnDate and the new message's s= selector before treating the unchanged selector as a fault.
How to fix a DKIM body hash verification failure
A DKIM body hash verification failure is separate from DKIM alignment. It means the value calculated from the received body, after the signature's body canonicalization, does not match the bh= value in the DKIM signature. The most common cause is a system changing the body after the DKIM signature was added.
Check signature verification separately from domain alignment, then compare fresh messages delivered to two receiving systems. If one verifies the body hash and another fails, compare the exact raw messages. That pattern points to message processing or an incomplete test sample rather than a selector DNS typo.
Real body change
- A gateway or compliance system adds a disclaimer after Microsoft signs the message.
- A security system rewrites URLs or tracking parameters inside the signed body.
- A downstream mail-flow rule appends text or legal content after DKIM signing.
- A forwarding or list system changes MIME boundaries, footers, or body encoding.
Test sample or verifier problem
- A local verifier hashes decoded or reformatted content instead of applying the signature's body canonicalization to the raw message.
- A copied sample loses body content or changes the MIME structure needed for the test.
- A header-only sample omits the body bytes required to verify its DKIM body hash.
- An incomplete message export gives the verifier different bytes than the recipient received.
Send a plain-text email with no disclaimer or downstream mail-flow modification. If its body hash verifies, add each modification back one at a time until the failure returns. Apply necessary body changes before the final DKIM signing step. Microsoft 365 normally uses relaxed canonicalization, which tolerates some whitespace changes but does not preserve a signature after substantive content changes.
Is include:spf.mtasv.net required for Mailchimp?
No. include:spf.mtasv.net is not required for normal Mailchimp Marketing authentication. SPF only contributes to a DMARC pass when the authenticated envelope sender domain has alignment with the visible From domain. Mailchimp Marketing normally uses a Mailchimp-controlled envelope sender domain, visible in the delivered Return-Path, so receivers evaluate that domain's SPF record rather than your visible From domain's record.
Mailchimp separates domain verification from domain authentication. Verification confirms that you control an address at the domain. Mailchimp's authentication instructions specify two CNAME records for DKIM and one TXT record for DMARC during manual setup. Publish the exact values shown in the account, wait for validation, and confirm that campaign headers show an aligned DKIM pass. Validation normally takes a few minutes, but Mailchimp allows up to 48 hours.
A domain must have only one DMARC TXT record at _dmarc. If a DMARC record already exists, do not publish Mailchimp's value as a second record. Keep one valid record and preserve its reporting addresses and intended policy; do not downgrade an enforced policy just to copy a setup example.
|
|
|
|
|---|---|---|---|
2 DKIM CNAMEs | DKIM or aligned SPF | Enable signing | |
2 DKIM CNAMEs | Aligned DKIM | Authenticate domain; retain one DMARC record | |
Transactional sender | Sender records | Varies | Follow sender |
Unknown source | DMARC data | Confirm | Identify owner |
Keep SPF and DKIM decisions tied to the sender that actually sends the mail.
SPF example for a Microsoft 365-only domaindns
example.com. TXT "v=spf1 include:spf.protection.outlook.com -all"
Use this SPF example only when Microsoft 365 is the domain's sole authorized SPF sender. If an SPF record already exists, edit that record rather than creating a second one, and preserve other legitimate senders. SPF has a limit of 10 DNS-lookup-causing terms during evaluation, including nested includes. Exceeding that limit returns permerror. Do not remove an existing include until its owning mail stream has been identified.
For Mailchimp Marketing, authenticate the sending domain, publish the records supplied in the account, then use DMARC reports to confirm that campaigns pass through aligned DKIM. An unneeded SPF include consumes SPF DNS-lookup budget and does not fix DKIM alignment.
How to read DKIM and DMARC results in message headers
Follow Microsoft's outbound verification steps and test with a recipient outside your Microsoft 365 organization. Messages between domains in the same organization can omit the DKIM signature, so an internal dkim=none result does not prove outbound signing is broken. Read the full headers at the destination.
Example receiver results with an aligned DKIM passtext
From: user@example.com Return-Path: <bounce@bounce.sender.example.net> Authentication-Results: mx.receiver.example; dkim=pass header.d=example.com header.s=selector1; spf=pass smtp.mailfrom=bounce.sender.example.net; dmarc=pass header.from=example.com
- header.d=example.com identifies the verified DKIM signing domain. It matches the visible From domain in this example.
- header.s=selector1 identifies the selector. Together with the signing domain, it identifies selector1._domainkey.example.com as the public-key lookup name.
- spf=pass authenticates the envelope sender at bounce.sender.example.net, which has no domain alignment with example.com.
- dmarc=pass is satisfied by the DKIM result here. DMARC does not require both SPF and DKIM alignment.
A message can contain multiple DKIM signatures. One passing signature with domain alignment is enough for DMARC; an extra tenant-domain signature does not cancel it. If several Authentication-Results fields appear, use the result added by the trusted receiving system. An earlier internal result can predate outbound signing.
How to verify the full authentication path
A single DNS lookup does not prove the fix. Verify the domain's DNS records, Microsoft 365 signing state, a fresh message header, and DMARC aggregate data after real mail flows. Each one tests a different part of the authentication path.
For a broad check across SPF, DKIM, and DMARC, use a domain health checker first. Then send a real message and inspect the DKIM-Signature and Authentication-Results headers. Finally, use DMARC monitoring to confirm that Microsoft 365 and Mailchimp traffic pass for the expected aligned domain over time.
DKIM rollout checks
Use sender evidence, not a raw pass-rate percentage, to decide whether to enforce DMARC.
Setup incomplete
DKIM missing
Custom-domain DKIM is missing or Microsoft signs as the tenant domain.
Investigate sources
Known failure
A legitimate sender still uses an unexpected signing or envelope domain.
Ready to stage policy
Mail aligned
Every identified legitimate sender passes DMARC through aligned DKIM or SPF.
Maintain enforcement
Monitored
New failures are investigated and authorized sending changes are tracked.
Suped's DMARC reporting platform groups DMARC aggregate data by source and shows SPF and DKIM alignment results. Use those reports to track Microsoft 365 and Mailchimp separately and investigate unexpected signing domains.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
A practical Suped workflow is to add the domain, classify Microsoft 365 and Mailchimp as known sources, resolve alignment diagnostics, and stage DMARC enforcement only after legitimate mail passes. Alerts can identify a sudden change in authentication before it persists across later campaigns or business mail.
For deeper background on Microsoft-specific failures, the Microsoft DKIM failures article covers common Microsoft 365 signing problems. The DKIM authentication article explains why a valid signature still needs domain alignment for DMARC.
Views from the trenches
Best practices
Check the DKIM d= domain in a fresh external header before changing selector DNS records.
Copy both Microsoft 365 CNAME targets from the tenant instead of using old examples.
Use Mailchimp's supplied authentication records and keep unrelated SPF includes out.
Test body hash failures with a plain message before changing any DKIM selector DNS records.
Common pitfalls
Deleting selector records can break valid signing when the issue is inside Microsoft.
A tenant-domain DKIM pass alone does not establish DMARC alignment for a custom domain.
Adding an unrelated SPF include spends lookup budget without fixing DMARC alignment.
Testing with copied headers alone omits the message body needed for DKIM verification.
Expert tips
Keep Microsoft 365 and marketing mail separate in DMARC source and ownership reports.
Retest after Microsoft shows Valid because previously sent mail keeps its old headers.
Keep both Microsoft selectors published so key rotation does not interrupt DKIM signing.
Review downstream gateways and disclaimers when diagnosing DKIM body hash verification failures.
Marketer view
Marketer from Email Geeks says DKIM alignment errors often come from Microsoft 365 signing with the tenant domain instead of the custom From domain.
2022-08-31 - Email Geeks
Marketer view
Marketer from Email Geeks says the fix belongs in Microsoft 365 signing configuration first, because DNS publication alone does not make Microsoft use the domain.
2022-08-31 - Email Geeks
Frequently asked questions
Microsoft 365 automatically signs mail for the initial tenant domain. Each custom domain or subdomain needs its two CNAME records and DKIM signing enabled before Microsoft signs with that domain.
No. DMARC requires a DKIM or SPF pass with domain alignment to the visible From domain. A tenant-domain DKIM pass alone does not satisfy that requirement for a custom From domain, but another valid signature or an SPF pass with domain alignment can satisfy it.
Microsoft cannot detect the expected selector CNAME configuration. Compare both selectors with the current tenant values. Check for a duplicated zone name, an incorrect record type or target, and DNS caching. Publish both selectors so key rotation remains possible.
Not first. Confirm which selector appears in a fresh message header, which domain appears in the DKIM d= tag, and what CNAME values Microsoft 365 currently expects. Both selectors are needed for key rotation.
Mailchimp Marketing normally uses its own envelope sender domain, which SPF checks. Domain authentication lets Mailchimp add a DKIM signature that matches your visible From domain for DMARC.
Use it only when the sending service responsible for that mail stream explicitly provides it. It is not a Mailchimp Marketing requirement. Before removing an existing include, identify the service that added it and confirm whether it still sends mail.
