Home › Blog › Tenant migration
Guide · Tenant migration
Nothing bounces, the message trace says delivered, and everything goes to junk. The DKIM records are tenant-specific and still describe the tenant you left. What each of the three records does, what has to change, and the five-minute test on cutover day.
By Alex Makey · 6 September 2026 · 6 min read · Verified against Microsoft documentation, September 2026
Monday after a tenant migration, outbound mail lands in spam. Nothing is bounced, nothing errors, the Microsoft 365 message trace says delivered. The problem is not deliverability; it is that the three DNS records that vouch for your mail still describe the tenant you left. Here is what each record does, what has to change, and how to check.
SPF lists which servers may send mail for your domain. Microsoft 365 is one entry, include:spf.protection.outlook.com, and it is the same for every tenant — so SPF usually survives a migration untouched. Where it breaks: a domain that also sends through the old on-premises relay, a marketing platform, a ticketing system, each needing its own include, and a record that has grown past the ten-lookup limit, which makes the whole thing fail silently.
DKIM signs each outbound message with a key that lives in your tenant, and publishes the public half in DNS as two CNAME records. The CNAMEs are tenant-specific. selector1._domainkey.contoso.com points at selector1-contoso-com._domainkey.<initial-domain>.onmicrosoft.com, where the initial domain is the target tenant’s. Move the domain to a new tenant and the old CNAMEs point at the old tenant’s keys. Every message is now signed with a key the DNS does not vouch for, and DKIM fails.
DMARC tells receivers what to do when SPF or DKIM fail, and where to send reports. It does not change with the tenant. But if the policy is p=reject or p=quarantine — as it should be — then a DKIM failure after migration is enforced immediately. Which is exactly the Monday-morning symptom.
1. In the target tenant, enable DKIM for the domain. Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select the domain. The portal shows the two CNAME records it needs. They will not resolve yet.
2. Publish the two new CNAMEs at your DNS provider, replacing the old ones. selector1._domainkey and selector2._domainkey, each pointing at the target tenant’s value from step 1.
3. Wait for propagation, then enable signing. Back in the DKIM page, turn the domain on. If the CNAMEs have not propagated, the portal refuses. With TTLs lowered beforehand this is minutes; otherwise up to an hour.
4. Check SPF. nslookup -type=txt contoso.com. Confirm the Microsoft include is present, remove includes for systems that no longer send, and count the lookups — over ten and receivers ignore the record.
5. Check DMARC. nslookup -type=txt _dmarc.contoso.com. Confirm the reporting address still exists in the new tenant. If it pointed at a mailbox in the old tenant, reports go nowhere and you lose the visibility that would have told you about step 2.
6. Test from outside. Send to a Gmail address and open the headers. Look for dkim=pass, spf=pass and dmarc=pass. If DKIM shows fail with the domain of the old tenant in the selector, the CNAMEs have not propagated or step 3 was skipped.
Doing this on Monday instead of Saturday. The DKIM CNAMEs can be published for the target tenant in advance if signing is enabled there first; the domain does not have to be live in the target to prepare the records. Prepare on the day, enable the moment the domain verifies.
A DMARC policy that was set to reject “for security” and never monitored. Reject is right. Reject without reading the reports is how you find out about a broken DKIM from your customers.
Third-party senders that were authorised for the old tenant. A signature tool or a security gateway that sat in the mail path and signed on the tenant’s behalf. It needs reconfiguring for the new tenant or removing from the path, and SPF adjusting either way.
Subdomains. Each subdomain that sends mail has its own DKIM selectors and its own SPF. A migration that remembers the main domain and forgets notifications.contoso.com breaks the automated mail nobody thinks about until it stops.
Send one message from the migrated domain to an external mailbox you control. Read the headers. Three passes and you can stop thinking about it. One fail and you have found it before the customers do.
One email a month, at most
Postmortems, timelines, licensing changes that cost people money. If a month has nothing worth your time, you hear nothing.
Please enter a work email address.
Done. Unsubscribe by replying to any email; we will not argue.
Related questions
Almost always DKIM. The two DKIM CNAME records in DNS are tenant-specific; after a domain move they still point at the old tenant’s keys, so every message fails DKIM, and a DMARC policy of quarantine or reject enforces the failure.
Usually not: the Microsoft include is the same for every tenant. Check for includes belonging to systems that no longer send, and confirm the record is under ten DNS lookups.
In the Defender portal under email authentication settings, select the domain to get its two CNAME values, publish them at the DNS provider, wait for propagation, then enable signing for the domain.
Yes. Enable DKIM for the domain in the target tenant to get its CNAME values in advance and have them ready to publish the moment the domain verifies in the target.
Send a message from the migrated domain to an external mailbox you control and read the headers: dkim=pass, spf=pass and dmarc=pass. A DKIM failure naming the old tenant in the selector means the CNAMEs have not been updated or signing was not enabled.
Rather not do this yourself?
Describe the situation and you get back a sequence, an honest view of what will be slow, and a fixed price — usually within one business day. Or ask one question and get one answer.