What is an MX record cutover?
An MX record cutover is the DNS change that tells the rest of the internet to deliver your email to Google Workspace. MX stands for mail exchanger. Every domain that receives email has one or more MX records, and sending servers look them up to decide where to deliver a message. When you replace your old MX records with Google's, new mail starts flowing to Gmail.
The change itself takes a few minutes at your DNS host. What takes planning is the timing, because the old and new systems overlap for a short window while the change spreads. For how the cutover fits into the wider project, see how to plan a Google Workspace migration.
When should you change your MX records?
You should change your MX records after the bulk copy is complete and your users are ready to sign in to Google Workspace. Changing too early means people open an empty Gmail inbox while their history is still moving. Changing too late means the overlap drags on and people stay unsure which system to use.
In practice, the order is: copy existing data, test with a pilot group, send the day-before message to staff, change the MX records, then run the final delta migration. If you are moving people in batches, the timing is different. A staged migration usually keeps MX records on one system and routes mail for moved users to the other until the last batch.
How do you prepare DNS before the cutover?
You prepare DNS by confirming access, lowering the TTL, and recording your current settings. Do these a few days before the switch:
- Confirm you can sign in to the DNS host for your domain. This is often your registrar, but not always.
- Take a screenshot or export of every current DNS record so you can restore anything quickly.
- Lower the TTL (time to live) on your MX records to a short value, such as five minutes, at least a day before the cutover. TTL controls how long other servers cache the record.
- Verify your domain in the Google Admin console, if you have not already.
- Copy the exact MX values the Admin console shows for your domain, rather than values from an old article.
What happens to email during propagation?
During propagation, some sending servers still have your old MX records cached and deliver to the old system, while others already deliver to Google. This is normal, and it is short when the TTL is low. It is also why you keep the old mailboxes active through the switch.
Messages that land in the old system during this window are not stranded. The delta pass copies them into Gmail after the change settles. Once the delta pass finishes and test messages arrive in Gmail consistently, the cutover is complete. Ask users to report anything that looks missing in the first few days, as covered in our guide to the first 30 days after a migration.
What other DNS records change at the same time?
Your email authentication records should change at the same time, so receiving servers trust mail sent from Google. Add Google to your SPF record, turn on DKIM signing in the Admin console and publish the key it gives you, and set up or review your DMARC policy. Keep the old provider in your SPF record until you no longer send mail through it. Our guide to SPF, DKIM, and DMARC for Google Workspace covers each record.
Leave unrelated records, such as the ones for your website, alone unless you are moving those too. Changing several things at once makes problems harder to trace.
Next step
Our migration plans and process include the MX change and the delta pass, so your team does not have to time the switch alone.
Frequently asked questions
Can we undo an MX change if something goes wrong?
Yes. You can point the MX records back to the old system, and mail will follow once caches expire. This is one reason to keep a short TTL and leave the old mailboxes active through the switch. A tested pilot group makes a rollback much less likely to be needed.
Do we need to move our domain to a new registrar?
No. Your domain can stay with its current registrar or DNS host. You only need to edit the records there. Moving a domain to a new registrar in the middle of a migration adds risk, so we recommend leaving it in place until after the cutover.
