How does DKIM work in Google Workspace?

DKIM in Google Workspace is a domain signature you switch on in the Google Admin console. Open Apps > Google Workspace > Gmail > Authenticate email, pick your domain, generate a key, and publish it as a DNS TXT record at google._domainkey.. Then return to the same page and click Start authentication. Google signs your outbound Gmail with the private key, and receiving servers verify each message with the public key you published. Activation can take up to 48 hours.
Quick takeaways
- DKIM is enabled per domain in the Admin console under Apps > Google Workspace > Gmail > Authenticate email.
- Google uses the default selector
google, so the DNS host is alwaysgoogle._domainkey.. - Choose the 2048-bit key when your DNS host supports it, and 1024-bit only when it does not.
- After the record resolves you must click Start authentication, or your outbound mail stays unsigned.
- Activation can take up to 48 hours to begin working.
- Confirm it by checking for
dkim=passwith the selectors=googleon a message your domain actually delivered.
How DKIM works in Google Workspace
DKIM (DomainKeys Identified Mail) lets your domain attach a cryptographic signature to the mail it sends. When Google Workspace sends a message from your domain, Gmail signs selected headers and the body with a private key and adds a DKIM-Signature header. The receiving server reads the selector and domain from that header, fetches the matching public key from DNS, and checks the signature. RFC 6376 defines this process and stores every public key in a subdomain named _domainkey, so a lookup for the selector foo at example.com queries foo._domainkey.example.com. For the vendor-neutral background, read what DKIM is.
In Google Workspace the selector is chosen for you. Google's default prefix selector is google, which is the recommended option, so your public key lives at google._domainkey.. When you generate the key you pick 2048-bit, recommended whenever your DNS host supports it, or 1024-bit when it does not. Google keeps the private key and signs your outbound Gmail; you only publish the public half in DNS.
Authentication also affects whether your mail is accepted. Google's sender guidelines require every sender to set up SPF or DKIM, and senders of more than 5,000 messages a day to Gmail accounts to use SPF, DKIM, and DMARC together.
When Google Workspace DKIM fails or shows as not set up
A Workspace DKIM problem is usually one of a few specific conditions rather than a broken protocol. Use the symptom to narrow the cause, then confirm it against the published record and a real message.
The key was generated but Start authentication was never clicked. Generating the key and publishing the record is not the last step. Google's setup guide ends with a Start authentication click, and until you complete it your outbound mail stays unsigned.
The record is published at the wrong host. The selector fixes the host, so the TXT record must sit at google._domainkey.. If a checker reports no DKIM record found, the host name is the first thing to verify.
The DNS change has not propagated yet. After you add the key it can take up to 48 hours for DKIM authentication to start working, so a fail result in the first hours after publishing is expected.
DKIM passes but DMARC still fails. DKIM can verify while DMARC fails, because the signing domain is not aligned with the visible From domain. That specific case is covered in why a DKIM signature fails alignment.
Matching a single symptom to one of these causes is a reasonable starting point, not a guarantee. The record and message evidence below confirms which one applies.
What a Google Workspace DKIM record looks like
The record you publish is a single DNS TXT entry. The host name is fixed by the google selector, and the value carries the public key that Google generated for your domain.
Host/Name: google._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=<public key generated in the Admin console>
The value follows standard DKIM key-record syntax. RFC 6376 defines the tags: v= is the version DKIM1, k= is the key type rsa, and p= is the base64 public key. Google's guide shows the generated value starting with v=DKIM1. Before you save it, confirm three things: the host is exactly google._domainkey., the type is TXT, and the p= value is the key you generated for this domain rather than one copied from anywhere else.
How to check your Google Workspace DKIM
Confirm DKIM in two places: the record you published, and a message your domain actually sent.
Check the record first. A DKIM lookup for the google selector should return the public key at google._domainkey.. The Palisade DKIM checker resolves that host and shows the published v=DKIM1 record.
Then check a delivered message. Send mail from your domain to a Gmail account, open it, and choose More then Show original to see the full headers. RFC 8601 defines the Authentication-Results header that records the outcome; a working setup shows dkim=pass, and the DKIM-Signature header shows s=google with d= set to your domain.
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=google header.b=Ab1Cd2Ef;
spf=pass smtp.mailfrom=example.com;
dmarc=pass (p=NONE) header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google;
h=from:subject:date:message-id; b=Ab1Cd2Ef...
Reading both together tells you the record is published and that Google is signing real mail with the google selector.
Check that your Google Workspace DKIM record is published
Once you have clicked Start authentication and given DNS time to update, run your domain through the Palisade DKIM checker to confirm that google._domainkey. resolves and returns a v=DKIM1 public-key record. To see how DKIM sits beside SPF and DMARC, browse the email authentication guide.
A public record check confirms that the record is published and readable. It does not prove that production Gmail is signing every message, that the signature aligns for DMARC, or how any receiver will handle a given message.
Sources and further reading
Frequently asked questions
Keep going with AI
Ask AI how this applies to you
Take this guide to your assistant — each question opens pre-filled, with a link back to this page so it can read the details.

Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →


