Why DMARC Fails After Email Platform Migration Even When SPF and DKIM Pass

You migrated your email platform. SPF checks out. DKIM checks out. Then your DMARC reports show hundreds of failures, and nobody can explain why.

Here is what is actually happening, and how to catch it faster with DMARC monitoring.

The short answer

SPF and DKIM are authentication checks. They verify that a specific server is allowed to send for a domain and that the message was signed with a valid key. DMARC adds a separate layer on top: alignment.

Alignment means the domain you see in the email's From header (the address your recipients see) has to match the domain that passed SPF or DKIM. When you migrate platforms, the infrastructure changes, and that alignment can break even though the individual checks still pass.

This is where DMARC monitoring tools like DMARCFlow matter. They catch alignment failures from your daily DMARC aggregate reports within 24 hours. If you are not watching those reports, you will not know alignment broke until a recipient flags a problem or your deliverability drops.

Why migrations break DMARC alignment

There are two main ways this happens.

SPF return-path domain changes

When you switch email platforms, the sending infrastructure moves to new servers with new IP addresses. Your old SPF record listed your old service provider's IP ranges. Your new provider has different ones.

The RFC5321.MailFrom domain (the return-path address used for bounces) is now hosted by your new provider. If that domain does not match your RFC5322.From domain, DMARC alignment fails. This is called SPF alignment.

DKIM signing domain changes

Your new email platform signs outgoing messages with its own DKIM keys, using its own domain as the signing domain. If that domain differs from your RFC5322.From domain, DMARC alignment fails on the DKIM side.

Some platforms use a shared signing domain that matches your brand domain. Others use a generic platform domain. The difference matters enormously for DMARC.

How to tell which one broke

The fastest way is to look at your DMARC report. You want to see which alignment check is failing: SPF, DKIM, or both.

If your report shows failures in the SPF column, the RFC5321.MailFrom domain is not matching your From domain after migration.

If it shows DKIM failures, your new platform is signing with a domain that is not the same as your From domain.

If both are failing, you have two separate problems that both need fixing.

How to fix it

The goal is to make either the RFC5321.MailFrom domain or the DKIM-Signature domain match your RFC5322.From domain. You have two paths.

Fix SPF alignment

Make sure your new email platform uses your brand domain as the RFC5321.MailFrom domain. Many platforms allow you to set a custom return-path domain instead of their default. If yours does not, this is a limitation of that platform.

If you are using Microsoft 365 after migrating from Google Workspace, or vice versa, you need to verify that your SPF include statements cover the new platform's sending infrastructure completely. An incomplete SPF record after migration is one of the most common causes of SPF alignment failure.

Fix DKIM alignment

Your new platform should sign outgoing mail with your brand domain, not its own generic domain. If it does not, check whether your plan includes custom DKIM signing. Some providers require a higher tier plan to sign with your own domain.

If you cannot get your DKIM signing domain to match your From domain, you need either to accept that DKIM alignment will fail (and rely on SPF alignment alone), or to switch to a platform that supports custom DKIM signing.

A specific example

A company migrated from a legacy SMTP provider to Microsoft 365. Their SPF record had been updated to include the Microsoft 365 SPF include mechanism. Their DKIM was configured on the Microsoft 365 tenant. SPF checks passed. DKIM checks passed.

But DMARC reports showed a 40 percent failure rate. The problem: they had a secondary marketing email system that used a different RFC5321.MailFrom domain. That system's mail was not covered by their DMARC policy because the From domain matched but the return-path domain did not. After the migration, they had not updated the subdomain routing, so alignment was broken for about 40 percent of their outbound volume.

The fix took two hours. Identifying it from the DMARC report took longer because nobody was checking the reports.

What you should do before your next migration

Before you switch platforms, verify three things. First, check what RFC5321.MailFrom domain your new platform will use and whether it can be set to your brand domain. Second, check what DKIM signing domain your new platform uses and whether custom signing is available on your plan. Third, run a DMARC alignment check before cutover, not after.

Waiting until after migration to discover an alignment problem means you have already sent mail that failed DMARC checks for some recipients. Some mail systems will silently deliver it. Others will junk it or reject it.

Checking your DMARC reports after any infrastructure change is standard practice for a reason. Tools like DMARCFlow make that check automatic rather than something you have to do manually, and they alert you within 24 hours when alignment breaks.

Frequently asked questions

Can a platform migration break DMARC even if nothing else changes?

Yes. The migration itself is the change. As soon as the sending infrastructure, the RFC5321.MailFrom domain, or the DKIM signing domain changes, DMARC alignment can fail even if your DNS records look correct.

How do I check DMARC alignment after a migration?

Read your DMARC aggregate report. Look at the alignment failure breakdown. If you see DKIM alignment failures, your DKIM signing domain does not match your From domain. If you see SPF alignment failures, your RFC5321.MailFrom domain does not match your From domain.

What is the difference between SPF authentication and DMARC alignment?

SPF authentication checks whether the sending server IP is allowed to send for the domain in the RFC5321.MailFrom field. DMARC alignment checks whether the domain in the RFC5321.MailFrom or DKIM-Signature field matches the domain in the RFC5322.From header that recipients see. You can pass SPF and fail DMARC if the domains do not match, which is exactly what happens during most platform migrations.

How long does it take to fix DMARC alignment after a migration?

The DNS changes needed to fix alignment typically take effect within a few hours, but it can take up to 48 hours for DMARC reports to reflect the new state. The longest part is usually identifying which alignment check is failing and finding the right configuration setting in your new platform.

DMARCFlow processes your daily DMARC aggregate reports and flags alignment failures within 24 hours of when they start. If you are mid-migration or planning one, that feedback loop is worth setting up before you cut over.