Defaults.Exposed › Setup walkthroughs › DKIM › Google Workspace

Google Workspace DKIM setup

This job runs across two companies’ control panels, and nobody tells you that up front, which is why it stalls. Google mints the key in the Admin console. Somebody else, whoever answers DNS (Domain Name System) for your domain, publishes it. Then you return to Google and click one button to start the signing. Miss that last button and the key sits in DNS doing nothing.

What Google does and does not do here

Google Workspace generates the key pair for your domain and keeps the private half inside its own systems, where it signs each outgoing message. What it gives you is the public half and a selector, which for Google defaults to google. A receiving server pulls that selector out of the DKIM-Signature header on your message, looks up google._domainkey.yourdomain.com, and checks the signature against the key it finds.

Google publishes nothing into DNS by itself. The Admin console generates the value and, after you click Start authentication, comes back to look for it, but the zone belongs to whichever nameservers your domain delegates to. Google’s own nameservers answer for 10,774,487 domains in the October 2026 census, 3.30% of all domains that have nameservers, so for some readers both halves happen inside Google products. For most, the second half happens elsewhere. The DKIM guide covers what the receiving server does with the result.

The value Google gives you

Google issues a TXT (Text) record. The value opens v=DKIM1; k=rsa; p= and then runs on for hundreds of characters of base64 with no spaces in it, and the p= tag carries the key itself.

When you generate, Google asks for a key length. Take the 2048-bit default. The 1024-bit option exists because some DNS hosts historically choked on a value that long, and if your host turns out to be one of those, that limit is the only reason to consider the shorter key. Google also lets you set the selector prefix at generation time. Leave it on google unless you have a specific reason, because everything downstream, including most checkers, expects it.

Many DNS hosts split a long TXT value across several quoted strings when they save it. That is normal, Google reads it back correctly, and nothing is wrong, provided nothing was truncated and no stray spaces or line breaks were introduced during the copy.

Generate, publish, then start authentication

1. Sign in to the Google Admin console at admin.google.com with an administrator account.
2. Go to Apps > Google Workspace > Gmail, then open Authenticate email, which is the DKIM (DomainKeys Identified Mail) section.
3. Select the domain from the list on that page.
4. Click Generate new record and take the default key length of 2048-bit.
5. Copy the DNS host name or selector Google shows, which for Google is google._domainkey.
6. Copy the TXT record value Google shows, beginning v=DKIM1; k=rsa; p= followed by the long public key string.
7. Sign in to the DNS host and open the DNS settings for the domain, under DNS, Records, or Advanced DNS.
8. Add a new record, choose TXT, enter google._domainkey in the Host or Name field, paste the long key value into the Value field, leave TTL (Time to Live) on the default, and save.
9. Return to the Authenticate email page in the Google Admin console and click Start authentication.

Laid out the way the DNS host will want it, the record is this:

Host:  google._domainkey
Value: v=DKIM1; k=rsa; p=<the long public key string Google generated for this domain>

In the Name or Host field enter only google._domainkey, because the DNS host appends the domain name automatically; adding the domain again produces a broken host such as google._domainkey.yourdomain.com.yourdomain.com. In the Value field paste the plain key string Google produced, without adding extra quote marks, since most DNS hosts add the quotes themselves.

Before you leave the DNS screen, compare the last few characters of what you pasted against the Admin console page. A value that stopped short looks fine in a record list and will never verify.

Traps specific to Google Workspace

• Publishing the record in DNS is not enough on its own. Skipping the Start authentication click leaves the key sitting in DNS while Google never signs outbound mail with it.
• The host in DNS must match the selector Google expects, google._domainkey, character for character, because that is how the receiving server finds the right key.
• Paste the plain value rather than adding a second set of quote marks, since most DNS hosts already wrap the value in quotes and a manually added pair corrupts the record.
• Generating a new record for a domain that already has one replaces the value you need to publish. If you click Generate new record again after publishing, the record in DNS no longer matches the key Google will sign with.
• Each domain in the account is authenticated separately. Turning it on for one does nothing for a second domain or for an alias domain that sends in its own name.

While you are in the DNS screen, your SPF record is usually the other thing Google asks for. That is a separate TXT row at Host @, so keep the two apart and do not paste either value into the other’s row.

Save, wait, then check

Google can take from a few minutes up to a couple of hours after the record is saved before it can confirm the record and DKIM starts validating. The generated selector and value stay on the Authenticate email page in the Admin console until they are copied across, so you can always go back and compare against what you published.

If clicking Start authentication cannot find the record yet, wait and click it again once DNS has had time to update.

Once Google reports authentication as started, run the free scan against your domain. It requests the selector from DNS the way Gmail’s own receiving side would and reports whether a usable key answered.

How the scan grades this record: the DKIM check, with its pass and fail rules and how many domains pass it.

A second check covers the signing as well as the publishing, which matters here because the two are separate steps. Send a message from the domain to an outside mailbox you can open, then look at its Authentication-Results header. dkim=pass with your domain in header.d= means Google is signing and the key you published verifies the signature.

When the scan comes back empty

Work through it in order: the host spelling in DNS first, then whether the nameservers really point at the DNS host you edited, then the tail of the pasted value, then whether Start authentication was ever clicked.

If all four are right, consider the limits of any checker. There is no way to list the DKIM records on a domain, so a checker has to ask for selectors by name and can only ask for the ones it knows to try. google is one of the best known, so this rarely affects a Workspace domain, though it is why the census figure sits where it does: of the 76,563,365 domains where the census could run the DKIM check, it found a key at a known selector on 38,666,798 (50.5%) and no key at any selector it tried on the other 37,896,567 (49.5%). That second group includes the domains whose keys sit under a selector the census doesn’t try.

If you inherited the domain and are not certain which selector is live, finding your DKIM selector shows how to read the s= tag out of the headers of a message already sent. And if DKIM passes while DMARC (Domain-based Message Authentication, Reporting and Conformance) still fails, the DMARC piece covers the alignment rule that decides it.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.