Overview

Setting up DNS records for Google Workspace is a common MSP task. Unlike Microsoft 365, which has a few quirks with legacy Skype for Business records and MDM enrollment CNAMEs, Google Workspace DNS is straightforward. One MX record (or five for legacy accounts), one SPF include, DKIM signing, and a DMARC policy — that's the full set.

This guide covers every record you need to configure, the values to use, and why each one matters. For the authoritative Google values, see their documentation on Set up MX records for Google Workspace and TXT record values.

What You'll Need Before Starting

• Admin access to the client's DNS registrar or hosting provider
• A Google Workspace admin account with super-admin privileges
• Domain verified in Google Workspace admin center (Admin > Domains > Verify Domain)

Required Records at a Glance

Google Workspace supports two MX record configurations:

New accounts (recommended): A single MX record:

Legacy accounts (still supported): Five MX records:

Both configurations are valid. Google recommends the single MX record for new accounts, but the five-record setup continues to work for existing accounts.

The sections below walk through each record in detail.

MX Records for Google Gmail

The MX record tells the internet where to deliver email for your client's domain. Google Workspace supports two configurations. For the official values and instructions, see Google's Set up MX records for Google Workspace guide.

Option 1: Single MX Record (New Accounts)

For accounts created after 2023, Google recommends a single MX record:

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

This simplifies configuration and Google's infrastructure handles redundancy internally.

Option 2: Legacy Five MX Records

For accounts created before 2023, or if you prefer the traditional setup:

yourdomain.com.    3600    IN    MX    1    ASPMX.L.GOOGLE.COM.
yourdomain.com.    3600    IN    MX    5    ALT1.ASPMX.L.GOOGLE.COM.
yourdomain.com.    3600    IN    MX    5    ALT2.ASPMX.L.GOOGLE.COM.
yourdomain.com.    3600    IN    MX    10    ALT3.ASPMX.L.GOOGLE.COM.
yourdomain.com.    3600    IN    MX    10    ALT4.ASPMX.L.GOOGLE.COM.

If your current MX records are working with the five-record setup, no changes are required.

How to Find the Correct Values

MX values for your specific domain can be found in the Google Workspace admin center:

1. Go to Admin > Domains > Manage Domains
2. Click on the domain you're configuring
3. Select View Generic Setup Instructions
4. Open the Step 2: Add MX records section

Priority and TTL

• Single MX: Set priority to 1 (highest priority).
• Legacy MX: Google uses priorities 1, 5, 5, 10, 10. The primary (1) has the highest priority. The two servers at priority 5 and two at priority 10 provide redundancy at each tier.
• TTL: 3600 seconds (1 hour) is standard. Lower to 300 if you're migrating and need faster propagation.

Important Notes

• If using the legacy five MX records, all five are required. Some MSPs omit the lower-priority backup servers, which works initially but removes redundancy. If the primary servers have issues, mail won't fail over to the backup servers if they don't exist in your DNS.
• Remove old MX records from previous mail providers once the migration is complete. Leaving stale MX records causes intermittent delivery issues.
• If using a third-party email filter (Mimecast, Proofpoint, etc.), the MX records may point to the filter instead of Google. The filter then routes to Google Mail. Don't override this if a filter is in place.

MX Record Verification

Single MX verification:

dig MX yourdomain.com +short
Should return: 1 smtp.google.com.
nslookup -type=MX yourdomain.com

Legacy MX verification:

dig MX yourdomain.com +short
Should return:
1 ASPMX.L.GOOGLE.COM.
5 ALT1.ASPMX.L.GOOGLE.COM.
5 ALT2.ASPMX.L.GOOGLE.COM.
10 ALT3.ASPMX.L.GOOGLE.COM.
10 ALT4.ASPMX.L.GOOGLE.COM.
nslookup -type=MX yourdomain.com

SPF Record for Google Workspace

SPF tells receiving mail servers that Google's mail servers are authorized to send email for your client's domain.

The Record

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

Starting with SoftFail (~all)

For Google Workspace, it's recommended to start with ~all (soft fail) rather than -all (hard fail). Here's why:

• Google Mail doesn't always route through Google's own servers — some large organizations route outbound mail through third-party gateways
• Marketing emails, transactional systems, and other integrations may also send from different IPs
• Starting with ~all lets you identify any legitimate senders that aren't covered before switching to -all

After verifying that all legitimate email sources are included in your SPF record, you can switch to -all for strict enforcement.

Combining with Other Senders

Most clients don't send email exclusively through Google Workspace. They might also use a CRM, helpdesk platform, or transactional email service. All senders need to be in the same SPF record — you can only have one SPF TXT record per domain.

; Google Workspace + HubSpot
yourdomain.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:spf.hubspot.com ~all"
; Google Workspace + Mailchimp
yourdomain.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:servers.mcsv.net ~all"
; Google Workspace + SendGrid
yourdomain.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
; Google Workspace + Salesforce
yourdomain.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all"
; Google Workspace + multiple services
yourdomain.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:spf.hubspot.com include:sendgrid.net ip4:198.51.100.25 ~all"

The 10-Lookup Limit

SPF has a hard limit of 10 DNS lookups. Each include: counts as at least one lookup. Google's include:_spf.google.com typically counts as 2 lookups on its own.

If you're running into the limit:

• Use ip4: for static IPs instead of include: (these don't count toward the limit)
• Audit the record — remove any services the client no longer uses
• Consider an SPF flattening service if you genuinely need more than 10 includes

For a full breakdown of SPF syntax and mechanics, see our guide on What Is an SPF Record?.

SPF Verification

dig TXT yourdomain.com +short | grep spf
Should return: "v=spf1 include:_spf.google.com ~all"

DKIM Setup for Google Workspace

DKIM adds a cryptographic signature to outgoing emails, letting recipients verify the message wasn't altered in transit and genuinely came from your domain. Google Workspace uses a TXT record at a specific selector for DKIM public keys.

How DKIM Works in Google Workspace

Unlike Microsoft 365, which uses CNAME records pointing to Microsoft's servers, Google Workspace requires you to generate a DKIM key pair directly in the Google Admin console and then publish the public key as a TXT record in your DNS.

Step 1: Generate the DKIM Key in Google Admin

1. Go to Admin > Apps > Google Workspace > Gmail > Authenticate email
2. Select the domain you want to configure
3. Click Generate new record
4. Choose the TXT record (not CNAME — Google Workspace uses TXT)
5. Copy the TXT record value (the public key) — you'll add this to your DNS

Google will generate a selector name (usually google by default) and a long TXT record value that looks like:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz...

Step 2: Add the DKIM TXT Record to Your DNS

The DKIM record is published at google._domainkey.yourdomain.com:

google._domainkey.yourdomain.com.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz..."

Step 3: Enable DKIM Signing in Google Admin

After adding the DNS record, go back to the Google Admin console and click Start authentication or Enable. It can take up to 48 hours for Google to detect the record and validate it.

Why the Selector Matters

The selector (google) allows Google to use different keys for different purposes while keeping the domain name the same. If you ever need to rotate keys, Google generates a new selector (e.g., google2024) while keeping the old one active until all cached DNS entries expire.

DKIM Record Structure

Verifying DKIM

dig TXT google._domainkey.yourdomain.com +short
Should return the full DKIM record value
In Google Admin, the DKIM status should show "Authenticated"

What If DKIM Fails?

Common causes for DKIM authentication failures:

1. DNS record not propagated yet — Wait up to 48 hours after adding the record
2. Incorrect record name — Must be exactly google._domainkey.yourdomain.com
3. Extra spaces or line breaks — The TXT record value must be exact
4. DKIM not enabled in Google Admin — The DNS record alone isn't enough; you must click Enable in the admin console

DMARC Record

DMARC ties SPF and DKIM together and tells receiving mail servers what to do when a message fails both checks. It also gives you reporting so you can see who's sending email as your client's domain. For the official values, see Google's TXT record values guide.

The Record

_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=quarantine; pct=100; rua=mailto:postmaster@yourdomain.com"

DMARC Policies Explained

Recommended Rollout

1. Start with p=none and set up a rua address to receive aggregate reports
2. Review reports for 2-4 weeks — identify any legitimate services failing SPF/DKIM
3. Fix any gaps (add missing SPF includes, enable DKIM for additional services)
4. Move to p=quarantine once you're confident
5. Move to p=reject when you're ready for full enforcement

A Practical Starting Point

; Monitoring only — start here
_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=none; rua=mailto:postmaster@yourdomain.com"
; Quarantine with reporting — move here after review
_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=quarantine; pct=100; rua=mailto:postmaster@yourdomain.com"
; Full reject — final state
_dmarc.yourdomain.com.    3600    IN    TXT    "v=DMARC1; p=reject; pct=100; rua=mailto:postmaster@yourdomain.com"

If you or your client uses a DMARC monitoring service (like Valimail, dmarcian, or EasyDMARC), point the rua address to that service instead for more readable reports.

DMARC Verification

dig TXT _dmarc.yourdomain.com +short
Should return: "v=DMARC1; p=quarantine; pct=100; ..."

Verifying Your Configuration

Once all records are in place, verify each one.

Using dig (macOS/Linux)

# MX Records (single MX)
dig MX yourdomain.com +short
Expected: 1 smtp.google.com.
MX Records (legacy five MX)
dig MX yourdomain.com +short
Expected: 5 MX records from ASPMX.L.GOOGLE.COM through ALT4.ASPMX.L.GOOGLE.COM
SPF (TXT record)
dig TXT yourdomain.com +short | grep spf
Expected: "v=spf1 include:_spf.google.com ~all"
DKIM
dig TXT google._domainkey.yourdomain.com +short
Expected: "v=DKIM1; k=rsa; p=..."
DMARC
dig TXT _dmarc.yourdomain.com +short
Expected: "v=DMARC1; p=quarantine; ..."

Using nslookup (Windows)

nslookup -type=MX yourdomain.com
nslookup -type=TXT yourdomain.com
nslookup -type=TXT google._domainkey.yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com

Online Tools

• MXToolbox (mxtoolbox.com) — Quick MX, SPF, DKIM, and DMARC lookups
• Google Admin Toolbox (toolbox.googleapps.com/apps/dig) — Web-based dig for any record type
• DMARC Analyzer (dmarcanalyzer.com) — DMARC record validation

Google Workspace Admin Center

The Google Workspace admin center has a DNS diagnostics tool:

1. Go to Admin > Domains > Manage Domains
2. Select your domain
3. Click Check DNS or View Setup Instructions

This will confirm whether Google can see your MX, SPF, and DKIM records.

Common Mistakes

These are the issues that come up most often when configuring Google Workspace DNS.

Missing Backup MX Records

Google requires all five MX records. Some MSPs configure only the primary server (priority 1) and skip the backup servers. This works fine until Google's primary server has issues — then mail delivery fails because there's no fallback.

Always include all five MX records.

Multiple SPF Records

A domain can only have one SPF TXT record. If a previous provider's SPF record is still present, you'll end up with two, and SPF validation will fail for both. Merge all senders into a single record.

; Wrong — two separate SPF records
yourdomain.com.    TXT    "v=spf1 include:_spf.google.com ~all"
yourdomain.com.    TXT    "v=spf1 include:_spf.otherprovider.com ~all"
; Right — combined into one
yourdomain.com.    TXT    "v=spf1 include:_spf.google.com include:_spf.otherprovider.com ~all"

Forgetting to Enable DKIM in Google Admin

Creating the DNS record is only half the job. You also need to click Enable or Start authentication in the Google Admin console for Google to actually start signing outbound mail.

Using ~all Indefinitely in SPF

Starting with a soft fail (~all) during testing is fine. But leaving it permanently means unauthorized senders get through with only a "suspicious" flag rather than being rejected. Move to -all once you've confirmed all legitimate senders are covered in your SPF record.

Incorrect DKIM Selector Name

The DKIM record name must be exactly google._domainkey.yourdomain.com. If Google generated a custom selector for you (which happens in some configurations), use that instead of google.

Skipping DMARC

SPF and DKIM without DMARC means you have no policy enforcement and no visibility into who's sending email as your client's domain. Even a p=none DMARC record with reporting gives you valuable data.

Frequently Asked Questions

How long does it take for DNS changes to propagate?

Most records propagate within 15-60 minutes, but it can take up to 48 hours depending on TTL settings and DNS caching. Google typically detects MX and SPF records within a few hours. DKIM can take up to 48 hours for Google to validate after you enable it.

Can I set up Google Workspace DNS records before migrating email?

Yes. You can add MX, SPF, DKIM, and DMARC records ahead of time. As long as the MX records are in place before you switch email routing, you'll receive mail at Google once the cutover happens.

What if the client uses a third-party email filter?

If the client uses Mimecast, Proofpoint, Barracuda, or a similar service, the MX record points to the filter, not directly to Google. The filter handles routing to Google Mail. Check the filter provider's documentation for their specific DNS requirements — they may have their own SPF include values or require different MX priorities.

How do I handle multiple domains in the same Google Workspace account?

Each domain needs its own complete set of DNS records. The DKIM record for each domain will differ (Google generates unique keys per domain), but the MX pattern, SPF include, and DMARC structure are the same.

What's the difference between Google Workspace DKIM and Microsoft 365 DKIM?

Microsoft 365 uses CNAME records pointing to Microsoft's DKIM servers. Google Workspace uses TXT records with the public key directly embedded. Both achieve the same result, but the DNS record format and setup steps differ.

Do I need any CNAME records for Google Workspace?

No. Unlike Microsoft 365 (which has Autodiscover CNAMEs for Outlook and MDM enrollment CNAMEs for Intune), Google Workspace doesn't require any CNAME records for standard email functionality. The only records you need are MX, SPF (TXT), DKIM (TXT), and DMARC (TXT).

Get Started with Unified DNS

Setting up Google Workspace DNS for one domain is straightforward. Setting it up for 50 client domains across different registrars is where it gets tedious. Unified DNS lets you view, modify, audit, and backup DNS records across Cloudflare, Porkbun, NameSilo, NameCheap, and more — from one dashboard. See SPF, DKIM, and DMARC status at a glance across your entire client portfolio.

Unified DNS is live — try it free for a month with code FREETRIAL2026 at billing setup. No commitment. Or contact us for a walkthrough.