Why DMARC Alignment Breaks After Platform Migration

You migrated your email infrastructure. SPF passes. DKIM passes. DMARC fails. No bounce. No warning. Email goes out, some receivers accept it, some silently junk it, and you only find out months later when someone checks the aggregate report.

This is the silent failure that catches even experienced email operators off guard. The authentication checks pass individually, but the combination check that DMARC actually enforces fails because of alignment.

What DMARC Alignment Actually Means

DMARC adds one requirement that SPF and DKIM do not have on their own: the domains used in authentication must match the From header domain. This is called alignment.

SPF alignment: the domain in the MAIL-FROM or HELO identity must match the From header domain. If you send from newslette at example.com but the From header says newsletter at company.com, SPF alignment fails even if the sending IP is authorized.

DKIM alignment: the domain in the DKIM-Signature header's d= value must match the From header domain. If your mail server signs with d=sender.example.com but the From header says company.com, DKIM alignment fails.

DMARC passes only when at least one of SPF alignment or DKIM alignment passes AND at least one authentication check passes. It is a two-step gate: first the individual checks (SPF pass/fail, DKIM pass/fail), then the alignment check across both.

This distinction matters during migrations because you can have SPF pass and DKIM pass independently, and still have DMARC fail due to alignment.

Why Migrations Break Alignment

Migrations create alignment failures in four predictable ways. Knowing which one applies tells you exactly what to fix.

Changing your mail routing or relay. When you move your mail server or add a relay, the MAIL-FROM domain may change. If your MTA now uses a different envelope domain for bounces, SPF checks that domain against a different identity than your From header. The result is SPF alignment failure even though the sending IP is still authorized.

Switching to a cloud email provider. When you move to Microsoft 365 or Google Workspace, your sent email may now be DKIM-signed by the cloud provider's infrastructure rather than your own servers. If the DKIM selector domain does not match your From header domain, DKIM alignment fails. Microsoft 365 uses the tenant domain for some relay scenarios. Google Workspace uses google.com for certain configurations.

Using a third-party sending service for transactional or marketing email. Services like Amazon SES, SendGrid, Mailgun, or Klaviyo send from their own infrastructure. If they are not configured to DKIM-sign with your From domain, every email they send on your behalf fails DKIM alignment. This is one of the most common causes of alignment failures after a migration, and it is often discovered only when DMARC reports arrive.

Changing the From address domain in automated tools. Some platforms let you set a custom From address. If the sending infrastructure behind that address uses a different domain for SPF or DKIM, alignment breaks. This happens with CRM integrations, support platforms, and ticketing systems that send email on behalf of your domain.

How to Diagnose an Alignment Failure

The fastest way to diagnose alignment is to check your DMARC aggregate reports. Look for entries where both SPF and DKIM appear as "pass" but the DMARC result is "fail". That is an alignment failure.

If you are mid-migration and need to catch alignment changes as they happen, a tool like DMARCFlow that processes your aggregate reports continuously and alerts on new failure patterns is more useful than a one-time check. During a migration window, alignment can break and restore multiple times as different systems come online. Manual checks miss the windows between checks. Automated monitoring does not.

If you do not have aggregate reports set up, you can check manually. Use a DMARC checker tool and look at the detailed result. If it shows SPF: pass, DKIM: pass, and DMARC: fail, you have an alignment problem.

To identify which alignment is failing, check your email headers. Look for the Authentication-Results header. It shows SPF result and the domain it was checked against. Then look for the DKIM-Signature header and its d= value. Compare both of those domains to the From header domain. The mismatch tells you which alignment check is failing.

If the SPF domain in Authentication-Results does not match your From domain, SPF alignment is broken. If the DKIM d= domain does not match your From domain, DKIM alignment is broken. Both can fail simultaneously.

How to Fix SPF Alignment After Migration

If SPF alignment is failing, the MAIL-FROM domain your MTA uses does not match your From header domain. The fix depends on your MTA configuration.

With Postfix, check the smtp_header_checks or the address rewriting configuration. The MAIL-FROM address should use your From domain, or you need to configure the domain rewrite to match. Some Postfix setups default to the local hostname, which creates a domain mismatch.

With Microsoft 365, if you are using shared namespaces or internal relay, the connector configuration determines the MAIL-FROM domain. Setting the correct Return-Path domain in the connector settings restores SPF alignment.

The underlying principle is the same regardless of platform: the domain your MTA uses in the envelope must share the same root domain as your From header, or be explicitly authorized in your SPF record through include mechanisms or a dedicated subdomain for sending.

How to Fix DKIM Alignment After Migration

If DKIM alignment is failing, your DKIM signing domain does not match your From header domain. This usually means your email is being signed by a third-party service using that service's domain.

The correct fix is to configure DKIM signing with your own domain as the d= value. Most major providers support custom DKIM: you add their verification record to your DNS, then they sign with your domain instead of their default domain.

For Amazon SES: after verifying your domain and generating DKIM tokens, you enable custom DKIM signing and add the three CNAME records SES provides to your DNS. SES then signs with your domain, not amazonses.com.

For SendGrid: you can add a custom DKIM record to your DNS and verify it in the SendGrid settings. SendGrid will then sign outbound email with your domain.

For Microsoft 365: you add the DKIM record for your domain in Microsoft 365 admin center. Microsoft generates two CNAME records that you add to your DNS. After verification, Exchange Online signs with your domain.

If your current email provider does not support custom DKIM signing, that is a vendor limitation worth knowing about before you commit to them long-term.

How to Verify Alignment Before Moving to p=reject

Before you move your DMARC policy from p=none to p=quarantine or p=reject, verify that your legitimate email stream passes alignment consistently. Send test emails to multiple external accounts (Gmail, Outlook, Yahoo) and check the authentication headers in each.

In your DMARC aggregate reports, look for a pass rate of 100% or close to it on your legitimate sending sources before you enforce a policy that will hard-reject misaligned email. If you see sporadic failures, investigate whether there are edge cases in your sending patterns: forwarded email, mailing list software that re-sends from a different domain, or automated systems that send through a different infrastructure.

If you are using DMARCFlow, you can monitor alignment in real time and receive alerts when it changes. This is particularly useful during migrations, where you are making active changes to your sending infrastructure and want immediate notification if an alignment failure appears in your reports.

Post-Migration Checklist

Before you consider a migration complete, run through this checklist:

1. Send test email from your primary sending infrastructure to an external account. Check the authentication headers: SPF domain, DKIM d= domain, and From header domain.
2. Send a test email through every third-party service that sends email on your behalf. Check the same three domains.
3. Check your DMARC aggregate reports within 24 hours of migration. Look for any alignment failures on your legitimate sending sources.
4. If you have multiple sending domains or subdomains, test each one independently.
5. If you added any new sending services, verify their DKIM configuration before they send at volume.

If any of these steps show a mismatch, fix the configuration before sending at volume. The time to discover an alignment failure is before your DMARC policy enforces rejection.

FAQ

Why does DMARC fail when SPF and DKIM both pass?
Because DMARC requires alignment, not just individual authentication passes. SPF can pass for a different domain than your From header. DKIM can sign with a different domain than your From header. Both must also pass alignment to satisfy DMARC. This two-layer check is intentional: it prevents attackers from sending email through an authorized third-party service while impersonating your domain.

Can alignment fail for only some recipients?
Yes. Alignment failures produce consistent results across receivers, but if some of your legitimate email passes alignment and some does not, it means some of your sending infrastructure is configured correctly and some is not. Check whether different teams, services, or platforms are using different sending paths.

What is the most common cause of alignment failure after a migration?
Third-party sending services that do not use custom DKIM signing. If you have added a new email service for transactional email, marketing, or automation in the past 30 days, check their DKIM configuration first. This is the single most likely culprit when SPF and DKIM pass but DMARC fails.

Should I move to p=reject as soon as alignment is fixed?
Not immediately. Run at p=none for at least one full reporting cycle (24-48 hours for most receivers) to confirm that your aggregate reports show consistent pass rates across all legitimate sources. When you see zero alignment failures from legitimate senders for multiple consecutive days, you are ready to move to p=quarantine first, then p=reject.

How does DMARCFlow help during a migration?
DMARCFlow monitors your aggregate reports continuously and alerts you when alignment changes or when new failure patterns appear. During a migration, when you are making active changes to your sending infrastructure, having automated alerts means you do not have to remember to check reports manually. You get notified when something breaks instead of discovering it when email delivery starts failing.