Google Workspace DNS Setup

Google Workspace uses DNS to prove domain ownership, receive Gmail mail, authenticate outgoing mail, and enforce anti-spoofing policy.

Use this guide when DNScale hosts the authoritative DNS zone for a domain you are adding to Google Workspace.

Official Google references:

• Verify your domain with a TXT record
• Set up MX records for Google Workspace
• Set up SPF
• Set up DKIM
• Set up DMARC

Record Checklist

Do not paste the example verification or DKIM values from this page into production. Those values are unique to your Google Workspace account and domain.

1. Verify the Domain

In Google Admin console, add the domain and choose TXT verification. Google gives you a unique TXT value, usually starting with:

google-site-verification=

Create the record in DNScale:

Type: TXT
Name: @
Content: google-site-verification=<value-from-google>
TTL: 3600

Verify from the command line:

dig TXT example.com +short

Then return to Google Admin console and confirm ownership.

Keep the verification TXT record unless Google explicitly says it can be removed. Verification records are low risk and help avoid account revalidation problems later.

2. Route Mail to Gmail

Google's current Google Workspace MX record is:

Type: MX
Name: @
Priority: 1
Target: smtp.google.com
TTL: 3600

Some DNS interfaces require a trailing dot:

smtp.google.com.

DNScale normalizes record names for you, but the target should still be the exact mail exchanger hostname.

If the domain already receives mail somewhere else, plan the cutover:

1. Create all Google Workspace users and mailboxes first.
2. Lower old MX TTLs 24-48 hours ahead if possible.
3. Remove old MX records when you are ready for Gmail to receive new mail.
4. Add the Google Workspace MX record.
5. Verify from multiple resolvers.

Check:

dig MX example.com +short
dig MX example.com @1.1.1.1 +short
dig MX example.com @8.8.8.8 +short

Google notes that legacy MX records beginning with aspmx are still supported for older Workspace setups. If mail is working on a legacy setup, do not change it during an unrelated DNS cleanup.

3. Publish SPF

If Google Workspace is the only system sending mail for the domain:

Type: TXT
Name: @
Content: v=spf1 include:_spf.google.com ~all
TTL: 3600

If other systems send mail too, keep one SPF record and add their includes or IP ranges to the same record:

v=spf1 include:_spf.google.com include:amazonses.com include:servers.mcsv.net ~all

Do not create multiple SPF TXT records at the same name. Receivers treat that as an SPF error.

Check:

dig TXT example.com +short

Then count lookups before adding more senders. SPF has a 10-DNS-lookup limit. See SPF Record Explained for lookup-count troubleshooting.

4. Enable DKIM

In Google Admin console:

1. Go to the Gmail authentication settings.
2. Select the domain.
3. Generate a DKIM record.
4. Choose a 2048-bit key when your DNS host supports long TXT records.
5. Copy the selector and TXT value exactly.

Google's default selector is commonly:

google

That produces this DNS name:

google._domainkey.example.com

Create the DNScale TXT record:

Type: TXT
Name: google._domainkey
Content: v=DKIM1; k=rsa; p=<public-key-from-google>
TTL: 3600

Use the exact selector from Google if it is not google.

Check:

dig TXT google._domainkey.example.com +short

After DNS resolves, return to Google Admin console and enable DKIM signing.

5. Roll Out DMARC

Start with monitoring:

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc@example.com
TTL: 3600

After reports show legitimate mail passes SPF or DKIM alignment, move in stages:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Then:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

Do not move to reject until marketing tools, CRMs, ticketing systems, ecommerce platforms, and website mail all pass alignment.

Check:

dig TXT _dmarc.example.com +short

For the deeper policy model, read DMARC Explained.

DNScale API Example

You can also create records through the DNScale API.

curl -X POST "https://api.dnscale.eu/v1/zones/$ZONE_ID/records" \
  -H "Authorization: Bearer $DNSCALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "@",
    "type": "MX",
    "content": "smtp.google.com.",
    "priority": 1,
    "ttl": 3600
  }'

Use the dashboard for one-off setup. Use the API, Terraform, or DNSControl when you need repeatable onboarding across many domains.

Migration Checklist

Before changing MX:

• Google Workspace domain is verified.
• Users and mailboxes exist.
• Old provider export or migration is complete.
• Old MX TTL has been lowered and aged out.
• SPF includes every legitimate sender.
• DKIM record exists and signing is enabled.
• DMARC starts at p=none.
• Support team knows the cutover window.

After changing MX:

• dig MX returns only the intended Google Workspace MX.
• Test inbound mail from an external mailbox.
• Test outbound mail and inspect headers for SPF, DKIM, and DMARC.
• Watch DMARC aggregate reports for unknown senders.

Common Mistakes

Keeping old MX records

Old MX records can route some mail to the previous provider. Remove old MX records once Gmail should receive all new mail.

Creating two SPF records

SPF must be one TXT record at the domain. Merge all senders into one value.

Copying DKIM examples

DKIM values are unique. Copy the value generated by Google Admin console.

Moving DMARC too fast

p=reject is the destination, not the starting point. Start with reports, fix legitimate senders, then enforce.

Related Guides

• Email Security with SPF, DKIM, and DMARC
• SPF Record Explained
• DKIM Explained
• DMARC Explained
• DNS MX Record Explained