Google Workspace MX Records: The Exact Values and How to Set Them Up

Google Workspace needs one MX record: host @ (or blank), priority 1, value smtp.google.com. Delete every other MX record on the domain, then activate Gmail in the Admin console; Google says the new record can take up to 72 hours to be recognised. Domains set up before 2023 may still use the five ASPMX.L.GOOGLE.COM records, which Google still supports, so if mail is arriving there is nothing to change. If you are still choosing a plan, you can buy Google Workspace from Register.Domains and set up the domain and the mailboxes in one place.

Values checked against Google’s Workspace Admin Help (pages last updated 7 October 2026), the SPF and DNS standards (RFC 7208, RFC 2181, RFC 5321) and the published rules of the .de, .it and .no registries on 9 October 2026. Google’s own help pages are the reference if anything changes.

The five DNS records Google Workspace uses

The MX record is the one that moves your email, but a working Workspace domain normally ends up with five records. Google’s help splits them across five pages; here they are in one table, with the waiting time Google gives for each.

Record	Type	Host / Name	Value	What it does	Google’s stated wait
Verification	TXT	@ or blank	google-site-verification=… (your own code from the Admin console)	Proves you own the domain	Up to 72 hours
Mail delivery	MX	@ or blank	smtp.google.com, priority 1	Sends incoming email to Gmail	Up to 72 hours
SPF	TXT	@	v=spf1 include:_spf.google.com ~all	Lists Google as allowed to send for your domain	Up to 48 hours
DKIM	TXT	google._domainkey	The public key generated in the Admin console (2048-bit if your DNS host accepts it)	Signs outgoing mail	Up to 48 hours
DMARC	TXT	_dmarc	Start with v=DMARC1; p=none; rua=mailto:you@yourdomain.com	Tells receivers what to do when SPF and DKIM fail, and sends you reports	Add it 48 hours after SPF/DKIM

Two of these are no longer optional if you write to Gmail users. Since 1 February 2024, Google’s sender guidelines require every sender to set up SPF or DKIM, and anyone sending more than 5,000 messages a day to Gmail accounts must have SPF, DKIM and DMARC. A Workspace domain with only an MX record receives mail fine but is more likely to have its own messages land in spam.

The single MX record vs the five legacy ASPMX records

Before 2023 Google asked for five MX records. Google’s help now says any account can use the single smtp.google.com record, “but the legacy MX record values are still supported” and “if your email is working, no changes are required.” If you find these in your DNS, they are not a mistake:

Legacy MX value	Usual priority
ASPMX.L.GOOGLE.COM	1
ALT1.ASPMX.L.GOOGLE.COM	5
ALT2.ASPMX.L.GOOGLE.COM	5
ALT3.ASPMX.L.GOOGLE.COM	10
ALT4.ASPMX.L.GOOGLE.COM	10

All six host names (the five above and smtp.google.com) resolved in a DNS lookup on 9 October 2026. Google practises what it publishes: google.com itself now uses a single MX pointing to smtp.google.com. What matters with the legacy set is the order, not the exact numbers: under the SMTP standard (RFC 5321) “lower numbers are more preferred than higher ones”, so ASPMX.L.GOOGLE.COM must carry the lowest number. Some large domains use 10/20/30 instead of 1/5/10 and work the same way.

The rule for a new setup: use the single record. The rule for an old one: don’t mix the two sets, and don’t touch a legacy set that delivers mail.

The order that avoids lost email

Most “my mail disappeared” stories come from doing the steps in the wrong order: switching MX before the mailboxes exist, or generating DKIM before Gmail is active. This is the sequence Google’s help implies, with its waiting times:

1. Verify the domain with the TXT record. Wait until the Admin console confirms (up to 72 hours). You can remove the TXT once verified; removing it earlier makes verification fail.
2. Create the users, aliases and groups for every address that receives mail today. Once the MX changes, mail for an address that doesn’t exist in Workspace bounces.
3. Replace the MX records: add smtp.google.com with priority 1 and delete all the others.
4. Activate Gmail: Admin console > Menu > Account > Domains > Manage domains > Activate Gmail.
5. Add SPF (v=spf1 include:_spf.google.com ~all). Google recommends ~all.
6. Wait 24–72 hours after activating Gmail, then generate DKIM in Apps > Google Workspace > Gmail > Authenticate email, publish it at google._domainkey, and click Start authentication. The console can keep saying “You must update the DNS records” for up to 48 hours even when the record is right.
7. 48 hours after SPF and DKIM, add DMARC with p=none. Read the reports for a few weeks, then move to p=quarantine and finally p=reject, using pct to apply the stricter policy to a share of messages first.

Where to enter the records: registrar or DNS host

The records go wherever your domain’s DNS is served, which is not always the company you bought the domain from. The domain’s nameservers decide it: if they belong to your registrar, you edit DNS there; if you pointed them to Cloudflare, your web host or another DNS provider, records added at the registrar are ignored.

• At Register.Domains, the free DNS that comes with every domain is managed from your account: select the domain, open DNS Records, choose MX records, add the record and save. If your domain is on one of our hosting plans, DNS is edited in Plesk instead (DNS > your domain > DNS Records), and the NS records there should be left alone.
• Format differs by panel. Some want @ for the root domain, some want the field blank; some require the trailing dot (smtp.google.com.); some take priority and value in one line (1 smtp.google.com). Google lists all three as correct depending on the provider.
• Free email forwarding ends when the MX changes. A registrar’s forwarding service receives your mail through its own MX records. Once the MX points to Google, that forwarding stops, so recreate each forwarded address in Workspace (as a user, an alias or a group) before you switch.

Moving DNS for a .de, .it or .no? Build the zone first

Some country-code registries test the new nameservers before they accept them. If the zone is not already live on the new DNS host, the registration or nameserver change is refused or left pending, and in the meantime mail keeps flowing to the old MX, or nowhere. Our registration system flags 34 of the extensions we sell as needing nameservers that already answer authoritatively for the domain.

Registry	What it checks	What happens if it fails
.de (DENIC)	“All name servers stated in the request must be reachable and authoritative for the requested zone”; at least two nameservers, one reachable over IPv4, with different IP addresses	The request returns an error and is not delegated
.it (Registro .it)	At least two authoritative nameservers; the MX must not point to a CNAME; the same MX records on every nameserver	A nameserver change stays in pendingUpdate for up to 5 days while the check is retried every 30 minutes
.no (Norid)	At least two nameservers on separate machines, checked at registration and afterwards at regular intervals	“Rejection of the application or deletion of the domain”

The other extensions in our list are .dk, .pt (and .com.pt), .com.br and other .br second levels, .co.za and other .za second levels, .hu, .is, .lu, .si and .et. For any of them, the safe order is:

1. Create the zone at the new DNS host and add the Google records to it, MX included.
2. Check that the new nameservers answer for the domain (DENIC, Registro .it and Norid each publish an online checker).
3. Only then change the nameservers at the registrar.

Keeping the DNS where it is and only editing the MX avoids the check altogether.

Six mistakes that break Workspace email

Mistake	What you see	Fix	Why
Old MX records left next to Google’s	Some messages arrive, some go to the old provider	Delete every MX that isn’t Google’s	Google: “Your email might not work correctly if you keep old or incorrect MX records”
Two SPF records (one from the old provider, one for Google)	SPF fails for every message	Merge them into one: v=spf1 include:_spf.google.com include:<other> ~all	RFC 7208: a domain “MUST NOT have multiple records”; more than one gives a permerror
Too many include: terms in SPF	SPF fails once you add a newsletter or CRM tool	Remove services you no longer use	RFC 7208 caps DNS-querying terms at 10; above that the result is permerror
MX pointing to a CNAME (an alias)	Unreliable delivery; a .it registry check fails	Point the MX straight at smtp.google.com	RFC 2181: the value of an MX “must not be an alias”
Records added at the registrar while the nameservers point elsewhere	Nothing changes, even after 72 hours	Add the records at the provider your nameservers point to	Only the authoritative DNS host is queried
DKIM key truncated by the DNS panel	DKIM never validates	Use a host that accepts long TXT values, or generate a 1024-bit key	Google: choose 1024-bit only if your domain host doesn’t support 2048

How to check the records are live

• Google Admin Toolbox Dig (toolbox.googleapps.com): enter your domain, choose MX, and compare the answer with the values above. This is the tool Google’s own help points to.
• From a terminal: dig MX yourdomain.com +short (macOS, Linux) or nslookup -type=mx yourdomain.com (Windows). A correct single-record setup answers 1 smtp.google.com.
• SPF and DMARC: dig TXT yourdomain.com +short and dig TXT _dmarc.yourdomain.com +short. There should be exactly one line starting with v=spf1.
• In Gmail: open a message you sent to an outside address, choose Show original, and check that SPF, DKIM and DMARC say PASS.

FAQ

What is the MX record for Google Workspace?

One record: priority 1, value smtp.google.com, host @ or blank. Google introduced it in 2023; the older five-record ASPMX set still works.

How long do Google Workspace MX records take to work?

Google says up to 72 hours for the MX to be recognised. SPF and DKIM can take up to 48 hours each after you publish them.

Can I keep my old provider’s MX as a backup?

No. Google tells you to remove every other MX record. A lower-priority MX at another provider still receives mail whenever a sender can’t reach Google at that moment, and those messages never reach Gmail.

Do I need SPF, DKIM and DMARC if mail already arrives?

Receiving only needs the MX. Sending reliably to Gmail needs SPF or DKIM for everyone, and all three above 5,000 messages a day, under the sender guidelines Google has applied since February 2024.

Where do I find the MX records in Google Workspace?

Google doesn’t host them: they live at your DNS host. The Admin console only shows the values to use (Account > Domains > Manage domains) and whether Gmail is active.

Ready to set it up? Get Google Workspace with your domain at Register.Domains, or register the name first: a country domain like .de or .it, or a .email domain for an address that says what it is.