How to Configure DNS Records for Google Workspace?

Signing up for Google Workspace is quick. Getting your domain's DNS right so that Gmail actually receives your mail, and so your outgoing messages land in inboxes rather than spam folders, takes a little more care. You need a verification record, MX records, an SPF record, a DKIM key, and — since Google and Yahoo tightened their bulk sender rules in February 2024 — a DMARC record too. Get one wrong and mail bounces or quietly goes to junk. If you're new to how mail routing relies on DNS, setting up a custom email domain through DNS gives the broader picture.

This guide lists every DNS record Google Workspace needs, the order to add them in, what each value should be, and how to verify each one from the command line. It's specific to Google Workspace; the equivalent setup for Microsoft's platform is covered in how to configure DNS records for Microsoft 365.

The Records at a Glance

Purpose	Type	Host / Name	Value
Domain verification	TXT	@	google-site-verification=... (unique to your account)
Receive mail	MX	@	smtp.google.com, priority 1
Authorize senders (SPF)	TXT	@	v=spf1 include:_spf.google.com ~all
Sign mail (DKIM)	TXT	google._domainkey	v=DKIM1; k=rsa; p=... (generated in Admin console)
Policy and reporting (DMARC)	TXT	_dmarc	v=DMARC1; p=none; rua=mailto:...

The verification token and DKIM key are unique to your account, so always copy them from the Google Admin console. The others are standard values documented by Google.

A note on the Host field: DNS providers differ. Most want @ (or a blank field) for the root domain and a relative name like _dmarc for subdomains, and they append your domain automatically. If you type _dmarc.example.com into a provider that appends the domain, you end up with _dmarc.example.com.example.com. Check how your provider displays existing records before adding new ones.

Step 1: Verify Your Domain

Google asks you to prove you control the domain before activating Gmail. In the setup wizard (or later under Account, then Domains, then Manage domains in the Admin console), Google shows a TXT record like this:

example.com.  3600  IN  TXT  "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"

Add it at the root of your domain, then click Verify in the Admin console. Google keeps checking for a while, so if it fails at first, wait a few minutes and try again. Keep this record in place after verification — Google may re-check it, and removing it can unverify the domain. Google can also accept a CNAME record for verification on some setups; use whichever method the console offers.

Check it's visible:

dig example.com TXT +short | grep google-site-verification

If you have other TXT records at the root (SPF, other services' verification tokens), that's fine. Multiple TXT records can exist side by side at the same name. The details of this verification pattern, which many services share, are covered in how to verify domain ownership with a TXT record.

Step 2: Add the MX Record

The MX record tells other mail servers where to deliver mail for your domain. For Google Workspace, Google's current instruction is a single MX record:

example.com.  3600  IN  MX  1 smtp.google.com.

Before you add it:

1. Lower the TTL on your existing MX records a day ahead if you're moving from another email provider. That shortens the window where some senders still use the old server.
2. Delete all existing MX records at the same time as adding Google's. Leaving an old provider's MX in place means some mail goes there, based on priority.
3. Make sure users exist in Google Workspace before switching, so mail has a mailbox to land in.

Older Google Workspace setups used five records (ASPMX.L.GOOGLE.COM at priority 1, ALT1.ASPMX.L.GOOGLE.COM and ALT2.ASPMX.L.GOOGLE.COM at 5, and ALT3/ALT4 at 10). Those still work, so there's no urgency to change an existing domain, but new setups should use smtp.google.com. Don't mix the two sets.

Verify:

dig example.com MX +short

The output should show only 1 smtp.google.com. (or the full legacy set, if that's what you use). For more on how priorities and fallback work, see what MX records are and how they work. Mail starts flowing to Gmail as resolvers pick up the new record — usually within an hour, though cached old records can delay some senders until their TTL expires.

Step 3: Add the SPF Record

SPF lists the servers allowed to send mail for your domain. If Google Workspace is your only sender, the record is:

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

The include:_spf.google.com mechanism pulls in Google's sending ranges, and ~all soft-fails anything else. Once you're confident everything legitimate is listed, you can tighten it to -all.

The critical rule: a domain must have only one SPF record. If you also send through other services — a newsletter platform, a CRM, a transactional mail API — merge their mechanisms into the same record:

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

Two separate v=spf1 records cause a permerror, which receivers treat as an SPF failure. Also keep the total number of DNS lookups (each include, a, mx, and similar mechanism counts) at 10 or fewer. The background on SPF syntax and limits is in what an SPF record is and why it's important.

Step 4: Set Up DKIM

DKIM signs every outgoing message with a private key; receivers check the signature against a public key in your DNS. Google generates the key pair for you.

1. In the Google Admin console, go to Apps, then Google Workspace, then Gmail, then Authenticate email.
2. Select your domain and click Generate new record.
3. Choose a 2048-bit key length (use 1024-bit only if your DNS host can't store long TXT records) and keep the default prefix selector of google unless you have a reason to change it.
4. Google shows the DNS host name (google._domainkey) and the TXT value.
5. Add the TXT record at your DNS host.
6. Return to the Admin console and click Start authentication.

The record looks like this (key shortened):

google._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq8"
                                                 "...remainder-of-the-public-key...IDAQAB" )

A 2048-bit key is longer than the 255-character limit for a single TXT string. Most DNS control panels split it automatically when you paste the full value. Some require you to split it into multiple quoted strings yourself. Either way, receivers join the strings back together.

Wait until the record is visible before clicking Start authentication, or Google reports that it can't find the key:

dig google._domainkey.example.com TXT +short

You should see the v=DKIM1 string with the full key. If you see nothing, check the Host field for the doubled-domain mistake described earlier. For background, see what a DKIM record is.

Step 5: Add a DMARC Record

DMARC ties SPF and DKIM to the domain visible in the From address and tells receivers what to do when both fail. Google and Yahoo require a DMARC record for bulk senders, and it's good practice for every domain. Start in monitoring mode:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none collects aggregate reports at the rua address without affecting delivery. After a few weeks of reports showing that all your legitimate mail passes, move to p=quarantine and eventually p=reject. Choosing and tuning the policy is covered in what a DMARC record is and how to set one up.

Optional Records

• Custom URLs for Google services. You can create CNAME records such as mail.example.com pointing to ghs.googlehosted.com so users reach Gmail at a friendly address. Set this up from the Admin console so Google knows about the alias.
• Google Sites custom domains also use a CNAME to ghs.googlehosted.com.
• MTA-STS and TLS reporting add TXT records (_mta-sts and _smtp._tls) plus a hosted policy file to enforce encrypted inbound delivery. They're worth adding once the basics are stable.

Recommended Order and Timing

1. Add the verification TXT record and verify the domain.
2. Create user accounts in Google Workspace.
3. Lower the TTL on existing MX records (if migrating) and wait for the old TTL to expire.
4. Replace the MX records with smtp.google.com.
5. Add or update SPF.
6. Generate and publish DKIM, then start authentication. Google says DKIM can take up to 48 hours to start working after you add the record.
7. Add DMARC at p=none, then tighten over time.

If you're also changing DNS providers during this process, finish the move first. Combining a nameserver change with a mail cutover makes problems much harder to diagnose.

Verify Everything at Once

This short script uses dnspython to check all four mail-related records in one pass:

import dns.resolver

DOMAIN = "example.com"

def txt_values(name):
    try:
        answers = dns.resolver.resolve(name, "TXT")
        return [b"".join(r.strings).decode() for r in answers]
    except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer):
        return []

try:
    mx = sorted((r.preference, r.exchange.to_text()) for r in dns.resolver.resolve(DOMAIN, "MX"))
except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer):
    mx = []
print("MX:", mx)

spf = [v for v in txt_values(DOMAIN) if v.startswith("v=spf1")]
print("SPF:", spf if len(spf) == 1 else f"PROBLEM - found {len(spf)} SPF records")
print("SPF includes Google:", any("include:_spf.google.com" in v for v in spf))

dkim = txt_values(f"google._domainkey.{DOMAIN}")
print("DKIM published:", any(v.startswith("v=DKIM1") for v in dkim))

dmarc = txt_values(f"_dmarc.{DOMAIN}")
print("DMARC:", dmarc or "missing")

Install the library with pip install dnspython. The script joins multi-string TXT records (important for DKIM), flags duplicate SPF records, and reports anything missing. Google's own Check MX tool in the Google Admin Toolbox runs similar checks from Google's side.

Finally, send a message from a Workspace account to an external mailbox (for example, a personal Gmail address) and open Show original. You want to see SPF: PASS, DKIM: PASS, and DMARC: PASS.

Common Mistakes

1. Leaving old MX records in place. Mail splits between providers, and some messages never arrive in Gmail.
2. Two SPF records. Often caused by adding Google's SPF without removing the old provider's. Merge them into one.
3. Doubled domain in the host name. google._domainkey.example.com.example.com instead of google._domainkey.example.com.
4. Truncated DKIM keys. Some editors cut long values silently. Compare the published key to what the Admin console shows.
5. Clicking Start authentication too early. Wait until dig shows the DKIM record.
6. Deleting the verification record. Keep it so the domain stays verified.
7. Changing nameservers mid-setup. Records added at the old provider disappear once the new nameservers take over. Changes to nameservers affect mail in ways covered in how changing DNS affects email services.

---

Google Workspace DNS FAQ

Conclusion

Google Workspace needs five DNS records to work well: a verification TXT, a single MX record pointing to smtp.google.com, one SPF record that includes _spf.google.com, a DKIM key at google._domainkey, and a DMARC policy at _dmarc. Adding them in the right order — verify, create users, switch MX, then authentication records — keeps mail flowing throughout the migration.

The mistakes that cause trouble are almost always small: an old MX record left behind, a second SPF record, or a host name with the domain doubled. Verify each record with dig or the script above, then send a test message and confirm SPF, DKIM, and DMARC all pass. Once they do, your domain is set up to deliver reliably to every major mailbox provider.

Here are some useful references for Google Workspace DNS setup:

1. Google Workspace Admin Help: Set up MX records for Google Workspace email — Google's official MX record instructions.
2. Google Workspace Admin Help: Set up SPF — how to publish and combine SPF records for Workspace.
3. Google Workspace Admin Help: Set up DKIM — generating and enabling DKIM keys in the Admin console.
4. Google Workspace Admin Help: Set up DMARC — Google's guidance on DMARC policies and reporting.
5. Google Admin Toolbox: Check MX — checks a domain's MX, SPF, DKIM, and DMARC configuration for Workspace.