Microsoft 365 handles email correctly for a lot of organisations without much configuration. But DMARC is different. Getting DMARC to pass consistently in an M365 environment requires deliberate setup, and there are four specific failure modes I see repeatedly in production.
Understanding DMARC alignment is what makes each failure mode make sense.
Alignment: the concept that causes most DMARC failures
DMARC doesn’t just check whether SPF or DKIM passed. It checks whether the domain that passed SPF or DKIM aligns with the domain in the message’s From header (the address your recipient actually sees).
For SPF alignment, the domain in the envelope sender (also called the return-path or MAIL FROM) must match the From header domain. These are two separate fields and they often differ.
For DKIM alignment, the d= domain in the DKIM signature must match the From header domain.
DMARC passes if either alignment check passes. The failure modes below all involve alignment breaking in specific M365 configurations.
Failure mode 1: DKIM not enabled in Microsoft 365
Microsoft 365 does not automatically enable DKIM signing for custom domains when you add them. Out of the box, outbound mail from yourcompany.com is signed by Microsoft using their own domain (*.onmicrosoft.com), not yours.
This means DKIM passes for authentication purposes, but DKIM alignment against your From domain fails. If your SPF is also failing alignment (common with forwarding or third-party senders), DMARC fails entirely.
What it looks like in aggregate reports: You’ll see mail from Microsoft’s IP ranges passing SPF on *.onmicrosoft.com and DKIM signed with a Microsoft domain, but DMARC alignment failing because neither aligns with your custom domain.
The fix: Enable DKIM in the Microsoft 365 Defender portal under Email & collaboration, Policies & rules, Threat policies, DKIM. Microsoft generates two CNAME records (selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com) that you add to your DNS. Once both CNAMEs resolve correctly, enable DKIM signing for the domain.
Microsoft rotates between selector1 and selector2 automatically for key rotation. Both CNAMEs need to be present and resolving. The portal will show an error if they’re not.
After enabling, allow a few hours for the change to propagate and check your next DMARC reports. You should see DKIM alignment pass rates climb.
Check DKIM selector resolution for your domain →
Failure mode 2: third-party senders breaking SPF alignment
Your marketing team sends newsletters via Mailchimp. Your support desk sends from Zendesk. Your CRM sends from Salesforce. All of these send email with a From address at your domain.
Here’s the alignment problem: these services typically use their own domain in the envelope sender (return-path). Mailchimp’s return-path is something like bounce.mailchimp.com. That domain passes SPF for Mailchimp’s infrastructure, but SPF alignment fails because the return-path domain doesn’t match your From domain.
If DKIM isn’t configured for your domain on these platforms, DMARC fails entirely for all mail from those services.
What it looks like in aggregate reports: You’ll see source IPs belonging to Mailchimp, HubSpot, Salesforce or similar passing SPF on a third-party domain, with DKIM either absent or signed with the vendor’s own domain, and DMARC alignment failing.
The fix: Configure DKIM signing for your domain on every third-party sending platform. Most major ESPs and CRMs support custom DKIM domains. This means publishing a DKIM key in your DNS that the platform uses to sign your mail with your domain in the d= value.
SPF alignment will still fail for these senders. That’s expected and normal. DMARC only requires one alignment check to pass, so DKIM alignment is sufficient.
Work through every source IP in your DMARC reports and confirm DKIM alignment is passing for each one.
Failure mode 3: email forwarding breaking SPF
This one affects organisations that forward mailboxes, often executives who forward to a personal address, or domains forwarded after an acquisition.
When a receiving server forwards a message, it typically changes the envelope sender to its own domain. This breaks SPF for the original domain, because the message is now coming from a server not in that domain’s SPF record. DKIM usually survives forwarding unless the forwarding server modifies the message body.
What it looks like in aggregate reports: You’ll see messages from unexpected IP ranges, often residential ISPs, personal mail providers, or partner organisations, failing SPF but potentially passing DKIM. If DKIM is configured and intact, DMARC should still pass via DKIM alignment. If DKIM was never set up, forwarded mail will fail DMARC entirely.
The fix: The forwarding problem is why DKIM matters so much. SPF is inherently broken by forwarding. DKIM survives it. Organisations with working DKIM across all sending paths are largely immune to forwarding-related DMARC failures.
For environments with a lot of forwarding, also look at whether the forwarded domains need DMARC records of their own, and whether ARC (Authenticated Received Chain) sealing would help. Large mail providers like Google and Microsoft implement ARC to preserve authentication results through forwarding chains.
Failure mode 4: hybrid routing stripping DKIM
Organisations running Exchange Server on-premises alongside Microsoft 365 often route some mail through on-prem infrastructure. This is common in hybrid deployments where not all mailboxes have migrated, or where on-prem connectors handle specific mail flows.
Exchange Server, depending on version and configuration, can modify message headers during routing. Header modification after DKIM signing invalidates the signature. The signature is still present but no longer verifies.
What it looks like in aggregate reports: You’ll see DKIM present but failing validation, from IP addresses belonging to your own infrastructure. SPF may pass, but if the envelope sender domain doesn’t match the From domain, DMARC alignment still fails.
The fix: Identify which transport rules or connectors are modifying mail headers in your hybrid environment. The most common culprits are anti-spam or compliance rules that add headers to messages after signing, and connectors that rewrite certain fields.
If on-prem Exchange is adding disclaimers or other content to messages, this also invalidates DKIM. Disclaimers need to be added before signing, or the signing needs to happen after the disclaimer is appended, typically by configuring DKIM signing on the final outbound hop rather than earlier in the routing path.
In complex hybrid environments, moving DKIM signing to Exchange Online’s outbound connector rather than signing on-prem is usually cleaner.
Working through your DMARC reports
If you’re seeing failures but can’t identify the source, the aggregate reports are the right starting point. Each report shows the sending IP, the DKIM result and selector used, the SPF result and domain, and the DMARC alignment outcome.
Map each failing IP to the service responsible for it. For Microsoft 365 tenants, Microsoft publishes their IP ranges. IPs in those ranges that are failing DMARC are almost always the DKIM-not-enabled case.
Once DKIM is enabled in M365 and configured on every third-party sender, most M365 DMARC failures resolve. The forwarding and hybrid routing cases require more investigation but affect a smaller proportion of environments.
Relevant reading: Setting up DKIM in Microsoft 365 covers the CNAME setup in detail. Understanding DMARC aggregate reports explains how to read the XML reports and identify failure sources.