Do I still need the five old ASPMX records?

No. The current documented setup is a single record pointing at smtp.google.com. The older five-host set continues to function, so there is no emergency if you already have it, but you should never publish both at once — that is two competing sets of MX records and it produces unpredictable routing.

Does the priority value matter with only one record?

Functionally, no — there is nothing else for a sender to prefer it over, so any valid value delivers the same. Use 1 because it matches Google's documentation and because a consistent value makes the zone easier to read. Priority only becomes meaningful when two or more MX records exist.

Should the value end with a trailing dot?

In a raw zone file, yes — smtp.google.com. with the dot, because a name without a trailing dot has the zone origin appended and would become smtp.google.com.example.com. Most web DNS panels add the dot for you and expect you to type the name without it. Verify with dig afterwards; a target that resolves to nothing tells you immediately which convention your panel uses.

Can I point MX at a CNAME?

No. The MX target must be a hostname with A or AAAA records. Pointing MX at a CNAME violates the DNS specification, and while some receivers tolerate it, others refuse the delivery outright. If you need indirection, publish the address records directly on the MX target name.

Mail is still going to my old server after I changed MX. Why?

Either resolvers are still holding the previous record for its TTL, or a second MX record was left in place, or your hosting control panel is set to deliver mail locally regardless of DNS. On cPanel-style hosting the last one is very common — the email routing setting must be changed to Remote Mail Exchanger separately from the DNS record.

Will I lose mail during the switch?

Not usually. Sending servers queue and retry for hours or days when a delivery attempt fails, and during the TTL window both the old and new destinations are typically still accepting mail. The practical risk is mail landing in the old mailbox, so keep access to it for several days and check it before decommissioning.

Add MX Records for Google Workspace

MX records tell the rest of the internet which servers accept mail for your domain. For Google Workspace this used to mean five records with three different priority values; the current setup is one record pointing at a single host. Both still work, but the single-host version is what Google documents today and it removes an entire category of typo.

What record do you add?

Field	Value	Notes
Type	MX
Host / Name	`@`	Or the bare domain, or blank — panels differ. Never `www`.
Priority / Preference	`1`	Any value works with a single record; Google documents 1.
Value / Points to	`smtp.google.com`	Some panels require a trailing dot: `smtp.google.com.`
TTL	3600	One hour is a sensible default; lower it before a planned change.

Google's own domain publishes exactly this shape — dig +short MX google.com returns a single smtp.google.com. answer. If you inherited the older five-record set (aspmx.l.google.com plus four alt hosts), it continues to work; there is no urgency to change, but if you are setting up fresh, use the single record. Check Google's current documentation before migrating an existing working setup.

; Current setup — one record
example.com.   3600  IN  MX  1  smtp.google.com.

; Legacy setup — still functional, five records
example.com.   3600  IN  MX  1  aspmx.l.google.com.
example.com.   3600  IN  MX  5  alt1.aspmx.l.google.com.
example.com.   3600  IN  MX  5  alt2.aspmx.l.google.com.
example.com.   3600  IN  MX  10 alt3.aspmx.l.google.com.
example.com.   3600  IN  MX  10 alt4.aspmx.l.google.com.

Zone-file form of both setups — do not publish them at the same time

What does the priority number actually do?

The priority — properly the *preference* value — is a 16-bit unsigned integer, and lower is more preferred. A sending server sorts the MX records for your domain by preference and tries the lowest number first, falling back to higher ones only if the connection fails. Records sharing the same preference are used in a randomised order, which is how the legacy set spread load across alt1 and alt2.

With a single record the number is functionally irrelevant — there is nothing to prefer it over. Publish 1 because that is what Google documents and because a support engineer reading your zone should not have to wonder whether something else was meant to be there. What matters far more is that you do not leave a *second* MX record from a previous provider sitting at a different priority. MX priority explained covers the ordering rules in detail.

A leftover MX record is the classic cause of "some mail arrives and some does not". If an old host is still listed at a higher priority, mail delivers to Google normally until Google is briefly unreachable — at which point a slice of your mail is delivered to a mailbox nobody reads. Delete old MX records; do not just deprioritise them.

What must you remove?

Every other MX record at the apex. Old host, previous email provider, a filtering appliance you no longer use. Google Workspace should be the only MX unless you are deliberately running an inbound gateway in front of it.
MX records pointing at your web server. Common on cPanel-style hosting where a local mail server was configured automatically. On cPanel you must also change the routing setting to "Remote Mail Exchanger", or the server will keep delivering locally and never send mail out to Google at all.
An A record where the MX used to be. If no MX exists, senders fall back to the A record of the domain, which is why removing MX without adding the replacement sends your mail to your website's server.
Do not remove unrelated TXT records at the apex — SPF, domain verification, DMARC on _dmarc. Those are separate and still needed.

MX Lookup

Mail servers and priorities for a domain

How do you verify it?

# The record itself
dig +short MX example.com
# 1 smtp.google.com.

# With the TTL, so you can watch caches expire
dig MX example.com +noall +answer
# example.com.  3600  IN  MX  1 smtp.google.com.

# Confirm the MX target actually resolves — a dead target is a dead MX
dig +short A smtp.google.com

# Ask two public resolvers separately to spot cache disagreement
dig @1.1.1.1 +short MX example.com
dig @8.8.8.8 +short MX example.com

# Without dig
host -t MX example.com
nslookup -type=mx example.com

Verifying MX from the command line

You want exactly one answer line, naming smtp.google.com, and you want dig +short A smtp.google.com to return addresses. Then confirm the mail server is actually reachable and speaking TLS:

openssl s_client -starttls smtp -connect smtp.google.com:25 -crlf < /dev/null 2>&1 \
  | grep -E "CONNECTED|Verify return code"

Confirming the MX host answers SMTP with valid TLS

The MX lookup does the same from outside your network and shows the resolved addresses for each target, and the SMTP connection test checks reachability on ports 25, 465, and 587. If different tools disagree, that is caching rather than configuration — check the propagation checker to see what resolvers around the world are currently returning.

How long until it takes effect?

The honest answer is: up to the old record's TTL, not the new one. A resolver that cached your previous MX with a 24-hour TTL will keep using it for up to 24 hours no matter what you publish now. Nothing you do after the change shortens that window — which is why the TTL is lowered *before* a migration, not during it.

If the old MX had a TTL of 3600, expect most senders to switch within an hour and stragglers within a few hours.
If it had 86400, plan for a full day of split delivery and keep the old mailbox accessible throughout.
If the domain previously had no MX record at all, negative answers are cached too — governed by the zone's SOA minimum — so the new record is not necessarily instant either.
Registrar-level nameserver changes are a separate and slower matter; only the zone edit is governed by the record TTL.

Twenty-four to forty-eight hours before a planned cutover, drop the MX TTL to 300 seconds, let the old long TTL expire, then make the change and raise the TTL again afterwards. Lower your TTL before a DNS migration walks through the timeline, and how long does DNS propagation take explains what is really happening in the caches.

What else does Google Workspace need?

MX handles inbound. Outbound needs authentication, and a Workspace tenant with correct MX but no SPF or DKIM will have its mail filtered.

; SPF — one record only, merged with any other senders
example.com.                  TXT  "v=spf1 include:_spf.google.com ~all"

; DMARC — start at p=none and read the reports
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

; DKIM — generated in the Workspace admin console, published at the selector it gives you
google._domainkey.example.com TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The three records that go alongside MX

The SPF value is covered in full in the correct SPF record for Google Workspace, including how to merge it when you also send through an ESP. Build DMARC with the DMARC generator, verify all three at once with the deliverability test, and check TXT records generally with the TXT lookup. If mail starts bouncing after the change, work through mail bouncing after a DNS change.