Enable DKIM for Google Workspace

Google Workspace DKIM is simpler than M365 in one important way and more demanding in another. Simpler: one selector, one record. More demanding: you publish the public key directly as a TXT record, and you manage rotation yourself.

The selector is always google. The record sits at google._domainkey.{domain}. Cathedra’s selector list includes it, so a correctly-configured Workspace tenant always passes the DKIM check.

This lesson walks the workflow on a client domain from start to finish.

The Google model in one paragraph

The Workspace admin console generates a key pair inside the tenant. Google shows you the public key as a TXT record value. You publish it in DNS. You then return to the admin console and flip a switch — Google calls it “Start authentication” — which tells Workspace to begin signing outbound mail with the matching private key.

Unlike M365, Google does not host the public key under a gappssmtp.com domain and ask you to CNAME to it. The TXT record lives directly under the client’s domain. The private key stays with Google.

Step 1 — Open the Workspace admin console

Sign into admin.google.com as a super admin. The DKIM controls live under Gmail.

Navigate to:

admin.google.com → Apps → Google Workspace → Gmail → Authenticate email

The Authenticate email page shows the list of domains in the tenant. Select the client’s primary domain from the dropdown.

For a fresh tenant, the panel reports:

Authenticate email
DKIM authentication is not set up yet.
Selector prefix: google
Key bit length: 2048

Step 2 — Generate the key

Click “Generate new record.”

A dialog opens with two fields:

• DKIM key bit length — default 2048. Use 2048 unless the client has a documented reason to drop to 1024. 1024-bit keys are deprecated for security reasons.
• Prefix selector — default google. Leave it as google. Cathedra’s selector list expects google; using a custom prefix here is the most common reason for a “no DKIM records found” warning on an otherwise-working Workspace tenant.

Click Generate.

Google produces a key pair inside the tenant. The dialog now shows two values:

• DNS Host name (TXT record name): google._domainkey
• TXT record value: a long string starting with v=DKIM1; k=rsa; p= followed by the base64-encoded public key.

Copy both. The TXT value is usually several hundred characters long. Take the whole thing.

Step 3 — Publish the TXT record in GoDaddy

Open the client’s DNS Management. Confirm the access model in IT Glue first.

Add the TXT record:

• Type: TXT
• Name (Host): google._domainkey
• Value (TXT Value): paste the entire string Google provided
• TTL: 1 hour

GoDaddy’s TXT value field has a length limit per record in some legacy UIs. The 2048-bit key value is long but should fit in the current GoDaddy editor. If GoDaddy rejects the value as too long, you are on an old DNS Management UI — contact the Service Desk lead to confirm the right path.

A note on quotes. Google’s UI shows the value with surrounding double quotes in some screenshots. Do not include the surrounding quotes when pasting into GoDaddy. GoDaddy quotes the value automatically on the server side. Pasting the quotes yourself produces a record like ""v=DKIM1; k=rsa; ..."" which receivers cannot parse.

Save.

Step 4 — Verify the record resolves

From terminal:

dig google._domainkey.isidoregroup.com TXT +short
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

The output should be the entire string Google provided. If dig returns nothing, the record didn’t publish or you used the wrong Host field. Check GoDaddy and re-save if needed.

Wait for the TTL of any previous (negative) cache to expire. Five minutes is usually enough.

Step 5 — Start authentication in the admin console

Return to the Authenticate email panel in admin.google.com. Click “Start authentication.”

Google performs a live lookup on the TXT record. If it cannot read the record (record not published, wrong Host, missing or wrong public key), the panel shows an error and Start authentication remains greyed out. Re-check DNS.

If Google reads the record successfully, the status updates:

Authenticating email with DKIM
DKIM signature is now being generated for outgoing messages sent through Google's mail servers.

The change takes a minute or two to fully take effect. Outbound mail from Workspace begins carrying a DKIM-Signature: ... d=isidoregroup.com; s=google; ... header from this point.

Step 6 — Confirm with Cathedra

Open Cathedra Workbench → Examen → Mail Diagnostics. Run against the domain.

Expected DKIM finding:

DKIM Records — status: pass
1 DKIM selector(s) found: google

The raw_value shows the actual TXT record. Cathedra confirms the public key is published and parseable.

Common pitfalls

Custom selector prefix. A tech changes the prefix from google to something else in step 2. The record publishes correctly, Workspace signs mail correctly, but Cathedra’s selector list does not include the custom prefix. The DKIM check reports “no DKIM records found.” Always leave the selector as google.

Pasted with quotes. As noted in step 3. The record looks correct in GoDaddy’s UI but receivers reject it. If the symptom is “Workspace says DKIM is on, Cathedra says no records found,” dig the record directly and look for double quotes around the value.

Old 1024-bit key in place. Some long-standing Workspace tenants set up DKIM years ago with a 1024-bit key and never rotated. The record exists, Cathedra passes the check, but the key is below modern strength. Regenerate at 2048 bits during the next maintenance window. Lesson 4.6 covers the rotation.

Two records at the same host. If a previous attempt left a stale TXT record at google._domainkey, the new record adds a second entry. Receivers may pick either one. Delete any stale record before publishing a fresh one. Unlike SPF, DKIM doesn’t have an explicit RFC rule against multiple records at the same selector, but in practice it breaks verification because receivers don’t know which key to use.

Domains beyond the primary

If a Workspace tenant has multiple verified domains (the primary plus aliases or secondary domains), DKIM has to be configured per domain. Repeat the workflow for each one. Each domain gets its own google._domainkey TXT record at its own apex.

What you should remember

• One selector: google. The record lives at google._domainkey.{domain}.
• Generate the key in admin.google.com → Apps → Google Workspace → Gmail → Authenticate email.
• Publish the TXT record in GoDaddy with the Host as google._domainkey and the value as Google provided, without surrounding quotes.
• Verify with dig, then click “Start authentication” in the Workspace console.
• Cathedra reports 1 DKIM selector(s) found: google on success.

Next: key rotation. Why M365 publishes two selectors, how rotation works in each provider, and what Cathedra sees during the transition.

---

Cathedra alignment: DkimRecordCheck.php — the `google` selector branch passes after this workflow