Moving MX tells the world where to deliver incoming mail. It says nothing about who may send mail for your domain. That is what SPF, DKIM and DMARC are for, and forgetting them is the most common reason mail lands in spam after a migration.
SPF: who may send
SPF is one TXT record on the domain listing the servers allowed to send for it. After a migration it must include the new provider:
- Google Workspace:
v=spf1 include:_spf.google.com ~all - Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all
Rules that trip people up:
- There must be exactly one SPF record. Two records make both invalid; merge them into one.
- Keep the old provider in SPF until nothing sends through it any more (for example a website contact form), then remove it.
- SPF allows at most 10 DNS lookups; long chains of
include:can break it.
DKIM: proof the message was not changed
DKIM signs each message with a key published in DNS. Each provider gives you its own record(s):
- Google Workspace: generate the key in the Admin console (Apps → Gmail → Authenticate email) and publish the
google._domainkeyTXT record. - Microsoft 365: publish the two CNAME records
selector1._domainkeyandselector2._domainkey, then enable DKIM signing in the Defender portal.
DMARC: what receivers should do on failure
DMARC ties SPF and DKIM to the visible From address and tells receivers what to do with mail that fails. Start gently and tighten later:
v=DMARC1; p=none; rua=mailto:[email protected]while you check reports.p=quarantineonce all your senders pass.p=rejectwhen you are sure.
Check it
The free MX/SPF/DMARC checker shows the records a domain publishes now and warns about the usual mistakes, including a missing new-provider include and duplicate SPF records. Then send a message to a Gmail address, open Show original, and look for SPF: PASS, DKIM: PASS and DMARC: PASS.