Google Workspace MX Records: Values, Setup and Checks

Do not index

For a new Google Workspace setup, publish an MX record with host @, priority 1, and destination smtp.google.com. Google recommends this single record for new setups, but its five legacy records also work, so a five-record result isn't automatically a configuration error.

The useful diagnostic question isn't whether a domain has the newest format. It's whether the domain publishes a complete, intentional Google Workspace MX set without leftover destinations, aliases, or formatting errors.

Table of Contents

Current Google Workspace MX Values to Publish Google Workspace MX records by configuration What should be checked before editing?How MX Priority Decides Which Server Gets Mail What does a sending server do?What makes an MX target valid?Which Google Workspace MX Record Set Applies to Your Domain Which MX record set should be published?What if account history and DNS disagree?What a correct check actually catches How to Publish the MX Records in Common DNS Panels What is the safe editing procedure?Where are the fields in each DNS panel?How to verify it How Long MX Changes Take to Reach the Internet Which timing layers matter?What should a cutover plan account for?How to Verify Your MX Change and Fix Common Errors Is Your Google Workspace MX Setup Ready What belongs on the readiness checklist?Frequently Asked Questions About Google Workspace MX Records Does a five-record Google Workspace setup still work?Which priority should the single Google Workspace MX record use?Why does an MX lookup still show the old host after a saved change?Should a domain publish the DNSSEC MX values?Can an MX record point at a CNAME?

Current Google Workspace MX Values to Publish

Google Workspace MX records identify the servers that accept incoming mail for a domain. They belong at the domain root wherever Google Workspace receives mail addressed to that domain.

Google's current Google Workspace MX setup guidance recommends the single-record configuration below for new setups. Existing domains on working legacy records can stay on them; the five-record set remains a supported configuration.

Google Workspace MX records by configuration

The table lists alternative configurations, not a combined set to publish. Every destination is an MX target at the root of the receiving domain.

Google documents the DNSSEC destinations and preferences separately in its DNSSEC MX configuration instructions. Treat the DNSSEC set as a third valid configuration, not a fallback for the standard set. Use it when following Google's DNSSEC-specific instructions. Adding it alongside an ordinary deployment produces a mixed set that a correct check will flag.

What should be checked before editing?

Query the live DNS answer first. A registrar's DNS panel can display a saved record even when the domain delegates authoritative DNS elsewhere, so the panel alone proves nothing about what the internet sees.

Before editing, inspect the domain's live MX records with mailX. Save the returned destinations and priorities as the rollback baseline, then compare them with the matching configuration above.

Confirm the applicable values in Google Admin Help before changing production routing. Copy only the matching configuration, preserve the existing zone information for rollback, and establish which provider serves authoritative DNS.

How to verify it: Run the mailX MX lookup against the receiving domain. A correct result contains one complete configuration from the table and nothing else. The failures that matter are leftover records from a previous provider, MX targets pointing at CNAME aliases (mailX's DNS Lookup returns records grouped by type, including CNAME, which exposes them), and formatting slips such as a missing trailing dot or a priority entered in the wrong field. Each surfaces in a live lookup before it surfaces as bounced mail.

How MX Priority Decides Which Server Gets Mail

MX priority is a numeric preference: the lowest number is tried first, and records sharing a number form a preference tier. Priority controls delivery order, not a guaranteed percentage of incoming messages.

For the legacy Google Workspace configuration, the primary destination is preferred over the alternate tiers. Equal-priority destinations don't promise an even traffic split, and a higher number doesn't reserve a share of mail for that server.

What does a sending server do?

For mail addressed to example.com, used here only as an example domain, the delivery sequence is:

The sending server looks up the recipient domain's MX records.

It orders the available destinations by preference and attempts delivery to a preferred destination.

If that destination can't accept the connection or delivery attempt, the sender can try another eligible destination, including a higher-numbered tier.

Fallback isn't authentication or account setup. Adding alternate MX records doesn't fix an inactive mailbox, and changing preferences doesn't authorize an application to send mail.

What makes an MX target valid?

An MX destination must be a hostname, not a literal IP address. The hostname must resolve to address records rather than depend on a CNAME alias. An administrator should therefore examine both the MX answer and the DNS records behind its target.

For Google Workspace, using Google's documented destination directly avoids unnecessary aliases under the organization's domain. A local alias adds another configuration to troubleshoot without improving the published Google setup.

A leftover destination with a lower numeric preference can attract delivery before Google. An equal-preference leftover can introduce another eligible destination, while a higher-numbered leftover can still receive fallback attempts. None belongs in a straightforward migration unless the administrator has deliberately designed that routing.

The mailX tips for inbound mail routing provide further context for interpreting preference tiers. The operational lesson is simple: inspect every returned MX row, not just the first Google hostname.

Which Google Workspace MX Record Set Applies to Your Domain

The deciding factor is the Google Workspace account's start date. Domains that began using Google Workspace before 2023 generally use the legacy configuration, while domains that started in 2023 or later generally use the single-record format, according to Google's instructions for setting up Workspace MX records.

That distinction explains why older tutorials and newer onboarding screens can show different valid answers. Confirm setup history in the Google Admin account; the domain's registration date doesn't answer that question.

Which MX record set should be published?

A correct diagnostic must accept both supported generations. A result shouldn't fail just because the domain publishes the complete legacy set instead of the newer destination.

Google states that legacy records remain supported when email already functions. Replacing a working configuration solely for cosmetic consistency creates an unnecessary routing change.

What if account history and DNS disagree?

Use the Google Admin setup instructions and the domain's actual configuration together. Third-party guides can describe different onboarding paths or historical cutoffs, so they shouldn't override Google's instructions for the account.

Check whether the domain already receives mail correctly, whether a migration is in progress, and whether DNSSEC-specific setup applies. An unexpected mix of generations deserves investigation rather than an assumption that more Google destinations means more resilience.

What a correct check actually catches

Picking the right generation is only half the job. The failures that break delivery in practice are leftover records from a previous provider, CNAME aliases standing in for MX targets, and formatting slips like a missing trailing dot or a swapped priority field. Each of those surfaces with a different tool: the mailX MX lookup returns the live record set with priorities so leftovers show immediately, and the mailX DNS Lookup groups the domain's records by type so an alias behind an MX target is visible instead of hiding in the answer.

Run the MX lookup before changing anything and compare its output against the set the table above prescribes. The good result is a complete matching generation with no unexplained destinations. Mixed generations or another provider's hosts mean the intended routing needs resolving first.

How to Publish the MX Records in Common DNS Panels

A clean MX edit is mostly a scope-control problem. Publish the supported Google destination, remove only the conflicting mail-routing rows that belong to the cutover, and leave authentication or verification records alone unless they are part of the same planned change.

For the current standard configuration, the DNS entry contains the following fields. The fully qualified destination includes a trailing dot where the DNS provider requires it.

The record belongs in the authoritative DNS zone. Purchasing a domain from a registrar does not prove that the same company currently serves its DNS; the active nameservers decide which panel can publish the answer.

What is the safe editing procedure?

Confirm the applicable configuration. Use the selection criteria above rather than replacing working legacy records automatically.

Open the DNS zone for the domain that receives mail. Check the active nameservers if there is uncertainty about which DNS panel controls publication.

Record the previous settings, then remove the previous provider's conflicting MX entries as part of the planned cutover. Include registrar-created default mail entries.

Add the selected Google MX configuration. For the current standard setup, use the field values above.

Save the changes and inspect the resulting record list. Confirm that the panel did not retain a default destination or automatically append the domain to the target.

Removing conflicting MX entries stays limited to mail routing. Keep unrelated TXT, verification, and address records unless the migration plan explicitly includes them.

Where are the fields in each DNS panel?

Menu names and defaults change. Treat these patterns as navigation guidance and confirm the current interface in the provider's official documentation before a production edit.

Some registrar panels require a mail-settings switch from the default hosted mailbox mode to a custom MX mode before the destination rows become editable. Dashboards that also proxy web traffic need the MX row kept as a DNS mail-routing entry, separate from any web proxy configuration.

The trailing dot belongs to the destination field. Some interfaces expect a fully qualified name; others normalize it automatically. If an interface treats an undotted destination as relative, it can append the receiving domain and publish a nonexistent target.

Do not add punctuation by trial and error. Save the provider's expected syntax, then inspect the resulting public hostname.

How to verify it

Run the mailX MX lookup for the root domain. It returns the domain's live MX records with their priorities, so the standard current setup should show the single Google destination and its documented preference from the values table.

A correct check accepts either supported Google MX generation. The failures that matter are concrete: leftover MX rows from the old provider appear as extra priorities or foreign hosts in the mailX MX lookup, a CNAME alias or other conflicting record at the same name appears in mailX DNS Lookup because that tool groups live records by type, and formatting slips appear when the lookup shows an appended domain or a target that does not exist.

If the record appears correctly only inside the DNS panel, confirm authoritative nameservers before assuming the problem is propagation.

How Long MX Changes Take to Reach the Internet

A saved MX change passes through two separate stages: the provider publishes it to authoritative nameservers, then caches everywhere have to let go of the old answer. A green status inside the DNS dashboard confirms the first stage only.

Google's setup guidance allows up to 72 hours for MX changes to become recognizable across DNS infrastructure. Treat that window as a troubleshooting allowance. An obviously wrong authoritative answer on day one will still be wrong on day three.

Which timing layers matter?

Provider publication. The DNS provider saves the change and starts serving it from authoritative nameservers. How fast this happens depends on the provider.

Cached answers. Recursive resolvers keep returning the previous MX answer until its cached TTL expires.

Sender visibility. Sending systems pick up the new route only when they request a fresh DNS answer.

Time to live, or TTL, is the number of seconds a resolver may cache a DNS answer before requesting it again. The TTL on the answer a resolver already holds controls the wait. Lowering the TTL in the panel afterward changes nothing for that cached copy.

Google recommends the registrar's default TTL, or the numeric TTL option shown in its setup interface. A bare value in a provider's field can mean seconds, minutes, or hours, so confirm the units in the provider's documentation rather than guessing.

What should a cutover plan account for?

Before switching, record the existing MX TTL and keep the old mail service running through the transition. Deleting the old provider's MX row changes where new lookups point. The mailboxes behind it keep accepting whatever still arrives until you retire them separately.

Some senders will keep delivering to the previous destination while caches expire. A lookup from a single location cannot prove every sender has moved.

The explanation of how long DNS changes take separates publication from cache expiration in more detail. When different locations return different answers, check DNS propagation status to compare visibility beyond the local resolver.

Once the documented allowance has passed, propagation stops being the plausible explanation for a failed check. The persistent failures are leftover MX rows from the previous provider, a CNAME sitting where the MX target should be, or a formatting slip in the destination field. The mailX MX lookup lists the surviving records with their priorities, the CNAME lookup exposes an aliased target, and the DNS lookup groups the zone's records by type for a formatting pass.

The decision rule stays simple. If authoritative DNS still publishes the wrong target, correct the zone because waiting accomplishes nothing. If the zone is right and a resolver still answers with the old route, the remaining delay is cache expiration, and the fix is time.

How to Verify Your MX Change and Fix Common Errors

I'm seeing a contradiction regarding the themailx.com URL. The duplicate URL check says to remove it entirely from this section, but the planned internal link requirement states it must appear exactly once here. The suggested improvement clarifies this: I should keep the link here and change the one in the closing CTA.

The instruction to remove duplicate links conflicts with the mandatory internal link requirement. However, the specific instruction to keep the themailx.com link exactly once in this section, along with the suggested improvement to keep it here only, takes precedence. The duplicate was in another section, so keeping it once here resolves the conflict for my scope.

I'm noticing overlap between section 2 and the guidance about inspecting every MX row and the first Google hostname. I need to consolidate the instruction to check every row so it appears only once and avoid repeating points about priority and the first hostname, as those are covered in section 2. The "first Google hostname" guidance seems to be a misinterpretation or perhaps related to priority ordering, as it's not explicitly in the current text of section 2.

I'm seeing an unsourced statistic about SPF DNS lookups. The rule says to remove numbers without sources, but "10 DNS lookups" is a real SPF fact. Since I can't invent a URL, I'll rewrite qualitatively to avoid the unsourced number, stating "An SPF policy can exceed its permitted DNS lookup limit."

I'm questioning the existence of a standalone CNAME lookup tool, as the facts don't explicitly list one. While DNS lookup can return CNAME records, the specific URL for a CNAME lookup tool appears unverified. I should replace this with a reference to the DNS lookup tool to ensure accuracy, especially since the mailX site can analyze CNAME records.

I'm preserving the cname-lookup link because the rule states existing internal links must be preserved exactly, even though I'm unsure if a standalone tool exists. While facts don't confirm it, they also don't contradict it, and one fact confirms CNAME analysis capability. Similarly, the SPF checker link is plausible and kept as an existing internal link.

The DKIM checker and SMTP finder details seem accurate and align with the facts. The text's description of the SMTP test checking attempted connections is plausible, and the MX, DNS, and TXT record lookups are confirmed. Notably, the diagnostics do not modify DNS or mailbox settings, which is also verified.

I'm seeing structural overlap with the previous section's H3 heading "How to verify it." To avoid repetition and maintain a unique angle, I need to rename my H3, perhaps to "What a correct MX result looks like," and ensure my content focuses on detecting specific errors like leftover records, CNAME aliases, and formatting slips using named mailX tools, rather than repeating the previous section's verification steps.

I'm checking the voice and formatting rules. The draft is section 6, not the intro, so a bold-claim opening isn't required, though the current opening is already bold. I've confirmed there are no em-dashes and will check the output for any banned phrases on the list.

I'm questioning the binary contrast rule's application to "not a green status inside a DNS panel." While the rule targets "Not X. But Y.," the text uses an inline "X, not Y." To be safe, I'll rephrase to avoid any contrast, stating that a green checkmark doesn't prove the MX change worked and then detailing what verification requires.

I'm seeing repetition in the guidance about inspecting MX rows. The draft suggests consolidating this instruction to appear only once, likely in the verification steps, and then referencing it briefly in the post-cleanup section. This avoids re-explaining the mechanics of row inspection and focuses on matching the applicable set from the values table.

I'm noticing overlap between the "rerun the lookup after the relevant cache window" instruction and the previous section's "How to verify it." I need to reduce this redundancy. My section can cover cleanup and re-verification, but the previous section already addresses propagation and timing. The immediate recheck after cleanup ("Rerun the MX lookup immediately to catch publication mistakes") is distinct from waiting for cache, so I'll keep that and soften the TTL part, referencing the propagation section for cache windows.

I'm considering whether to keep the mention of the MCP server. The next section covers MCP integration, so a direct mention might overlap. However, the MCP server hosts tools, which is a distinct point. I'll keep a brief mention to highlight tool availability, as it's a unique detail, but I'll avoid linking to documentation to prevent redundancy.

I'm seeing a potential H3 naming conflict with the previous section's "How to verify it." I need to rename my H3 to something distinct, like "What the returned answer should look like," and ensure my numbered steps focus on unique verification angles such as accepting valid sets and identifying leftover records or formatting slips. The numbered steps themselves seem fine, but the heading needs adjustment to avoid repetition.

I'm seeing a potential conflict between the instruction to handle "first Google hostname" and the existing text. The draft suggests this phrase implies priority ordering, which section 2 already covers. However, the "Wrong priority" row in the table references the values table (section 1) and doesn't explain priority mechanics, so I'll keep it.

I'm combining the DNSSEC check into the DNS lookup step, as it's a related detail. I'll also keep the SPF paragraph's original phrasing about its purpose, as it correctly distinguishes it from MX record functions. The image line needs to be preserved exactly as is.

I'm preserving the table mapping errors to tools, as it's a unique angle. I'm also rephrasing the CNAME explanation to avoid a potentially banned contrast pattern, changing "not whether" to a separate sentence for clarity. The SPF section is updated to be qualitative, removing the specific number of lookups to avoid an unsourced statistic.

I'm seeing a potential issue with the DKIM selector check: it must inspect the selector used for the domain's signing configuration, not just any record under an unrelated selector. Similarly, the record type check needs to distinguish between CNAME and TXT records. The SMTP finder's description is a bit long; I'll shorten it while keeping the core information about provider details and the fact that MX priorities don't configure submission connections. The "missing app password" point is fine as is.

The draft's phrasing "no promise"/"no evidence" is parallel but not the banned pattern. Rephrasing to "...doesn't prove... doesn't mean..." is safer. The reference to the propagation section for cache guidance should be qualitative, not a direct link, as the previous section already covered it. The mailX link should appear exactly once.

I'm skipping the MCP mention to avoid overlap, as the next section covers it. The "wider inspection" sentence and read-only closing should suffice. I'm also consolidating the "compare destinations and preferences" guidance into step 2, dropping the repeat here, and will check for banned words and meta-commentary. The word count seems within range.

I'm keeping the themailx.com link here as required, even though a duplicate check suggested removing it. The conflict is resolved by keeping it once in this section and changing the link in the closing FAQ. I'm also ensuring other links like cname-lookup and dns-lookup appear only once. The K13 detail about SMTP finder output is noted.

Is Your Google Workspace MX Setup Ready

Readiness has a precise definition here: a lookup returns the complete Google set for the domain's configuration and nothing else. A correct check accepts either valid answer, the single current record or the supported legacy five-record set. What blocks readiness is just as specific: leftover previous-provider entries, a CNAME standing where the MX hostname should resolve directly, or a formatting slip such as a duplicated domain appended to the destination.

What belongs on the readiness checklist?

The right set for this domain. The mailX MX lookup returns the full applicable Google configuration, whichever format applies.

No leftover destinations. Every host in the answer belongs to Google. A stray provider entry means cleanup is unfinished.

No aliases or formatting errors. The CNAME and TXT record lookups show whether the hostname resolves directly and catch an appended domain before it passes as valid.

Authorized scope only. Checks stay on domains and mail infrastructure the operator owns, manages, or is authorized to test.

For agent-based operations, mailX can be used from AI agents through the documented MCP integration. An agent can query the published records and report deviations against this checklist. The audit never changes DNS, so the zone stays under the administrator's control.

A passing MX result settles routing only. SPF, DKIM, and DMARC remain separate work, covered in the email authentication guide. Keeping them separate is what makes each failure easy to place: MX decides where inbound mail goes, and authentication decides whether receivers trust it.

Frequently Asked Questions About Google Workspace MX Records

Does a five-record Google Workspace setup still work?

Yes. Google still accepts the legacy set on domains where mail already flows, so a working domain does not need to migrate just to match the newer format. A check passes when every published record belongs to one complete supported set, whichever set the domain intends to run. It fails on a leftover prior-provider host sitting alongside the valid Google entries.

Which priority should the single Google Workspace MX record use?

Priority 1, with the destination and host shown in the current-values table. Copy the row exactly. A priority typed as 10 or a destination missing its trailing dot produces a record that resolves but routes nowhere useful, and mailX's DNS Lookup groups records by type so that formatting slip is visible at a glance.

Why does an MX lookup still show the old host after a saved change?

Caching. A resolver holds the previous answer until its TTL expires, and Google's setup guidance allows up to 72 hours for full recognition. Separate that from a publication error: if a live mx_lookup query returns the old host while the registrar dashboard shows the new one, the record never saved correctly and needs a DNS fix rather than more waiting.

Should a domain publish the DNSSEC MX values?

Only when the domain signs its zone and you are following Google's DNSSEC MX instructions. Adding those destinations to an unsigned domain as extra fallback creates a mixed set that fails a strict check. Confirm signing status with the DNS provider first, publish the matching group from the values table, then verify the answer that comes back.

Can an MX record point at a CNAME?

No. Google Workspace requires the direct host values, and an MX destination that resolves to a CNAME alias breaks delivery expectations. Alias or flattening features at some DNS providers can make the dashboard entry look correct while the zone publishes something different. A live MX lookup against the zone, rather than the dashboard, settles which one the internet sees.

Run an MX lookup with mailX to see the domain's live destinations and priorities, free and without signup. Compare every returned row with the applicable Google Workspace configuration, remove conflicting records, and rerun the check after the cache window.