How DMARC Alignment Breaks After an Email Platform Migration (And How to Fix It)

The problem you did not expect

You migrated to a new email platform. SPF check: pass. DKIM check: pass. DMARC: fail.

You checked your DNS records. Nothing changed. Your old platform was working fine. Then all of a sudden DMARC reports show alignment failures, and you have no idea why nothing in your From address changed.

The answer is DMARC alignment, and it is different from SPF and DKIM pass/fail.

Why alignment is not the same as authentication

SPF and DKIM each check a specific thing:

• SPF checks whether the sending server is authorized for the domain in the Return-Path (also called the envelope from).
• DKIM checks whether the message was cryptographically signed by a domain that claims responsibility.
• DMARC alignment checks whether the domain used in SPF or DKIM actually matches the domain in your From header.

SPF and DKIM can both pass. If neither of those domains aligns with your From address, DMARC fails anyway.

This is exactly what happens during most email platform migrations.

The mechanism: DKIM signing domain vs your From domain

When you move to a new email platform, the new provider signs outgoing messages with its own DKIM keys. In many default configurations, the provider signs with its internal routing domain, not with your From address domain.

Example: your From address is sender@example.com. Your new Microsoft 365 tenant uses the default Microsoft DKIM signing key, which signs messages with a domain like selector1._domainkey.prod.outlook.com. When receivers check DMARC alignment, they compare example.com (your From domain) against prod.outlook.com (the DKIM signing domain). These do not match, so alignment fails, even though DKIM itself verified correctly.

The same problem can appear with SPF. If your new platform uses a third-party relay or gateway that changes the Return-Path domain, SPF alignment can also fail even when your SPF record technically includes the new platform.

Pre-migration checklist

Do these before you cut over:

1. Enable DKIM on your From domain specifically, not the provider default. In Microsoft 365: Exchange Admin > Protection > DKIM > add your domain and publish the two CNAME records. In Google Workspace: Admin > Apps > Google Workspace > Gmail > Authenticate email > enable DKIM for your domain.
2. Check what domain your new platform uses for DKIM signing before you enable it. If it defaults to its own domain, you need to override that.
3. Verify your SPF include count. If you are adding a new platform to an existing SPF record, you may be pushing past the 10-lookup DNS limit. Use SPF flattening if needed.
4. Test in staging before full cutover. Send test messages to an external address that provides DMARC report feedback.
5. Confirm your DMARC record uses p=quarantine at most during the transition, not p=reject. This gives you a safety net while you verify alignment.

Post-migration verification

After cutover, check your DMARC aggregate reports within the first 48 to 72 hours. Look for alignment results on your legitimate sending sources.

A passing DMARC result means both:

• SPF or DKIM passed
• The domain used in that check aligns with your From address domain

If you see SPF or DKIM pass but alignment fail, the most common cause is that DKIM is signing with the wrong domain. Go back to your DKIM configuration and confirm the selector is published for your actual From domain, not the provider default.

This is also where DMARCFlow fits. DMARCFlow monitors your aggregate reports continuously and alerts you when alignment failures appear after a platform change. During a migration window, you want to know within hours, not days, when a source stops aligning. A monitoring tool that surfaces DKIM alignment failures per source makes that fast.

Quick-reference checklist

Before migration:

• Enable DKIM on your From domain (not provider default)
• Verify DKIM selector published to your DNS for your domain
• Count SPF includes; flatten if you are near 10
• Set DMARC to p=quarantine, not p=reject, before cutover
• Test in staging

After migration:

• Pull DMARC aggregate reports within 48 to 72 hours
• Confirm 100% alignment pass on your legitimate sources
• Watch for new sending sources that were not in your pre-migration baseline
• If alignment still fails, check whether DKIM is signing with the wrong domain

When to call for help

If you have checked your DKIM configuration and alignment still fails, the problem is likely in your Return-Path domain configuration or in how your email relay is handling the envelope from. These require access to your MTA configuration and DMARC record analysis.

FAQ

Why does DMARC fail when SPF and DKIM both pass?

Because DMARC checks alignment, not just whether SPF or DKIM passed. The domain used in SPF or DKIM must match your From address domain. If your new email platform signs DKIM with its own domain instead of yours, alignment fails.

Can this happen with SPF too?

Yes. If a third-party relay or gateway changes your Return-Path domain during transit, SPF alignment can fail even when your SPF record correctly includes the new platform.

How do I check if DKIM is signing with the wrong domain?

Most DMARC aggregate reports include the DKIM domain used in the check. Look for entries where the DKIM result is pass but the alignment result is fail. The DKIM domain in that record will show you what domain the platform is actually signing with.

How long should I stay at p=quarantine after a migration?

At minimum 7 to 14 days of monitoring with clean aggregate reports before moving to p=reject. If you see new sources appearing in reports after that window, investigate before upgrading.