Migrate to M365 or Google Workspace without a weekend outage

A dig at one domain's MX record this morning came back with 13,431 seconds still to run. Just under four hours. That domain's owner could change the MX at nine in the morning and the sending world would carry on delivering to the old server until nearly one in the afternoon, and not one thing would be wrong.

That number is why the weekend gets booked. It is also the wrong thing to book, because the four hours are not the outage. The outage is the mail that arrives at the old server during those four hours and finds nobody home.

The risky day is the Wednesday before, not the Saturday

The change you make on cutover day is a single record edit. The change that decides whether anyone notices is the TTL you published days earlier, and if you skipped it, no amount of Saturday fixes it.

A TTL is not a countdown you can shorten. It is a promise you already made to every resolver that asked. Publish MX 14400 on Monday and a resolver that queried at 08:00 on Tuesday will use that answer until midday, whatever you edit in between. Lowering the TTL only affects the resolvers that ask after you lower it.

So the lead time is the rule, not the value:

Publish the low TTL at least one full old-TTL period before you touch anything else. Old TTL four hours, lower it at least four hours ahead. Old TTL 24 hours, lower it the day before. I give it a day either way because it costs nothing and I would rather not do the arithmetic under pressure.

The running order that falls out of that table:

1. A week ahead: read a week of DMARC aggregate reports and list every system that sends as you.
2. Two days ahead: publish the new platform's SPF include and DKIM records alongside the old ones. Nothing changes for live mail.
3. A day ahead: lower the TTL on every record you plan to touch, and create any record that does not exist yet.
4. A day ahead: set the new platform to relay unmatched recipients rather than reject them, build the connector or route that says where those people actually are, and test it with a real message.
5. Cutover: change the MX. Confirm your own nameservers first, then watch the caches drain.
6. A week later, once the old platform has stopped seeing traffic: close the relay, delete the endpoints you no longer use, and put the TTLs back up.

What should I lower it to?

300 seconds, and not for the reason people assume.

Five minutes is not about speed. It is about the size of your mistake. If the new MX is wrong, or the tenant is not ready, or somebody typed mail.protection.outlook.com without the <MX token> prefix Microsoft assigns to the domain, a 300-second TTL means the rollback is live before you have finished apologising. A 14400-second TTL means you own the mistake until teatime.

Two limits ride along with that. Some DNS hosts will not accept a TTL as low as you want. The floor varies by host and it is not something you can argue with, so find out what yours allows before cutover day rather than at 08:55. And a short TTL means every resolver on earth re-asks your nameservers constantly, so put the TTL back up to something sensible a day or two after the dust settles. That last step gets skipped more often than it gets done, which is why so many production domains are still serving 300-second records years after the migration that set them.

Lower all of them, not just the MX. The autodiscover CNAME, the SPF TXT, the DKIM records, the A record for webmail if you have one. Every record you plan to change, plus the ones you might have to change when something surprises you.

One exception, and it is Microsoft's own. They ask for at least 3600 seconds on the DKIM CNAMEs and name 60 or 300 as too low. The failure mode there is not a stale record. It is constant re-lookups that time out, which reaches the receiver as an intermittent dkim=temperror16. That is not the trade-off the other records are making. You publish DKIM days early and never touch it on the day, so there is no rollback to keep small. Leave those at an hour.

The one TTL you cannot lower is the delegation

Your NS records at the parent are not yours to shorten. The delegation lives in the parent zone, and the TTL on it belongs to whoever runs that zone. Your own copy of the NS records, in your own zone, is not the one a resolver follows to find you.

How long can a nameserver change take to clear?

Longer than you would like, and the only way to know is to ask the parent directly. Two delegations, queried at their TLD's own servers this morning:

dig +noall +authority NS tamingdns.com @a.gtld-servers.net
tamingdns.com.  172800  IN  NS  aiden.ns.cloudflare.com.

dig +noall +authority NS osh.co.za @ns.coza.net.za
osh.co.za.      7200    IN  NS  ns1.dns-parking.com.

172800 seconds and 7200 seconds12. That is how long a resolver may keep asking your old nameservers after you change registrars or DNS hosts.

Those are the values those two delegations were returning this morning, not properties of .com and .co.za. Run the same query against your own domain rather than assuming a number, because it is the parent's answer that governs, and the parent can change it without telling you.

Note the @a.gtld-servers.net and @ns.coza.net.za in those commands. Ask a normal resolver for the same NS records and you get the copy inside your own zone, which is a different record with its own TTL. Asked at the zones' own nameservers on 5 September 2026, both of those domains answered 86400. Asked at 8.8.8.8 in the same minute, both answered 21600. So did com. itself, whose parent publishes 172800. That figure is the resolver's, not the zone's13. Neither of those numbers is the one that governs a nameserver change. What holds generally is that the delegation TTL runs far longer than anything in your own zone, and lowering things in your own zone does nothing to it.

Our take: never move DNS hosting and mail hosting in the same window. If you change nameservers on Saturday morning and the MX on Saturday afternoon, then for as long as that delegation TTL runs some resolvers read the new zone and some read the old one, you cannot tell which is which from the outside, and every symptom is intermittent. Move DNS hosting first, leave the zone byte-identical, wait out the parent TTL, confirm both sets of nameservers agree, and only then start on the mail. Two boring weekends beat one interesting one.

If you must do both, keep the old zone alive and identical on the old nameservers for a week afterwards. It costs a hosting fee and it removes the entire failure mode.

Both platforms have to accept mail on the day, and by default only one does

The second failure in a migration is not a DNS fault at all. It is an accepted-domain setting.

Once resolvers start using the new MX set, new delivery attempts arrive at the new platform1, and that means every address at your domain, not only the ones you have moved. If you have migrated eleven of forty mailboxes, the new tenant does not have the other twenty-nine, and it will not shrug and pass them along. It will reject them, because you told it the domain was its own.

Do not read across those two rows. They solve the same problem in different places, and the work each one asks of you is different.

Microsoft has one switch on the accepted domain, and it has a name for what Authoritative does to your unmigrated users: setting it turns on Directory-Based Edge Blocking, which rejects mail for recipients it does not know at the service perimeter2. That is the hard rejection, and it arrives the moment the MX flips.

Internal Relay turns that off, and it is only half the job, because it does not know where those people are. Microsoft is unusually direct about the other half: if you select internal relay, you "must create a connector for mail flow from Microsoft 365 or Office 365 to your on-premises email server; otherwise recipients on the domain who are not hosted in Microsoft 365 or Office 365 won't be able to receive mail on your own email servers". Set the switch, skip the connector, and you have swapped one rejection for another.

Google has no single equivalent switch. You might use default routing, split delivery or dual delivery, depending on how you are running the migration. The email routing and delivery options page is where that choice gets made. Pick the mechanism deliberately rather than hunting for the setting that looks like Microsoft's. Go by what each one does, not by the menu name. Those pages move. The one linked here answered at support.google.com/a/answer/2685650 when this was written and 301-redirects to a different host entirely as of 5 September 20263.

How long should the old platform keep accepting mail?

A week. Not four hours, and not until the propagation checker goes green.

A sender whose resolver still holds the old MX connects to the old server directly. Nothing hands that message on for you. So the old platform has to stay able to accept it and route it onwards, with the mailboxes still in place, for as long as stale caches might still be pointing there. Something out there caches badly, and it is always something you cannot see or contact. The version of this that costs you a Monday is the old server left running with nothing configured to move the mail on, because the propagation checker said the change was complete, and forty hours of quiet delivery to a mailbox nobody was reading.

Plain forwarding is the obvious way to do that and it is not free, and the reason is worth getting the right way round. SPF is evaluated against the address of the last server to send, so when your old platform forwards a message onward while keeping the original envelope sender, the receiver checks your forwarder's IP against the original domain's SPF record and does not find it. RFC 7208 §10.3 puts it as plainly as a standards document ever does: the evaluation "will fail unless mitigations" are used. Sender Rewriting Scheme is the usual mitigation, and it works by rewriting that envelope sender rather than preserving it, so a forwarder that does not do SRS is the one that breaks the check4.

Two more that cost less to prevent than to diagnose. A forward can collide with a rule at the far end and loop, and a recipient who exists on both platforms gets the message twice. Test the path with a real message before you rely on it, and read the headers on what arrives rather than trusting that it arrived.

Autodiscover outlives the migration, because nothing ever deletes it

How does Outlook pick an Autodiscover endpoint?

It works through a list of places in order and stops at the first one that hands back a payload it can read. Not the first correct one. The first one. Which places, and in what order, is not fixed across clients. Microsoft lists eight methods and says outright that Outlook uses them "depending on the client-server topology". Two of the eight turn on the version. The cached URL in the profile arrived in Outlook 2010, Direct Connect to Microsoft 365 in Outlook 2016. Microsoft's own worked example for a machine that is not joined to a domain starts at the predefined Autodiscover URLs and works down through the HTTP redirect method to the SRV lookup, with no SCP step in it5. So read the sequence out of your own client's log rather than off a diagram. What does not vary is the part that matters during a migration: an endpoint you decommissioned can still answer successfully, and a successful answer ends the search.

That is fine when the only thing answering is the platform you are on. After a migration it is rarely the only thing answering:

• Migrating to Microsoft 365, the old host's autodiscover.yourdomain.com A record, or the old control panel's endpoint at your root domain over HTTPS, is still serving a valid configuration for a mail server you have stopped using. Outlook finds it first and configures itself against the past.
• Migrating away from Microsoft 365, the autodiscover CNAME to autodiscover.outlook.com is still there, because nobody thinks to delete a record that was working. There is nothing to replace the record with. Google's own instructions for running Outlook against Workspace are to install Google Workspace Sync for Microsoft Outlook and sign in from the client. That page never mentions Autodiscover. Nothing in the setup asks you to publish a DNS record15. So the stale CNAME goes on answering, Outlook keeps asking Microsoft about a tenant your users have left, and no error appears to tell you it is wrong.

Delete the record you are not using. Publish the one you are. On Microsoft 365 that is a CNAME from autodiscover.yourdomain.com to autodiscover.outlook.com6, and the Autodiscover checker will show you every endpoint that answers, which is the point. You are looking for the ones you had forgotten about. The four ways Autodiscover breaks covers reading Outlook's own log when the external check and the client disagree.

The one thing an external check cannot see is the client cache. The cached URL in the profile is one of the eight methods in that Microsoft list, so where a client has it, a working endpoint found once can go on being used after the DNS is right, and a user who tested a laptop against the old configuration during your rehearsal may need the profile rebuilt. Expect a handful.

Publish both platforms' SPF and DKIM before you touch the MX

Authentication records are additive and cheap, so they should be in place well before cutover day, on both sides.

DKIM does not collide. Microsoft signs with selector1 and selector2, published as CNAMEs whose targets Microsoft generates for you. Domains onboarded before May 2025 point into your onmicrosoft.com initial domain; new custom domains since then use a format that points into dkim.mail.microsoft, and Microsoft says the old and new formats cannot coexist for the same selector, so read the targets out of your own tenant rather than copying a shape from an article7. Google signs with a TXT record at the selector you chose, and google is the default prefix it offers8. Different names, no conflict, both can be live for months.

SPF is the one people brace for. Both providers publish the include you would expect, Microsoft spf.protection.outlook.com and Google _spf.google.com, and carrying both at once is a documented arrangement rather than a bodge.

Count the lookups yourself though, because the answer moved. Both records in full, as they resolved on 27 August 2026, pulled twice and cross-checked: once with dig, and once through the DNS lookup tool on this site. The two agreed character for character10.

dig +short TXT spf.protection.outlook.com
"v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15 ip4:52.102.0.0/16
 ip4:52.103.0.0/17 ip4:104.47.0.0/17 ip6:2a01:111:f400::/48
 ip6:2a01:111:f403::/49 ip6:2a01:111:f403:8000::/51
 ip6:2a01:111:f403:c000::/51 ip6:2a01:111:f403:f000::/52 -all"

dig +short TXT _spf.google.com
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56
 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56
 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"

Count the mechanisms. Every one is an ip4, an ip6 or the final all, and none of those costs a lookup under RFC 72089. Neither record reached for another include, a, mx, exists or redirect, so on the day of that check the two include mechanisms cost one lookup each and nothing underneath them, which is two of your ten. Older write-ups quote five or six because _spf.google.com used to chain out to three _netblocks records, and it no longer does.

Treat that as a reading taken on one morning, correct when it was tested and not guaranteed after. Both records belong to their vendors and either can grow an include again without telling you, at which point your total goes up without you editing anything. Re-run the two commands against your own SPF before you commit to a design that has no headroom.

The caution is DMARC, not SPF. If you are at p=reject and a third-party sender was aligned by DKIM on the old platform and is not yet configured on the new one, it starts failing on the day the mailboxes move, and it is usually something nobody thinks of as email, like the invoicing system. Read a week of your aggregate reports before you cut over, not after. Take the staged path from p=none to p=reject after the migration has settled, not during it.

The record is live the moment your nameserver says so

There is no global sync and nothing is spreading. Your authoritative server answers correctly the instant you save, and every other resolver is simply serving what it cached earlier until that cache expires. Two different questions, so ask them separately:

dig MX yourdomain.co.za @ns1.yourdnshost.com     what you actually published
dig MX yourdomain.co.za @1.1.1.1                 what one resolver still believes
dig MX yourdomain.co.za @8.8.8.8                 what a different one believes

The first must be right before you go any further. If it is wrong, nothing downstream matters. The others tell you how far through the TTL window you are, and the number to watch is the TTL counting down in each answer, not the record itself.

The negative cache is the one nobody lowers. If somebody looked up autodiscover.yourdomain.com before you created it, the resolver cached the absence of that name, and that cached absence has nothing to do with the TTL on the record you go on to publish. RFC 230811 derives it from the SOA instead: the lesser of the SOA's MINIMUM field and the TTL on the SOA record itself. So the resolver keeps answering "no such name" until that timer runs out, whatever you have since put in the zone. Two zones checked with dig SOA on 5 September 2026 returned MINIMUM values of 600 and 1800 seconds14. A brand-new record can look broken to exactly one resolver for that long after you publish it, while behaving perfectly everywhere else. Create the records that do not exist yet a day early, before anything has a reason to ask for them.

What it will look like when it goes wrong

The symptom will not point at DNS. The first hour of a bad cutover gets spent in the wrong console.

It will look like a mailbox problem. One user says mail stopped arriving, three others say it is fine, and the three who are fine are the ones whose senders happen to sit behind a resolver that has already expired your old MX. Nobody has a mailbox fault. You are watching one TTL window from the inside.

It will look like an Outlook problem. A laptop that will not connect, or that connects and shows an empty mailbox, is usually a client that found an Autodiscover endpoint you meant to delete. Before rebuilding the profile, go and look at what is answering on autodiscover.yourdomain.com.

And it will look like a spam problem. Mail that suddenly fails authentication on the day of the move is far more likely to be a sender you forgot to re-authorise than a reputation collapse. Check the SPF and DKIM result on a failing message before you go anywhere near a postmaster console.

Go and look at the TTL on your MX record right now, before you have booked anything. If it comes back in the thousands of seconds, that is the window you have to drain after you lower it and before the new value can be relied on, and the preparation goes in the calendar that far ahead of the cutover.

What this article was checked against

Every claim above was verified against a primary source before publication, on 27 August 2026, and re-checked against those sources on 5 September 2026. Vendor records and console settings change, so re-run the commands rather than trusting the date on this page.

1. A domain may publish more than one MX record, and a sender picks from the set by preference. — RFC 5321 §5.1 ↩
2. Setting an accepted domain to Authoritative enables Directory-Based Edge Blocking, and Internal Relay requires a connector to the other mail system. — Manage accepted domains in Exchange Online ↩
3. Google's routing mechanisms: the page names Default routing, split delivery and dual delivery, and recommends split delivery with a small group when migrating to Gmail from another server. Checked 5 September 2026, when the original support.google.com/a/answer/2685650 URL 301-redirected to knowledge.workspace.google.com. — Email routing and delivery options for Google Workspace ↩
4. SPF is evaluated against the address of the “last” sending SMTP server, so where a mediator retains the original message’s address the evaluation “will fail unless mitigations such as those described in Appendix D are used”. Appendix D.2 gives the mitigation as rewriting the MAIL FROM into the mediator’s own domain. — RFC 7208 §10.3 ↩
5. Outlook's eight Autodiscover methods, used "depending on the client-server topology", two of them gated on client version. — Unexpected Autodiscover behavior with registry settings ↩
6. The Autodiscover CNAME target autodiscover.outlook.com, and the MX form <MX token>.mail.protection.outlook.com, whose token the page tells you to look up per domain under Microsoft 365 admin > Domains. — External DNS records required for Microsoft 365 ↩
7. Microsoft signs with selector1 and selector2, published as CNAMEs. The target format changed in May 2025: existing domains keep the …onmicrosoft.com form, new custom domains use ….<char>-v1.dkim.mail.microsoft, and the two cannot coexist for one selector. Take the exact target values from your own tenant rather than from any article. — Set up DKIM for Microsoft 365 ↩
8. Google publishes the DKIM public key as a TXT record at the selector; the page calls google the default prefix selector and shows the host as google._domainkey. — Set up DKIM for Google Workspace ↩
9. The ten-lookup limit, and which mechanisms count against it: include, a, mx, ptr and exists, plus the redirect modifier. The all, ip4 and ip6 mechanisms do not. — RFC 7208 §4.6.4 ↩
10. Both provider SPF records, resolved 27 August 2026 with dig and again through this site's own lookup tool. The two runs agreed. — DNS lookup tool · dig +short TXT spf.protection.outlook.com ↩
11. A negative answer's TTL is taken from the minimum of the SOA MINIMUM field and the SOA record's own TTL. — RFC 2308 §5 ↩
12. Delegation TTLs observed 27 August 2026 by querying each parent nameserver directly, which a recursive resolver cannot answer for you. Values belong to those two delegations on that morning, not to the TLDs. — DNS lookup tool · dig +noall +authority NS <domain> @<parent-ns> ↩
13. In-zone NS TTLs read at the zones' own nameservers on 5 September 2026: 86400 for both. The same query at 8.8.8.8 returned 21600 for both and for com., whose parent publishes 172800, so that value is the resolver's rather than the zone's. — dig +noall +answer NS <domain> @<its-own-ns> · dig +noall +answer NS <domain> @8.8.8.8 ↩
14. SOA MINIMUM values observed on two zones, 5 September 2026: 600 and 1800 seconds. Two readings, not a rule — run it against your own zone. — dig +noall +answer SOA <domain> @<its-own-ns> ↩
15. Google's instructions for using Outlook with Google Workspace are to install GWSMO and sign in from the client. Read 5 September 2026: the page describes no Autodiscover step and no DNS record. — Get started with GWSMO ↩
16. Microsoft asks for at least 3600 seconds on the DKIM CNAME records, listing a TTL “set too low (for example, 60 or 300 seconds)” as the cause of intermittent dkim=temperror or dkim=fail key-lookup timeouts. Read 6 September 2026. — Set up DKIM for Microsoft 365 ↩

Check what your MX record says today.