Migrate a client to Microsoft 365 mail

This is the change that ends up in more post-incident reviews than any other, and almost never because the plan was wrong. It goes wrong because one hostname was typed instead of pasted, and because DNS does not tell you when a hostname does not exist.

# The day before

1. Lower the TTLs Drop the MX, SPF TXT and autodiscover records to 300 seconds at least 24 hours before the cutover. This is the single most valuable thing on the list and the one most often skipped, because its benefit only appears when something goes wrong.
2. Collect the values from the tenant, not from a document In the Microsoft 365 admin centre, open Settings → Domains → your domain → DNS records. Copy each value. A handover document, a previous ticket or a similar client's record is not a source.
3. Check what SPF already says If the domain already has an SPF record you are merging into it, not replacing it. Anything currently sending — a CRM, an invoicing system, a scanner in the accounts office — has to survive the change.

# The change itself

1. Compose it as one change, not four MX, SPF, autodiscover and DKIM belong in a single change so they are checked together, approved together and recorded together. The Microsoft 365 template composes them for you.
2. Paste the MX target and then check it character by character DNSMentor requires this and will not let you skip it. The tenant hostname follows a pattern derived from the domain, which is exactly what makes a near-miss so easy: contoso-co-uk.mail.protection.outlook.com is right, contoso-couk is not, and neither produces an error anywhere.
3. Read the check results properly Expect a warning that removing the old MX stops mail to the previous host, and the mandatory MX verification warning. If you see an SPF error, you have replaced the record rather than merged into it.
4. Look at the simulation The resulting zone is shown before anything is written. Confirm the old MX is gone, the new one is present, and the SPF record is one record containing every sender the client still uses.
5. Apply DNSMentor re-reads live state first, writes through the provider API, then queries the records independently from outside.

# The records, for reference

# Afterwards, before you close the ticket

• Confirm DNSMentor shows the change as verified, not merely applied. Applied means the provider accepted it; verified means an independent query saw it.
• Enable DKIM signing in the Microsoft 365 admin centre. Publishing the CNAMEs does not switch signing on, and the two look identical from DNS.
• Send a message in from an external address and confirm it arrives. Outbound proves nothing about MX.
• Raise the TTLs back to 3600 once you are satisfied, a day or two later.
• Paste the generated write-up into the client ticket.