Introduction

A Microsoft 365 SPF problem after a DNS migration usually means the domain is now answering with the wrong TXT record, more than one SPF record, or no Microsoft 365 sender include at all. The fix is not to keep adding TXT records until a checker turns green. The real job is to verify the live authoritative zone and publish one valid SPF policy for the service that is actually sending mail.

Symptoms

  • Messages sent through Microsoft 365 fail SPF checks or show spf=fail in headers
  • Mail lands in spam after moving DNS hosting or changing nameservers
  • Some recipients accept the message while others reject it
  • Microsoft 365 mail flow looks normal, but domain authentication warnings appear
  • DNS checkers return different SPF answers during or after the migration

Common Causes

  • The new DNS provider does not have the Microsoft 365 SPF TXT record
  • The zone contains multiple SPF TXT records for the same hostname
  • The domain still publishes an old provider include instead of include:spf.protection.outlook.com
  • The migration copied MX records but missed mail-authentication records
  • Cached answers or mixed delegation make some resolvers see the old zone and others the new one

Step-by-Step Fix

  1. Confirm which hostname should publish the SPF record, usually the root domain, so you are fixing the right location.
  2. Query the live authoritative nameservers and verify the current TXT answer instead of relying only on the DNS panel view.
  3. Check whether the domain now has more than one SPF TXT record, because multiple SPF policies cause evaluation failures.
  4. Compare the live SPF value with Microsoft's current sender guidance and confirm include:spf.protection.outlook.com is present if Microsoft 365 is sending mail.
  5. Remove obsolete SPF records from previous providers instead of leaving multiple sender policies in place.
  6. Verify whether any third-party sender also needs authorization, then merge those senders into one valid SPF record instead of publishing separate entries.
  7. Send a controlled test from Microsoft 365 and inspect the full headers to confirm SPF now passes on the message that actually matters.
  8. Keep watching mail headers, spam placement, and resolver answers until the DNS migration fully settles and the domain returns one consistent SPF result everywhere.
  9. Document the complete mail DNS set before the next migration so the next cutover includes SPF, DKIM, DMARC, and provider-specific records together.