How to Set Up DKIM in Google Workspace
VigilDog Team · September 19, 2026 · 7 min read
Google Workspace sends your mail through Google's servers, but until you turn on DKIM, those messages go out unsigned, which makes them easier to spoof and more likely to land in spam. Setting up DKIM in Google Workspace takes about ten minutes of clicking and one DNS record, and it is the second leg of the SPF, DKIM, and DMARC tripod that mailbox providers now expect from every sender. Here is exactly how to do it, and how to confirm it actually works.
What DKIM does and why Workspace ships it off by default
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. The signature is generated with a private key Google holds, and receivers verify it against a public key you publish in your DNS as a TXT record. If the signature checks out, the receiver knows the message genuinely came from your domain and wasn't altered in transit.
Google Workspace does not enable custom DKIM automatically. Out of the box your mail may carry a generic signature from a google.com domain, which does not align with your own domain and does nothing for your reputation. To get the benefit, you generate a domain-specific key in the Admin console and publish it, and only then does DKIM start doing real work for you, especially once DMARC is in the picture and demands alignment.
Generate the DKIM key in the Admin console
Sign in to the Google Admin console at admin.google.com with an administrator account. Navigate to Apps, then Google Workspace, then Gmail, and open 'Authenticate email'. If you host multiple domains, select the one you want to sign from the dropdown at the top.
Set the key length to 2048 bits, this is the current recommendation and far stronger than the older 1024-bit option; only fall back to 1024 if your DNS provider cannot store the longer record. Leave the DKIM selector prefix as the default 'google' unless you have a reason to change it. Click 'Generate new record', and Google will show you a TXT record with a host of google._domainkey and a long value beginning v=DKIM1; k=rsa; p= followed by the public key.
Leave this page open. You will come back to it to switch signing on, but nothing happens until the DNS record is live and Google can see it.
Publish the TXT record at your DNS host
Log into wherever your domain's DNS lives, the registrar or DNS provider you use, and create a new TXT record. The host or name is google._domainkey (some providers want the full google._domainkey.yourdomain.com, others append the domain automatically, so check how your provider handles it). The value is the entire string Google gave you.
Watch for one gotcha with 2048-bit keys: the public key is long enough that some DNS interfaces require it to be split into multiple quoted strings within a single TXT record. Most providers handle this automatically, but if verification later fails, a mangled or truncated key is the first thing to check. Paste the value exactly, with no added spaces or line breaks inside the key itself.
Save the record. DNS changes can take anywhere from a few minutes to 48 hours to propagate, though in practice most providers publish within an hour. You can confirm it is live by querying dig TXT google._domainkey.yourdomain.com or by pasting your domain into a checker.
- Record type: TXT
- Host / name: google._domainkey
- Value: the full v=DKIM1; k=rsa; p=... string from the console
- Watch for 2048-bit keys split across multiple strings
Turn on signing and verify it works
Once the record has propagated, return to the 'Authenticate email' page in the Admin console and click 'Start authentication'. Google will look up the TXT record; if it matches the key it generated, signing switches on and the status changes to authenticating. If it errors, wait longer for propagation or double-check the record for typos and truncation.
Don't take the console's word for it, verify from the receiving side. Send a message to a Gmail account you control, open it, choose 'Show original', and look for DKIM: PASS with your domain listed. You can also send to a mailbox and read the Authentication-Results header, which spells out the DKIM, SPF, and DMARC verdicts together. If DKIM shows PASS and the signing domain (d=) is your own, you are done.
DKIM is one leg of three, finish the tripod
DKIM on its own is progress, but mailbox providers evaluate it alongside SPF and DMARC, and Gmail and Yahoo now require all three for bulk senders. Make sure your SPF record includes Google (v=spf1 include:_spf.google.com ~all) and that you have a DMARC record telling receivers what to do when authentication fails. Crucially, DMARC requires alignment, the DKIM signing domain must match your visible From domain, which is exactly why the domain-specific key you just published matters more than Google's generic signature. Our guide on fixing SPF, DKIM, and DMARC walks through getting all three consistent.
The hard part isn't the initial setup; it's noticing when something quietly breaks, a DNS edit that drops the DKIM record, a key rotation that never propagated, an SPF change that knocks alignment out. VigilDog monitors your email authentication, SPF, DKIM, and DMARC, and alerts you the moment a record goes missing or stops validating, so your deliverability doesn't degrade for weeks before anyone notices the spam-folder complaints. You can also spot-check your setup anytime with our free DMARC checker.
