DKIM on Google Workspace: One Key Per Domain, Verified From Outside

A team connects thirty domains to Google Workspace for an outbound programme, generates a DKIM key for each in the Admin console, pastes each one into DNS, and a week later a third of them are still failing authentication at Gmail. Nothing in the console said anything was wrong. On several of them, the console is still showing a warning that the DNS records need updating, which is documented behaviour and means nothing.

Half the difficulty with DKIM on this platform is that the work happens in two places and only one of them reports errors. Google generates and holds the private key. Your DNS host holds the public half, under a name that has to match exactly what a receiving server will ask for. Between those two systems there is no error channel at all.

One naming note before the procedure, because it accounts for a lot of search traffic and no technical difference. G Suite was renamed Google Workspace, so guidance written for G Suite DKIM and guidance written for Google Workspace DKIM describe the same product and the same records. The console layout has moved since then; the record shape has not.

Generating the key, and the two choices in the dialog

The key is generated inside the Admin console under Apps, then Google Workspace, then Gmail, then Authenticate email, then Generate New Record. Two settings appear in that dialog and both are decisions rather than defaults to click through.

Key length. Google offers 2048 and 1024 bits, and its guidance is unambiguous about which to prefer: select 2048 "if your domain provider supports 2048-bit keys", because "longer keys are more secure than shorter keys". Take the longer key. The reason 1024 still exists at all is a DNS limitation rather than a cryptographic one, and RFC 8301 records the history: widely used DNS configuration software "only handles a single 256-octet string in a TXT record, and RSA keys significantly longer than 1024 bits don't fit in 256 octets". The same document requires at least 1024 bits and recommends at least 2048.

The practical consequence of choosing 2048 is that the published record has to be split into multiple quoted strings that the resolver concatenates. Some DNS panels do that for you, some truncate silently, and Google flags the risk in passing: "Some domain providers limit TXT record length."

Selector prefix. Google's default prefix is google, and it recommends keeping it. The exception is stated in the same place and is the one that catches domains with a history: "If your domain already uses a DKIM key with the prefix google, enter a different prefix in this field." A second key published at a name that already holds one does not add a signer. It leaves two records at one hostname, which RFC 6376 makes explicitly undefined behaviour rather than a clean error, so the symptom is intermittent verification rather than a consistent failure.

Publishing it, and the ordering that matters

The record is a TXT record. Google's own field mapping is worth following literally: the host, which some panels call Name, Hostname or Alias, is the string ending _domainkey, and for the default prefix that reads google._domainkey. The value is the key string, starting v=DKIM1.

That hostname is fixed by the specification rather than by Google. RFC 6376 states that "All DKIM keys are stored in a subdomain named _domainkey", queried as <selector>._domainkey.<domain>, which is why the selector cannot be invented locally and why two platforms signing for one domain need two different selectors rather than one shared record.

The ordering trap is in Google's instructions and easy to read past. After generating the record, Google says plainly: "Do not click Start Authentication yet. You'll do that later." Publish the DNS record first, then return to the console and click Start authentication. Doing it the other way starts signing with a key no receiver can fetch.

1. Step 1Generate in the Admin console

   Apps, Google Workspace, Gmail, Authenticate email, Generate New Record. Choose 2048 bits and keep the google prefix unless it is taken.

2. Step 2Publish at your DNS host

   A TXT record with host google._domainkey and the generated key as the value. Read the saved record back.

3. Step 3Start authentication in the console

   Only after the record is published. The status changes to Authenticating email with DKIM.

4. Step 4Prove it at a receiver

   Send to a mailbox you hold elsewhere and read DKIM in the Authentication-Results header.

The four things that go wrong, and how each announces itself

The console keeps telling you to update DNS after you already have. Google documents this outright: the Authenticate email page "might continue to display this message for up to 48 hours: You must update the DNS records for this domain. If you've correctly added your DKIM key at your domain provider, you can ignore this message." It is the single most reported non-problem on this platform, and chasing it leads people to regenerate a key that was fine, which produces a real problem.

The host field ends up doubled. DNS panels differ on whether they want the label alone or the full hostname, and pasting google._domainkey.acme.com into a field that appends the zone for you publishes at google._domainkey.acme.com.acme.com, which resolves to nothing and looks perfectly normal in the interface. Read the saved record back rather than trusting the form.

The key was truncated on save. A 2048-bit key exceeds what fits in one DNS string, and a panel that quietly cuts it produces a record that is present, well formed at a glance, and cryptographically useless. The tell is a record that reads correctly and stops abruptly.

You tested by emailing yourself. Google states the limitation directly: "You can't verify DKIM is on by sending yourself a test message." Internal mail does not take the path that produces the header you are looking for. Send to an account you hold at another provider, open the full headers, and find Authentication-Results, where the DKIM result should read as a pass.

A Workspace DKIM record that is actually working

• ✓Yes: The saved host reads google._domainkey and not google._domainkey.yourdomain.com.yourdomain.com
• ✓Yes: The full key survived the save, with nothing lost at the end
• ✓Yes: Exactly one DKIM record answers at that hostname
• ✓Yes: Start authentication was clicked after the record was published, not before
• ✓Yes: A message to a mailbox at another provider shows a DKIM pass in Authentication-Results
• ✕No: The console warning about updating DNS was treated as evidence of a fault
• ✕No: The test was a message sent to yourself

The per-domain tax nobody budgets for

The sentence in Google's documentation that matters most to an outbound programme is the least dramatic one on the page: "If you are setting up DKIM for more than one domain, complete these steps for each domain. You must get a unique DKIM key from the Admin Console for each domain."

There is no shared key and no inheritance. A key published on acme.com does nothing for try-acme.com, even under one Workspace account, one registrar and one sending platform. Thirty domains is thirty console visits, thirty DNS records, thirty read-backs, and thirty Start authentication clicks in the right order. Google's stated propagation allowance applies to every one of them: "After adding a DKIM key, it can take up to 48 hours for DKIM authentication to start working."

That arithmetic is the argument for treating DKIM as part of provisioning a sending domain rather than as a launch checklist item. A domain that starts sending unsigned is asking receivers to build a reputation for an identity they cannot verify, which is the slowest possible way to warm anything.

It is also the argument for reading the record from outside rather than from the console. A missing record and a working record are indistinguishable from inside the sending platform, because the platform is reporting on what it was told to do.

Where this connects to the rest of authentication

A perfect DKIM key can still leave you failing DMARC, because DMARC does not ask whether DKIM passed. It asks whether DKIM passed for the domain in the visible From header. Signing on Google's default selector for your own domain satisfies that; a third-party platform signing with its own domain does not, and that is the first entry in the six causes of DMARC failure.

DKIM is also the durable half of the pair. SPF breaks on forwarding and stops evaluating entirely once a domain crosses its lookup budget, and the signature survives both, which is what keeps DMARC passing when SPF has quietly stopped contributing. The tags inside the key record, including the two that can switch it off while looking valid, are in the DKIM record in practice, and the concept sits at DKIM. The registrar-side version of this same handoff, where the panel rather than the console is the problem, is in DKIM on GoDaddy. All three records side by side are in the SPF, DKIM and DMARC setup guide.

We authenticate every sending domain before it carries a single message and run one message per campaign, so a domain that fails DKIM does not get a second attempt at the same person under a different pretext. That makes the read-back part of launching rather than part of troubleshooting.

If you would rather not own the authentication layer across a domain portfolio, we run the sending infrastructure as part of the engagement.

The short version

Generate the key in the Admin console under Apps, Google Workspace, Gmail, Authenticate email. Choose 2048 bits, keep the google prefix unless the domain already has a key under it, and publish a TXT record with the host google._domainkey at your DNS provider. Then, and only then, click Start authentication.

Read the saved record back to catch a doubled host or a truncated key, and prove the result at a mailbox held somewhere else, because Google states you cannot verify DKIM by emailing yourself. Ignore the console's warning about updating DNS for up to 48 hours after you already have, since Google documents that message as expected. Every domain needs its own key from the console, so a fleet of sending domains is that whole procedure repeated once per domain with no inheritance anywhere.

Google Workspace procedures and recommendations are per Google's published Set up DKIM documentation, verified as of August 2026. Specification behaviour is per RFC 6376 and RFC 8301. Verify current interface steps with the source before relying on them.

Sources: Set up DKIM, Google Workspace Admin Help, RFC 6376, RFC 8301