SPF, DKIM & DMARC After a
Microsoft 365 Migration

Why this matters more during a migration than at any other time

Your existing SPF, DKIM, and DMARC records are built around your current sending infrastructure — your old mail server, your previous provider, whatever tools currently send email on your domain's behalf. The moment you migrate to Microsoft 365, your actual sending infrastructure changes, but your DNS records don't update themselves. If nobody updates them to reflect Microsoft 365 as an authorized sender, mail servers receiving your email start failing authentication checks — and increasingly, failed authentication means the spam folder or an outright rejection.

This is not a rare edge case. It's one of the most common causes of post-migration email problems, and it's almost entirely preventable with correct DNS configuration before cutover.

SPF: authorizing Microsoft 365 to send on your behalf

SPF (Sender Policy Framework) is a DNS TXT record listing which mail servers are allowed to send email for your domain. Receiving servers check the sending server's IP address against this list. If it's not there, the message fails SPF.

Migrating to Microsoft 365 means adding Microsoft's sending infrastructure to your SPF record:

v=spf1 include:spf.protection.outlook.com -all

Two mistakes happen constantly here. The first is simply forgetting to add Microsoft's include statement, leaving the domain still pointing only at the old provider. The second — more subtle — is ending up with two SPF records instead of one merged record. DNS only permits a single SPF TXT record per domain; if a leftover record from the old provider isn't removed, most receiving servers treat this as a permanent SPF failure, not a partial pass. Every legitimate migration must merge into one record, not add a second.

If you're moving off GoDaddy-managed Microsoft 365 specifically, this is worth double-checking: GoDaddy's infrastructure often leaves a secureserver.net reference in the SPF record, which needs to be removed or updated once you're no longer routing mail through it. Our guide on GoDaddy Microsoft 365 limitations covers how to spot this and other GoDaddy-specific DNS markers.

DKIM: signing your outbound email

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages, which the receiving server verifies using a public key published in your DNS. This proves the message wasn't altered in transit and genuinely originated from an authorized source.

Microsoft 365 provides two DKIM selectors (CNAME records) that need to be published in your domain's DNS, then explicitly enabled in the Microsoft 365 Defender portal — publishing the DNS records alone does not activate DKIM signing. This two-step requirement (DNS record, then portal activation) is the most commonly missed step in the entire authentication setup. Without it, Microsoft 365 falls back to a default DKIM signature under the onmicrosoft.com subdomain rather than your own domain, which weakens your authentication posture and can affect how DMARC evaluates your mail.

DMARC: telling receivers what to do when checks fail

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that sits on top of SPF and DKIM. It tells receiving servers what to do if a message fails those checks — quarantine it, reject it outright, or take no action — and it can generate reports showing who is sending email using your domain, which is genuinely useful for spotting spoofing attempts.

A basic DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The p=none policy is deliberately conservative — it monitors and reports without blocking anything, which is the right starting point during and immediately after a migration while authentication is being verified. Moving to p=quarantine or p=reject too early, before SPF and DKIM are confirmed working correctly, can cause legitimate email from your own domain to be silently dropped. That transition should happen deliberately, after a period of clean reporting — not as a same-day change alongside the migration itself.

The sequencing that avoids deliverability problems

The order these changes happen in matters as much as the changes themselves:

• Before cutover — Add Microsoft 365's SPF include, publish the DKIM CNAME records, and set (or confirm) a permissive DMARC policy. This can be done ahead of the actual mailbox cutover since these are DNS additions, not replacements, at this stage.
• At cutover — Remove or merge any SPF entries tied to the old provider so only one SPF record remains, valid and correctly scoped to Microsoft 365 and any other legitimate senders (marketing platforms, CRM systems, invoicing tools).
• Immediately after cutover — Enable DKIM signing in the Microsoft 365 Defender portal for the domain, and verify it's active rather than assuming the DNS records alone are sufficient.
• Two to four weeks after cutover — Review DMARC aggregate reports to confirm all legitimate senders are passing authentication, then tighten the DMARC policy from p=none toward p=quarantine and eventually p=reject if appropriate for the organisation.

Third-party senders are the part people forget

Most businesses send email from more than just Microsoft 365 — invoicing software, CRM platforms, marketing tools, and helpdesk systems often send on the same domain. Each of these needs to be included in the SPF record and, ideally, configured with its own DKIM signing where the platform supports it. A migration is the natural point to audit this list, because it's exactly when the SPF record is already being touched. Leaving a third-party sender out of the updated SPF record is a common cause of a support team discovering, weeks later, that automated emails from their helpdesk system are suddenly landing in spam.

Getting this right as part of your migration plan

Email authentication should be a line item in the migration plan, not an afterthought discovered when someone reports a deliverability issue. Our Microsoft 365 migration checklist covers DNS preparation as part of the broader pre-migration process — SPF, DKIM, and DMARC configuration fits directly into that DNS and domain preparation phase.

If you're planning a migration and want DNS and authentication handled correctly from day one, CloudyNex builds this into every email migration and IMAP email migration engagement as a standard part of the process, not an optional extra.