smtp.google.com Is an MX Record, Not a Send Setting

To set up MX records for Google Workspace today you publish one record, and its value is smtp.google.com. Google Workspace used to want five, all pointing at hosts whose names began aspmx, each with its own priority number. Google's own setup page states it directly: "The Google Workspace MX record value is smtp.google.com."

MX records get your domain receiving mail, but authentication policy is a separate DNS entry, and DMARC on Google Workspace explains how to read Google's example record before enforcing it.

The hostname is what makes this confusing, because smtp.google.com reads like an outbound SMTP server and is not one. It is the name of the host that receives mail for your domain. Anyone provisioning domains for outbound meets both kinds of setting in the same afternoon, so the distinction is worth nailing down before touching a zone.

What an MX record is answering

An MX record names the server that accepts incoming mail for a domain, along with a preference number that sets the order senders should try. When another company's mail server has a message for someone at your domain, it queries your domain's MX records, sorts by preference with the lowest number first, and attempts delivery there. Google describes the same lookup: "the sender's computer looks up the MX records for your email domain, like @your-company.com, to figure out where to deliver it."

Nothing in that description concerns mail leaving your domain. Submission, which is your client or your platform handing a message to a server to send, is a separate protocol conversation with a separate hostname, its own port, and authentication. The MX record has no role in it.

The two get conflated because Google's chosen MX hostname now contains the word smtp. It is a naming choice rather than a change of function, and the definitional side of what an MX answer tells you, including how to read one on a prospect's domain before sending, is in MX record.

	The MX record	SMTP submission
Direction	Incoming	Outgoing
Where it lives	Your domain's DNS	A mail client or sending platform
What it says	Where other servers deliver mail for you	A host, a port and credentials to send through
Google Workspace value	smtp.google.com at priority 1	Not an MX target, not in DNS
If it is wrong	You stop receiving	You stop sending

The outgoing side, including which of Google's submission endpoints you actually want and what each one allows, is a separate job covered in Gmail SMTP settings.

Set up MX records for Google Workspace: the smtp.google.com record

Google publishes the exact values, and they are short enough to state in full. Type MX. Name, which some panels call Host or Alias, left blank or set to @, unless you are adding a subdomain to an existing Workspace account, in which case the subdomain label goes there. TTL at the registrar's default, or 1. Priority 1. Value smtp.google.com.

Two details in Google's instructions cause more trouble than the record does.

The first is the trailing dot. Google notes that registrars differ: "some domain registrars require a period at the end (smtp.google.com.)". A fully qualified name written without the terminating dot can be treated as relative by a panel that expects one, which appends your own zone and produces a target nothing resolves. Other registrars, Google adds, "have a preset option you can choose without typing anything", which sidesteps the question entirely.

The second is that the old records have to go. Google's instruction is unambiguous: "You might see some MX records already listed. Remove any other MX records. Your email might not work correctly if you keep old or incorrect MX records." Leaving a stale MX behind does not create a backup path. It creates a second destination that senders will try, at whatever priority it carries, and mail delivered there is mail nobody reads.

Then the wait, which is longer than most DNS changes: "It can take up to 72 hours for the new MX records to be recognized." Google repeats the figure twice on the page, once for DNS and once after activating Gmail in the Admin console, which is the second step and the one people forget when a domain resolves correctly and still receives nothing.

The cutover, and two figures Google publishes for the same wait

Changing an MX record is a cutover rather than an edit, because the old answer stays cached until it expires. Google's guidance on the change describes what happens in the gap: "Until the new records are active, emails are directed to your previous email provider." Nothing is refused during that window. It is delivered to a mailbox you may no longer be reading.

That is the reason Google's ordering advice runs the way it does, and it is worth following literally. Create the user accounts in the Admin console before changing the records, so that mail arriving the moment the new answer takes effect has somewhere to land. Google also suggests scheduling the change "when your email volume is low, such as in the evening or on the weekend", and telling the people who mail you most that a brief window may need a resend.

Two Google pages give two different allowances for the same wait, and both are current. The MX setup page says "It can take up to 72 hours for the new MX records to be recognized." The page on avoiding issues during the change says "It can take up to 48 hours for your Google MX records to propagate." Neither figure is a guarantee in either direction, since the real limit is the time-to-live on the record you are replacing plus whatever caching sits between a sender and your zone. The useful reading is to plan for the longer number and stop diagnosing before the shorter one has elapsed.

Lowering the TTL on the existing MX record a day before a planned change, and raising it afterwards, shortens that window more reliably than any of the published estimates. It costs one edit and it is the only part of the timing you control.

1

Create the user accounts first

So mail arriving on the new answer has somewhere to land.

2

Lower the old record's TTL a day ahead

The only part of the wait you control.

3

Replace every MX record with smtp.google.com

Priority 1, name blank or @, at a low-volume time.

4

Activate Gmail in the Admin console

The second step, and the one people forget.

5

Verify from outside the panel

Plan for 72 hours; do not diagnose before 48.

If your domain still has aspmx records

The five-record era has not been switched off, and Google is explicit about it: "If you started using Google Workspace before 2023, your domain might have different MX record values that start with aspmx. If your email is working, no changes are required. Any account can use the new single MX record value, but the legacy MX record values are still supported."

That is a clear answer to the question most people arrive with. A working legacy setup is not broken and does not need migrating on a deadline. A new domain should use the single record because it is one line instead of five, and five lines is five chances to mistype a priority.

The case worth being careful about is the half-migration, where somebody adds smtp.google.com alongside the existing aspmx set rather than replacing it. That domain now publishes six MX records with mixed priorities, all pointing into Google, which mostly works and produces exactly the kind of intermittent, hard-to-attribute behaviour that costs a day to diagnose. Replace, then verify from outside the panel.

Finished means

• Every previous MX record removed, not left alongside
• The value reads smtp.google.com, with a trailing dot if the registrar needs one
• The name field is blank or @, not the domain repeated
• Gmail activated for the domain in the Admin console
• An outside query returns the expected answer

Not finished

• A check run within an hour of saving, treated as conclusive
• smtp.google.com added beside the old aspmx set

Working legacy aspmx records left alone on purpose are fine: Google still supports them.

The reason this matters more on a sending domain than on a company domain

Outbound programmes run mail on domains bought specifically for the purpose, and there is a failure mode on those domains that has no equivalent on a primary company domain: the MX record is the only thing standing between a campaign and losing every reply it earns.

A sending domain that authenticates perfectly, warms properly and lands in inboxes, but has no working MX record, will send exactly as designed and receive nothing. Every reply bounces at the sender's end or vanishes, and the campaign reports as a total failure of the copy, the list, or the offer. Nothing in the sending platform's dashboard distinguishes that from an audience that simply did not care.

The check costs one DNS query per domain and it belongs in provisioning rather than in diagnosis. Resolve the MX for every domain you send from, confirm it answers, and confirm the mailbox behind it is one somebody monitors. Then keep the answer, because MX is also the cheapest pre-send signal available on the recipient side, and grouping a list by receiving platform before a send is a use of the same query described in MX record.

The other three records on the same domain are the authentication set, and they are the ones that decide whether the message is trusted rather than where the reply goes. All three side by side are in the SPF, DKIM and DMARC setup guide, the Workspace-specific SPF record and its limits are in the Google Workspace SPF record, and the lookup tools worth running against a domain you have just changed are in the MXToolbox deliverability guide.

The mechanics of generating and publishing that per-domain DKIM key are worked through in the Google Workspace DKIM setup guide.

We run one message per campaign, which raises the cost of a lost reply rather than lowering it, since there is no later message to the same person that could recover a conversation the first one started. That is why the MX read-back is part of launching a sending domain rather than part of investigating a quiet campaign, and it is the same reasoning behind carrying more sending infrastructure than a campaign consumes.

If you would rather not own the DNS layer across a portfolio of domains, we run the sending infrastructure as part of the engagement.

The short version

Google Workspace now uses a single MX record with the value smtp.google.com at priority 1, with the name left blank or set to @. The smtp in that hostname does not make it a submission server; it is the host that receives mail addressed to your domain, and outgoing settings live in your client or platform rather than in DNS.

Remove every other MX record rather than leaving old ones alongside, add a trailing dot if your registrar expects one, activate Gmail for the domain in the Admin console, and allow up to 72 hours before concluding anything. Domains that started before 2023 and still carry aspmx records are supported and need no migration if mail is working. On an outbound sending domain, confirm the MX resolves and the mailbox behind it is monitored, because a domain that sends perfectly and receives nothing looks exactly like a campaign nobody wanted to answer.

Google Workspace MX values and procedures are per Google's published Set up MX records and Avoid issues when changing MX records pages. Verify current values with the source before making DNS changes.

Sources: Set up MX records for Google Workspace, Google Workspace Admin Help, Avoid issues when changing MX records