Do I use the single smtp.google.com MX record or the five old Google MX records?

Either works, but pick one and use only that one. New Google Workspace domains can publish a single MX record — smtp.google.com at priority 1 — and Google now recommends it. The older configuration used five records: ASPMX.L.GOOGLE.COM at priority 1, ALT1 and ALT2.ASPMX.L.GOOGLE.COM at 5, and ALT3 and ALT4.ASPMX.L.GOOGLE.COM at 10. Both deliver to the same place. What breaks delivery is mixing them, or leaving a third-party provider's MX in the list alongside Google's. Publish the single smtp.google.com record on a new domain; if you already run the five-record set and it works, there is no reason to touch it. Just don't keep both, and don't keep your old host's MX after the cutover.

I verified my domain but Gmail still isn't receiving mail. Why?

Verification and mail routing are two separate steps, and passing the first does nothing for the second. The TXT verification record only proves to Google that you own the domain so it will let you activate the service. Mail only starts flowing to Gmail once your MX records point at Google — and only after your old MX records are removed. The most common cause of 'verified but no mail' is a split-MX: the new Google MX is live, but the previous provider's MX is still published too, so sending servers deliver to whichever one they pick and half your mail lands in an inbox nobody watches. Remove every non-Google MX record, confirm only Google's is left, and allow up to 72 hours for the change to propagate before deciding it's broken.

Should I delete the TXT verification record after Google confirms my domain?

No. Leave it in place permanently. Google re-checks domain ownership periodically, and if the verification TXT record disappears, verification can lapse and your Workspace service can be interrupted until you re-add it. The record is harmless to keep — it's an ordinary TXT value at your domain root that affects nothing else. The only records you remove during setup are the *old MX records* from a previous mail provider, never the google-site-verification TXT. If you're cleaning up DNS later and see it, resist the urge; it's load-bearing.

Google Workspace Domain Setup: Verify TXT, Then MX

What You’re Setting Up

Connecting a domain to Google Workspace is three DNS jobs that have to happen in order, and the order is where people lose a day. First you prove you own the domain (a TXT record). Then you route inbound mail to Google (MX records). Then you tell the rest of the internet that Google is allowed to send as you (SPF and DKIM). Do them out of order — or do the second one without undoing your old mail host — and you get the classic symptom: the Admin console says everything’s fine, and mail still lands somewhere else. This guide is the sequence, the exact values, and the two traps that eat the most time.

Step 1: Prove You Own the Domain (TXT)

Before Google lets you turn on Gmail for your domain, it needs proof you control the DNS. The Admin console hands you a unique verification string that looks like google-site-verification= followed by a long token, and you publish it as a TXT record at your domain root (the apex — the host field is @ or blank, not www and not a subdomain).

Two things trip people here:

It goes on the root, once. One TXT record at the apex. You don’t need a separate one per subdomain.
Propagation is real. After you add it, Google’s checker may not see it for minutes to a few hours. If it fails the first time, wait and re-check rather than adding the record a second time.

And the rule that comes back to bite people later: once verified, leave the TXT record alone forever. Google re-verifies periodically, and deleting it can suspend the service.

Step 2: Route Mail to Google (MX)

This is the step that actually delivers mail, and it’s where the real failure lives. You have two valid options:

# Modern — single record (recommended for new domains)
example.com.   3600   IN   MX   1   smtp.google.com.

# Legacy — five records (leave alone if already working)
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.

Use one configuration, not both. The single smtp.google.com at priority 1 is what Google now recommends for new setups; the five-record set is the old default and still works. They deliver to the same infrastructure — the only wrong move is publishing both, or worse, keeping them next to a leftover MX from your previous provider.

The split-MX trap

The single most common “Workspace isn’t receiving mail” cause is not a wrong Google value — it’s the old value still being there. You add Google’s MX, you don’t remove your previous host’s MX, and now your domain advertises two mail destinations. Every sending server on the internet gets to choose, based on preference numbers and its own retry logic, and the choice isn’t stable. Some messages go to Gmail, some go to the old mailbox nobody logs into anymore, and the split shifts as DNS caches expire. Users report mail “disappearing.” It isn’t lost — it’s being delivered, just to a system that was supposed to be dead. The moment your Google MX is confirmed working, delete every other MX record.

Step 3: Authorize Google to Send as You (SPF, then DKIM)

Routing mail in is done. Now stop your outbound mail from landing in spam.

SPF is one TXT record at the root telling receivers that Google’s servers may send for your domain:

example.com.   3600   IN   TXT   "v=spf1 include:_spf.google.com ~all"

The trap here is fatal and silent: a domain may have only one SPF record. If you already publish an SPF record for another service, you do not add a second v=spf1 line — two SPF records is a permerror that makes SPF fail entirely. You merge: keep one record and add include:_spf.google.com inside it alongside whatever was already there.

DKIM is generated inside the Google Admin console (Apps → Google Workspace → Gmail → Authenticate email). Google gives you a 2048-bit public key to publish as a TXT record at google._domainkey.example.com. The step people forget is the last one: after you publish the DKIM record and let it propagate, you have to go back into the console and click “Start authentication” to actually turn DKIM on. Publishing the key without flipping the switch signs nothing.

Diagnose with DechoNet

Email Check reads your domain’s MX, SPF, and DKIM the way a receiving server does — so you can confirm the Google MX is the only MX (catching a split-MX leftover), that your SPF is a single valid record containing _spf.google.com, and that DKIM is published and resolving, all in one pass.
DNS Check resolves an individual record on its own. Use it to confirm the google-site-verification TXT is live at the root, or that google._domainkey.example.com returns your DKIM key.

Verification Checklist

dig TXT example.com +short shows the google-site-verification= value — and you have not deleted it.
dig MX example.com +short shows only Google’s MX (either the single smtp.google.com or the five ASPMX hosts) and nothing from a previous provider.
There is exactly one SPF record, and it contains include:_spf.google.com.
dig TXT google._domainkey.example.com +short returns your DKIM public key.
DKIM authentication is switched on in the Admin console, not just published in DNS.
You’ve waited out the TTL / up to 72 hours before concluding anything is broken.

When It’s Not DNS

If verification passed, the Google MX is the only MX, SPF is single and correct, DKIM is published and switched on — and mail still misbehaves — DNS has done its job and the problem has moved into Workspace itself: a user not licensed, a routing rule or catch-all in the Admin console, or a mailbox that hasn’t been created. At that point it’s an account-and-routing question inside the console, not a records question in DNS.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.