How long will mail keep arriving at my old server after the change?

Google states it can take up to 72 hours for new MX records to be recognized, and that until records are updated worldwide you will still receive traffic at the old server. We keep the old mailboxes accepting mail for at least a week, because a single slow sender can show up on day five.

Do I need to replace my old aspmx records with smtp.google.com?

No. Google documents a single record pointing at smtp.google.com for new setups, and says the legacy values that start with aspmx are still supported and need no change if your mail is working. During a migration we leave a working legacy record alone and change one thing at a time.

Will changing the MX record break my website or my outgoing mail?

The MX record only decides which server accepts incoming mail for your domain. Your website follows separate records, and your ability to send as your domain depends on SPF, DKIM and DMARC, which have to be updated on their own. A clean MX change with a stale SPF record is the usual reason mail starts landing in spam after a move.

Change MX records to Google Workspace without losing mail

The MX change is the moment clients get quiet on the call. Everything else in a migration can be undone in an afternoon. This one feels like pulling a plug on the company phone line, and the question is always the same: what happens to mail that arrives mid-switch?

The honest answer is that nothing has to be lost, and the losses that do happen are almost never caused by the record itself. They are caused by an account that did not exist yet, an old mailbox that was shut off too early, or sending authentication that nobody updated. Here is the order we run for a client, and what we watch at each step.

What the MX record actually controls

An MX record answers one question for every mail server on the internet: when someone sends a message to your domain, which host should accept it? That is the whole job. It does not move the mail already sitting in your old mailboxes, it does not decide who is allowed to send as your domain, and it has nothing to do with your website.

That matters because the two halves of email break in different ways. Incoming mail follows MX. Outgoing mail is judged by SPF, DKIM and DMARC, which live in completely separate DNS records. We have seen a cutover go perfectly on the receiving side while every invoice the company sent that week landed in spam, because the SPF record still listed only the old host.

One more thing worth saying out loud: DNS does not switch, it expires. Every server that looked up your domain recently keeps the old answer for as long as the TTL allows, so mail arrives in two places for a while. Plan for the overlap instead of fighting it.

Lower the TTL first, days before you touch anything

The time to live, or TTL, is the number of seconds other servers may keep using a cached copy of your record before checking again. Google's own DNS guidance puts it plainly: a record with a TTL of 86400 seconds means changes take up to 24 hours to take effect, and it recommends a value of 3600 so that servers check every hour.

There is a catch that costs people a day. A shorter TTL only starts applying after the previous period has expired. If your MX record is sitting at 86400 and you lower it to 3600 an hour before the cutover, the rest of the internet is still entitled to the old answer for the next day. So the TTL change is its own step, done at least one full old-TTL period ahead. For a 24-hour record we lower it two days out.

Read what you have before you plan the window:

dig +noall +answer MX example.com
dig +nocmd +noall +answer TXT example.com | grep spf1

The number in the second column of the MX answer is the remaining TTL in seconds. That number, not the calendar, decides how early you start.

The values Google publishes today

Google's setup page now shows a single MX record pointing at smtp.google.com, and registrars usually want it at priority 1. Accounts that started before 2023 have the older set of values beginning with aspmx; Google states those legacy values are still supported and that no change is required if your mail is working. We do not rewrite a working legacy record during a migration. One risky change at a time is enough. Checked on the Google Workspace Help page for MX setup, 29 September 2026.

; what a current single-record setup looks like
example.com.    3600    IN    MX    1 smtp.google.com.

Two details cause most of the support threads. Registrar formats differ: some require the trailing dot, some want the priority and the host in one field as 1 smtp.google.com, and some add your domain to the value automatically so you end up with smtp.google.com.example.com. And the old MX records have to go. Google's instructions say to remove any other MX records, because mail may not work correctly if incorrect ones are left behind. A leftover record at priority 10 pointing at the old host is how half a company.s mail ends up in a mailbox nobody reads.

Create the accounts before you touch DNS

This is the step that actually loses messages, and it is not a DNS step at all. Google's guidance for avoiding problems during an MX change is to create your user accounts in the Admin console first, along with any groups or nicknames your domain uses.

Say a 12-person accounting firm has ten mailboxes, two shared addresses for clients, one address the billing software sends from, and an alias printed on an old business card. If facturacion@ exists on the old server but not in Workspace, mail to it starts bouncing the minute the record flips, and a bounce is not recoverable. We build the inventory from the old server's account list and from a month of logs, not from memory, because the addresses people forget are the ones machines use.

Dual delivery and split delivery: the two safety nets

You do not have to choose between the old system and the new one on a single evening. Google supports two arrangements for the overlap, both configured in the Admin console under Apps, then Google Workspace, then Gmail, then Routing.

Dual delivery puts a copy of each incoming message in both systems. Either side can be the primary one: Google recommends Gmail as primary, and notes that you might keep the legacy server as primary during a pilot or a migration, then move to Gmail only when the pilot ends. This is what we use when a team wants a week of reading mail in both places before they commit.

Split delivery routes incoming messages to two different systems based on the recipients you name, which fits a company moving one department at a time. Google's documentation notes that routing changes can take up to 24 hours, though they usually apply faster, so build that into the plan rather than testing five minutes after you save.

For a small business moving everyone at once, neither is strictly necessary. For a phased move, or a shared mailbox the business depends on, the overlap is cheap insurance.

The cutover hour, in order

Google's own advice is to schedule the change when your mail volume is low, an evening or a weekend. We add one rule: pick an hour when the people who can answer questions are still awake.

Confirm every address on the inventory exists in Workspace, including groups and aliases.
Confirm the sending side is ready: SPF authorizes Google, the DKIM key is published and turned on, and the DMARC record is in place.
Confirm the old mailboxes still accept mail and will keep doing so for at least a week.
Publish the Google MX record and delete every other MX record for the domain.
Re-read the record from outside your network with dig, not from the registrar screen.
Send a test message from an outside address, then reply from the new mailbox to something external.
Watch both systems for the rest of the evening. The old one keeps receiving for a while, and that is expected.

The mail that still arrives at the old host

Google is explicit that it can take up to 72 hours for new MX records to be recognized, and that until records have been updated worldwide you will still receive traffic at your old server. Read that as a week of caution, not a three-day countdown, because a domain that resolves everywhere on day two often has one stubborn sender on day five.

Two things keep that mail from being lost. First, leave the old mailboxes accepting and, where the host allows it, forwarding to the new addresses. Nobody should cancel the old hosting plan on cutover day, and we say so in writing before the project starts. Second, bring the history across properly. Google's data migration service and data import tool pull mail over IMAP from the Admin console under Data, then Data import and export, using a mapping file of source and destination addresses; the documentation notes a limit of 100 IMAP users per import and that you have to be signed in as a super administrator. Run the import after the cutover, then a second pass for anything that landed at the old host during the overlap.

Re-authenticate, then test with a real message

The receiving side is now Google. The sending side has to say so too, and this is where a clean MX change still produces a week of mail in spam folders.

If Google Workspace is the only thing sending for your domain, Google documents the record as v=spf1 include:_spf.google.com ~all, where ~all asks receivers to treat unlisted senders as suspicious. Most small businesses are not that simple: the shop, the CRM, the invoicing system and the helpdesk send too, and each one you add spends part of the 10-lookup budget SPF allows.

; Google plus one external sender, as an illustration
v=spf1 include:_spf.google.com include:sendgrid.net ~all

DKIM has to be generated and turned on in the Admin console, not just left to default behaviour. Google recommends the google selector prefix and a 2048-bit key, says to fall back to 1024 only if your DNS provider cannot handle the longer value, and notes that authentication can take up to 48 hours to start working. The Admin console may keep showing a message telling you to update DNS for up to 48 hours after the key is correct, which is worth knowing before someone starts changing things that were already right.

Then check it from the receiver's side rather than your own. Gmail's sender requirements state that all senders must set up SPF or DKIM, and that senders of 5,000 or more messages a day to Gmail must have SPF, DKIM and DMARC. Postmaster Tools has an authentication view showing the percentage of your mail that passes each check, which is the only number that settles an argument about whether a migration hurt deliverability.

How Guanacos Tech helps

We run MX cutovers as a scheduled hour with a written order of operations, because the failures here come from sequencing rather than from difficulty: an address that did not exist, a record deleted too early, a sending system nobody inventoried. Our Google Workspace migration consultants page sets out the scope we work to, including the overlap week and the authentication checks afterwards. Bring your current MX record and a list of everything that sends mail as your domain to a 30-minute call, and you will leave with the cutover hour, the risks specific to your setup, and what to keep running until the last sender catches up.

Changing MX records to Google Workspace without losing a single message