If you're searching for how to set up DKIM in Google Workspace, you might have already done half of it without realising. Lots of businesses generate the key, publish the DNS record and stop there.
And DKIM still doesn't work.
The missing piece is a single button in the Google Admin console. Until you click it, Google keeps signing your emails with a Google-owned default domain rather than yours. Those signatures pass, but they don't align with your From address, so DMARC can't use them.
This guide walks you through the whole process in order: checking what Google is doing now, generating the key, publishing it without the common DNS mistakes, clicking the button that actually switches it on, and proving it works on a real email.
What Google Does Before You Set Up DKIM
Google Workspace signs outgoing email even if you've never touched DKIM. But by default, it signs with a Google-managed domain, often one ending in gappssmtp.com, not your own business domain.
In a header, it can look something like this:
From: Tom Hughes <tom@yourbusiness.co.uk>
DKIM-Signature: v=1; a=rsa-sha256;
d=yourbusiness-co-uk.(something).gappssmtp.com; s=(selector); ...
Authentication-Results: ...
dkim=pass header.d=yourbusiness-co-uk.(something).gappssmtp.comDKIM passes. But the signing domain isn't yourbusiness.co.uk, so it doesn't align for DMARC.
Your SPF record (if it includes Google) may still give you an aligned SPF pass for direct mail. But SPF breaks when emails are forwarded. Aligned DKIM is what keeps forwarded mail passing DMARC.
For why this matters, see why DKIM can pass while DMARC fails.
Check Your Current DKIM Status in Two Minutes
- Send an email from your Google Workspace account to a different address you control (a personal Gmail or Outlook.com account works)
- Open the original message ("Show original" in Gmail)
- Find the DKIM-Signature header and note the d= and s= values
- Look at Authentication-Results for the dkim= and dmarc= results
If d= is your domain and the selector is something like "google", you're already set up. If d= is a Google-owned domain, carry on.
What You'll Need
- Super admin access to the Google Admin console (or an admin with the right Gmail settings privileges)
- Access to your domain's DNS host
- Fifteen minutes, plus a short wait for DNS
If you're not sure who controls your DNS, check how to find who hosts your DNS first.
Step 1: Open the Authenticate Email Settings
In the Google Admin console, go to the Gmail settings and find "Authenticate email". Google's own guide to setting up DKIM has the current menu path if the screens have moved.
If your organisation has more than one domain, choose the one you want to set up from the domain list.
Step 2: Generate a New DKIM Key
Click to generate a new record. Google will ask a couple of things:
- Key length: choose 2048-bit if your DNS host supports it. It's the stronger option and what Google recommends. Some older DNS hosts can't handle long TXT values; if yours can't, use 1024-bit.
- Prefix selector: the default is "google". Unless you've got a reason to change it (like another service already using a "google" selector, which is rare), leave it.
Google then shows you two things:
DNS Host name (TXT record name): google._domainkey
TXT record value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(long key)Copy both exactly. The p= value is your public key, and it's long.
Step 3: Publish the TXT Record (Watch for These Three Traps)
In your DNS provider, create a new TXT record with the name and value Google gave you.
Trap 1: The double domain
Many DNS panels add your domain automatically. Type google._domainkey and the panel usually creates google._domainkey.yourbusiness.co.uk. If you type the full name, some panels create google._domainkey.yourbusiness.co.uk.yourbusiness.co.uk instead, which won't work.
Trap 2: A truncated key
The 2048-bit key is longer than some panels expect. Some split it into chunks automatically (that's fine). Some quietly cut it off (that's not fine). After saving, view the record and check the end of the key matches what Google gave you.
Trap 3: Extra characters
Copying from a web page sometimes adds spaces, line breaks or extra quotation marks. Paste into a plain text editor first if you're unsure, then copy from there.
Step 4: Check the Record Is Public
Before going back to Google, confirm the internet can see it.
dig +short TXT google._domainkey.yourbusiness.co.ukOr use Google Admin Toolbox Dig: choose TXT and enter google._domainkey.yourbusiness.co.uk.
You should see a value starting with v=DKIM1; k=rsa; p= and your full key. It might appear split into a few quoted strings. That's normal.
Step 5: Click "Start Authentication" (the Step Everyone Forgets)
This is the bit that catches people out.
Publishing the DNS record doesn't switch DKIM on. You have to go back to the Authenticate email page in the Admin console and click "Start authentication".
Until you do, Google carries on signing with its default domain, no matter how perfect your DNS record is.
If Google says it can't verify the record, it usually means DNS hasn't caught up yet or the record name is wrong. Recheck with dig, wait a little, then try again.
Once it works, the status should change to show that authentication is on for your domain.
Step 6: Prove It With a Real Email
Send a fresh email from Google Workspace to an outside mailbox you control. Open the original and check:
DKIM-Signature: v=1; a=rsa-sha256; d=yourbusiness.co.uk; s=google; ...
Authentication-Results: ...
dkim=pass header.d=yourbusiness.co.uk;
dmarc=pass header.from=yourbusiness.co.ukThree things to confirm:
- d= is your domain
- s= is your selector (usually "google")
- dkim=pass and dmarc=pass
If d= still shows a Google default domain, the email may have been sent before authentication started. Wait a little and send another.
Several Domains or Aliases? Set Up Each One
DKIM in Google Workspace is set up per domain. If your account has secondary domains or domain aliases that you send from, each needs its own key and its own "Start authentication".
Go through the domain list in the Authenticate email settings and check every domain you actually send from.
Domains you never send from should be locked down with restrictive records instead. See how to protect a parked domain.
Google DKIM Only Covers Google
Setting up DKIM in Google Workspace signs email sent through Google. It does nothing for:
- Newsletter platforms
- Invoicing tools
- Website forms
- CRMs and help desks
- Booking systems
Each of those needs its own DKIM, usually called "domain authentication" or "custom DKIM" in its settings.
This is the most common reason a business sets up Google DKIM, sees "DMARC pass" on staff email and then gets surprised when its invoices fail. Build a list of every tool that sends as your domain with the sender inventory template.
Moving From Another Provider? Don't Delete the Old Key Too Soon
If you've recently moved to Google Workspace from another email provider, your DNS might still contain the old provider's DKIM records.
Don't delete them on day one. Emails sent just before the switch might still be in transit, and they'll need the old key to verify.
Once you're confident nothing sends through the old provider any more (including any devices or apps you forgot about), remove the old selectors. The guide to switching email providers without losing email covers the full sequence.
Should You Ever Change the Selector or Rotate the Key?
The default "google" selector is fine for most businesses. You'd only change it if another service already uses "google" as a selector name on your domain.
Rotating the key (generating a new one) is good security practice from time to time. If you do, the safe pattern is to use a new selector name so old and new keys can coexist while emails in transit finish verifying. Follow Google's current guidance when you do it.
What to Do Next: SPF and DMARC
DKIM is one of three pieces. Check the other two:
- SPF: your record should include Google's servers. See the SPF record guide for Microsoft 365 and Google Workspace.
- DMARC: publish a record, read the reports and move towards enforcement once every sender aligns. Start with the DMARC setup guide.
Google's sender guidelines set out what Gmail expects from senders, including authentication requirements.
A Worked Example: The Accountancy Firm That Thought It Was Done
A fictional Bath accountancy practice moved to Google Workspace last year. Their IT contractor generated a DKIM key and added the google._domainkey TXT record to DNS. Job ticked off.
Months later, they set DMARC to p=quarantine. Within a week, clients who forward work email to personal accounts start reporting that the firm's emails are landing in spam.
A quick look at a header shows:
dkim=pass header.d=practice-co-uk.(something).gappssmtp.com
dmarc=fail header.from=practice.co.ukThe DNS record was perfect. Nobody had clicked "Start authentication". Google was still signing with its default domain.
One click later, new emails show d=practice.co.uk, DKIM aligns, and forwarded emails pass DMARC again.
The lesson: always confirm with a real header, never with the fact that a record exists.
Error Messages You Might See (and What They Mean)
"The DKIM record has not been published" or similar
Google can't see your TXT record yet. Check:
- Is the record name google._domainkey (not doubled up)?
- Is it a TXT record (not CNAME)?
- Has enough time passed for DNS to update?
- Did you save it at the DNS host that actually serves your domain?
The record shows up, but Google still won't verify it
Compare the value you published with the one Google generated, character by character. Truncated keys and stray spaces are the usual culprits.
DKIM fails on some emails but not others
Something may be modifying certain messages after Google signs them, such as an email signature tool, a disclaimer service or a security gateway that rewrites links. Compare a passing and a failing header. The DKIM selector troubleshooting guide helps.
If Your DNS Host Can't Handle a 2048-Bit Key
Some older DNS control panels limit the length of a TXT record. A 2048-bit key may be too long to paste in one go.
Your options:
- Check whether the panel lets you enter the key as multiple quoted strings (many do, and DNS treats them as one)
- Ask your DNS host's support how to add long TXT records
- Move DNS to a host that supports long records (carefully, copying every record first)
- As a last resort, generate a 1024-bit key instead
Whatever you choose, always confirm the public record shows the complete key.
Using an IT Provider? Ask These Questions
"Is DKIM set up?" isn't specific enough, because Google signs by default even when it isn't.
Ask instead:
- "Has 'Start authentication' been clicked for each domain we send from?"
- "Can you send me a recent email header showing d= set to our own domain?"
- "Are secondary domains and aliases covered too?"
- "Which key length and selector did you use?"
Quick Checklist: Google Workspace DKIM
[ ] Checked a real header: what is the d= value today?
[ ] Generated a key in Admin console (2048-bit if possible)
[ ] TXT record published at google._domainkey (not doubled)
[ ] Full key visible in a public DNS lookup
[ ] "Start authentication" clicked
[ ] Fresh test email shows d=yourdomain, dkim=pass, dmarc=pass
[ ] Repeated for every domain we send from
[ ] Other sending tools checked separatelyGoogle Workspace DKIM Alongside Other Platforms
Your domain can hold many DKIM keys at once, one per sending service, each under its own selector. Google uses google._domainkey by default. Your newsletter platform might use something like nl1._domainkey. Your invoicing tool might use another.
They don't interfere with each other, as long as each one has its own selector name. Problems only happen when two services try to use the same selector name, so if a platform asks you to publish a record at google._domainkey for something that isn't Google, stop and ask it for a different selector.
Frequently Asked Questions
Does Google Workspace sign emails with DKIM automatically?
It signs with a Google-managed default domain. To sign with your own domain (which DMARC needs), you must generate a key, publish it and click "Start authentication".
Should I use a 1024-bit or 2048-bit DKIM key?
Use 2048-bit if your DNS host supports long TXT records. Use 1024-bit only if your host can't store the longer key.
Why does Google say it can't find my DKIM record?
Usually because DNS hasn't updated yet, the record name has the domain added twice, or the key was cut off when pasting. Check the public record with a DNS lookup.
What is google._domainkey?
It's the DNS name where Google Workspace's DKIM public key lives, using the default selector "google".
Do I need DKIM if I already have SPF?
Yes. SPF breaks when emails are forwarded; DKIM usually survives. Aligned DKIM keeps your DMARC passing in more situations.
Can I use a different selector instead of "google"?
Yes. Google lets you set a prefix selector. Only change it if another service already uses "google" on your domain, and use exactly the selector name Google shows when publishing the record.
Do I need to do anything when I add a new user in Google Workspace?
No. DKIM is set per domain, not per user. New users sending from a domain that's already authenticated are covered automatically.
Will setting up DKIM in Google Workspace break my existing email?
No. Until you click "Start authentication", nothing changes. Once you do, Google simply starts signing with your domain instead of its default. Mail keeps flowing as normal.
How do I know if DKIM is working in Google Workspace?
Send an email to an outside account and check the header. DKIM-Signature should show d= as your domain, and Authentication-Results should show dkim=pass and dmarc=pass.
Sources and further reading
- Google Workspace Admin Help: Set up DKIM
- Google: Email sender guidelines
- Google Admin Toolbox Dig
- RFC 6376: DomainKeys Identified Mail