Google Workspace DKIM Record Setup, Without the Waiting Trap

Setting up the google workspace dkim record is a fifteen-minute errand wrapped around one honest wait - and the wait is where nearly everyone stubs a toe, because the final button in Google's console is not a save button but a live DNS check that fails cheerfully until your record has propagated. This guide walks the exact console path, the two decisions along the way (key length and selector), the waiting trap itself, and the parts the basic instructions skip: what Workspace signs with before you do this, and what changes when your tenant has more than one domain.

What signs your mail before you turn this on

A Workspace domain that never configured DKIM still sends signed mail - Google signs everything. But it signs with a fallback identity on a Google-owned domain (the gappssmtp.com pattern you may have seen in message headers), not with yours. The signature is cryptographically valid and completely useless for you: DMARC requires the signing domain to align with your From domain, and a fallback signature aligns with nothing you own. Since the 2024 sender requirements made DMARC-passing mail the norm for bulk sending - and receivers score aligned authentication for everyone - "Gmail already signs it" is the most common false comfort in Workspace administration. The whole point of this errand is making the d= in your signatures say your domain.

Generating the google workspace dkim record in the Admin console

1. Sign in at admin.google.com as a super admin and go to Apps → Google Workspace → Gmail → Authenticate email.
2. In the selected-domain dropdown, pick the domain you're configuring.
3. Click Generate new record. Two options appear:
   • Key length: choose 2048-bit. Choose 1024 only if your DNS host truly cannot hold a long TXT value - a rarity today, and worth changing hosts over rather than halving your key strength.
   • Selector prefix: leave it as google unless a previous key already occupies that selector (the regeneration case below).
4. Google displays the DNS record: hostname google._domainkey and a TXT value beginning v=DKIM1; k=rsa; p=.... Copy both parts exactly.
5. At your DNS host, create the TXT record: Host google._domainkey (watch for panels that auto-append your domain), value pasted whole. Hosts split values longer than 255 characters into concatenated quoted strings automatically; if yours makes you split manually, break the string anywhere inside the key and keep every character.

Nothing is signing differently yet. Generation creates the key pair and shows you the public half; Google keeps signing with the fallback until the final step.

The waiting trap: Start authentication is a check, not a save

Back on the Authenticate email screen sits Start authentication. Clicking it makes Google resolve google._domainkey.yourdomain.com right then; only on success does Gmail begin signing with your new key. Google's documentation says propagation can take up to 48 hours - in practice most DNS hosts publish within minutes, but registrar-default nameservers and long TTLs do sometimes take hours.

So the failure pattern writes itself: paste record, click immediately, get "record not found", assume the record is wrong, delete it, re-create it, click again, repeat. If the value and hostname match what Google displayed, the record is not wrong - it is early. Confirm propagation yourself before clicking: Google's Admin Toolbox Dig tool (toolbox.googleapps.com/apps/dig) queries from Google's own resolvers, which is the vantage point that matters here. When a TXT query for google._domainkey.yourdomain.com returns your key there, Start authentication will succeed.

Once it engages, the console status flips to Authenticating email with your selector shown - and from that moment, outgoing Gmail signs as you.

Verifying end to end

Trust, then verify with a real message. Send from the configured domain to any Gmail mailbox, open the message, and use Show original: the summary block should read DKIM: 'PASS' with domain yourdomain.com. In the collapsed message view, the "signed-by" line should also show your domain rather than a gappssmtp hostname. If PASS names the wrong domain, the key engaged but for a different sending path than you tested - aliases and secondary domains each authenticate separately, which is the next section.

For the DNS half in isolation, dig TXT google._domainkey.yourdomain.com from any terminal - or the Admin Toolbox - shows exactly what receivers see, including whether the key survived the DNS panel intact.

Tenants with more than one domain

DKIM in Workspace is strictly per-domain. A tenant with a primary domain plus secondary domains repeats the whole generate-publish-activate cycle for each one; a key on the primary covers nothing else. Domain aliases are the subtle case - mail sent as an alias domain also needs that alias's own DKIM record generated and activated, or it rides the fallback signature and fails alignment even while your primary domain is perfectly configured. The Authenticate email screen's domain dropdown is the checklist: every domain listed there that ever appears in a From line deserves its own green "Authenticating email" status.

Regeneration, rotation, and the stuck states

To rotate a key (annual rotation is respectable hygiene; immediate rotation is mandatory if the private side may have been exposed - though with Workspace, Google custodians the private key, so exposure normally means a very different incident): click Generate new record again, publish the new TXT, and Start authentication once it resolves. If you generate onto the same selector, the console replaces the record value and there is a window where DNS must be updated before re-activation - the reason the selector-prefix option exists is to let you stage google2 alongside google and switch with no gap.

Two stuck states cover most support threads. "Record not found" that persists past a day: the record is at the wrong hostname - usually google._domainkey.yourdomain.com.yourdomain.com from an auto-appending panel, visible instantly in a dig. Status shows Authenticating but DMARC reports show failures: some other system - a printer relay, a marketing platform - is sending as the domain unsigned; the Workspace key only covers mail Gmail itself sends. Both are ten-minute diagnoses with the two verification tools above, which is the enduring virtue of this setup: every part of it is inspectable from outside, and none of it is faith.

Frequently asked questions

What is the default DKIM selector for Google Workspace?

google - the record lives at google._domainkey.yourdomain.com. The selector prefix can be changed at generation time, which is mainly useful for staging a replacement key alongside an existing one.

Why do my Gmail messages show gappssmtp.com instead of my domain?

That is Google's fallback signature, used when DKIM was never activated for your domain. It is valid but does not align with your From domain for DMARC - generate and activate your own key in Admin console → Gmail → Authenticate email.

How long does Google Workspace DKIM take to activate?

The record generates instantly; Google quotes up to 48 hours for DNS propagation before Start authentication succeeds. Check propagation with Google's Admin Toolbox Dig tool and click the button only once the record resolves.

Do secondary domains in Google Workspace need their own DKIM records?

Yes - DKIM is per-domain, including domain aliases. Repeat generate, publish, and Start authentication for every domain in the tenant that appears in a From address.