G Suite MX Record Cutover Best Practices
Mx change prerequisites and cut over best practices before Go Live. Mail exchange record for Go live in GSuite.

Introduction
For customers migrating to G Suite, moving existing Mail Exchange (MX) DNS records to G Suite for hygiene and email routing is often a prerequisite. During this change, our goal is to limit user impact as much as possible. The steps mentioned here will help to meet up your goal. We will focus on the MX record change in three sections:
-
Best Practices & Watch Points: Preparing organizations for the cutover, and ensuring proper understanding of common questions that arise.
-
Test & Deploy: Testing your configuration and making the cutover event run as efficiently and effectively as possible.
-
Rollback: Contingency planning in case of issues.
We need to take several preparation steps prior to MX cutover. These guidelines will make the activity run smoothly.
G Suite Email Settings
-
Google recommends a thorough review of the G Suite Admin Panel Email Settings. It is very important to understand feature translation from existing email hygiene systems, as well as newly available features and gaps that may exist between products.
Common topics to address during this review include:
-
Configuring Google Email Settings
-
Adding Email Hosts
-
Default Routing
-
Split Delivery vs Dual Delivery
For details on the above settings, please check the Email Routing Support Help Center Guide.
Best Practices & Watch Points
SPF Record Creation
Google recommends creating (or updating) the Sender Policy Framework (SPF) record(s) to ensure valid authentication for outbound email. Google recommends making this change as soon as possible following the decision to move to G Suite. We can See SPF records for the setup instructions when creating an SPF record in association with G Suite.
Hardcoded MX Records
Despite internet best practices, some systems/vendors use products which hardcode mail routes to servers. Be sure to identify these DNS vendors and reach out to them to ensure they update their systems as these changes occur. It is best to begin the identification of such systems as soon as possible following the decision to move to G Suite.
TLS and Encryption Considerations
Google Email Settings is equipped with opportunistic TLS meaning that messages will be delivered or received via a secure channel if the corresponding receiving server is also configured for TLS as well. This is a built-in feature and does not need to be configured. In addition, Google Email Settings has options for transport layer security (TLS), secure email connections to enforce TLS policy. Be sure to set any dispositions for ‘TLS Controls’ for domains where all traffic must be secured for reasons such as compliance. A description of ‘TLS Controls’ can be found here Secure transport (TLS) Compliance setting.
Time To Live (TTL) of DNS Records
TTL records are a mechanism to define how long a DNS record is valid. Once the TTL period has expired for a given DNS record, external systems will have to re-validate (not loading from cache). Updating to a lower value TTL, ahead of time, is a vital part of making the MX switch run efficiently. Not properly updating TTL’s ahead of time can cause long delays and misrouted traffic during the MX change event.
It is best to make the TTL’s value as low as possible. One example would be setting them to 300 (5 minutes) for all domains at least 2 weeks prior to the MX cutover.
Network Configuration
Google recommends allowing email only from Google IP’s into your legacy network. If you need to allow mail from trusted sources for your G Suite domain, see instructions for adding an Inbound Gateway found here. Please also see the Creating SPF record to update the SPF Record to include Google IP ranges.
Implementation Procedure
Our cutover goal is to realize a seamless change of email delivery to both G Suite and Legacy users. Directly following cutover, tests will be performed to validate the changes made for the domain(s). It is vital to ensure all of the setup and watchpoints have been taken into account before proceeding with this change.
We recommend the following participants in the Testing phase and conference meeting:
-
DNS Administrator
-
Network Administrator
-
Firewall Administrator
-
Email/Messaging Administrator
-
Google Partner Project Team Lead (For LCS)
Testing and Validation Steps:
Alternatively, they can be viewed using any web-based MX record lookup, for example using MXTOOLBOX, G SUITE TOOLBOX or WHATSMYDNS by changing the domain, links and websites are listed below:
The following is an example of how an MX record is represented:
Name/Host/Alias |
Time to Live (TTL*) |
Record Type |
Priority |
Value/Answer/Destination |
@ or leave blank |
3600 |
MX |
1 |
ASPMX.L.GOOGLE.COM. |
@ or leave blank |
3600 |
MX |
5 |
ALT1.ASPMX.L.GOOGLE.COM. |
@ or leave blank |
3600 |
MX |
5 |
ALT2.ASPMX.L.GOOGLE.COM. |
@ or leave blank |
3600 |
MX |
10 |
ALT3.ASPMX.L.GOOGLE.COM. |
@ or leave blank |
3600 |
MX |
10 |
ALT4.ASPMX.L.GOOGLE.COM. |
Best practice is to remove legacy MX records upon cutover. Following successful testing, legacy MX records should be removed to prevent spammers from targeting your legacy systems directly.
Note: Initial attempts to verify may fail if the tests are conducted within the TTL period. After this threshold has passed, we will be able to confirm the change. Other Resources like the G Suite Toolbox and Email Log search can come in handy when troubleshooting message transit issue.
The following list of actions applies to tasks which should be carried out on a cutover day
Action |
Timeline |
Confirm TTL’s value |
10 mins |
Network configuration |
20 mins |
DNS change of MX record to Google |
10 mins |
Confirmation of change |
24 - 48 Hours based on DNS propagation |
Live tests to confirm successful email flow |
60 mins |
Initiate rollback procedure if needed |
60 mins |
Rollback Strategy
In the case of failure, the DNS administrator will revert the MX records to their original settings. The rollback needs to be done quickly so that existing system won't get hampered.