The Google Admin console hands you three things: a host name, a very long value that starts with v=DKIM1, and a button labelled Start authentication. Almost every DKIM problem in Google Workspace happens in the gap between the second and the third. Your DNS host refuses the long value, or you click the button before the record exists, or the setup passes and your mail still fails DMARC.
This guide walks through the setup in the order that avoids those traps, and includes something most guides leave out: what real Google Workspace domains publish today. If the word selector is new to you, What Is a DKIM Selector and How Do You Find Yours? explains it first. If you run Microsoft 365 instead, the equivalent steps are in How to Set Up SPF, DKIM and DMARC for Microsoft 365 Without Breaking Your Website Email. Everything here was checked against Google’s own documentation and live DNS on 7 October 2026.
Before you generate the key: the 24 to 72 hour wait
You need a super administrator account that has the Gmail settings privilege. The key lives under Apps, then Google Workspace, then Gmail, then Authenticate email in the Admin console. There is one condition people miss: Google says that after you turn on Gmail for your organization, you must wait 24 to 72 hours before you can get your DKIM key. If you added Workspace this morning and the key page shows an error, nothing is wrong with your account. Come back in a day or two.
Pick the key length: 2048 unless your DNS host says no
Select your domain, click Generate new record, and Google offers two key lengths. 2048-bit is the recommended one. 1024-bit exists for a single reason: some DNS hosts do not accept the longer record. The default selector, the prefix that becomes part of the host name, is google.
On 7 October 2026 I looked up the default google selector for 29 well-known domains whose mail runs on Google. 27 of them publish a record at that name. The split:
| Key length | Domains | Record length | Examples |
|---|---|---|---|
| 2048-bit | 19 of 27 (70%) | 410 characters | Zapier, Asana, Webflow, Ahrefs, Vercel |
| 1024-bit | 8 of 27 (30%) | 234 characters | GitLab, Stripe, Shopify, Figma, HubSpot |
A 1024-bit key still verifies, and plenty of large companies run one. It is also the older choice, and Google recommends the longer key, so treat 1024-bit as a fallback for a stubborn DNS host and not as a preference. The two domains out of 29 with no record at the google name may sign under a different selector, or have DKIM set up for them automatically. Google notes that Squarespace domains are configured automatically, for example.
Why the long key breaks in some DNS panels
The 410 characters in that table are the problem. A single string inside a DNS TXT record can hold at most 255 characters, so a 2048-bit key cannot fit in one string. It has to be published as two strings in the same record, and the receiver joins them back together before checking the signature. Google’s own page puts it mildly: some domain providers limit TXT record length.
When I counted how the 19 long records are cut, 14 of them split at exactly 255 characters plus 155. The other five split elsewhere: 203 and 207, 251 and 159, 205 and 205, 236 and 174, 235 and 175. The cut position does not matter, because the pieces are joined in order. What matters is what your DNS panel does with the value you paste:
- It splits automatically. You paste the whole value and the panel handles it. This is the easy case.
- It rejects the value as too long. Cut the value into two pieces of 255 characters or fewer, and enter each piece in its own quotes if the panel supports multiple strings. Do not add a space where you cut.
- It will not take two strings at all. Go back to the Admin console, generate a 1024-bit key instead, and publish that. A working 1024-bit key beats a 2048-bit key that was never published.
The mistakes that come up most often are quotation marks pasted into the value field of a panel that adds its own, and a line break copied in from the console. Either one turns a good key into a record that fails silently.
Publish the record, then wait before you press the button
At your DNS host, create a TXT record with the host name Google shows you, normally google._domainkey, and the value that starts with v=DKIM1. Some hosts append your domain to the host name on their own, so entering the full name there produces google._domainkey.yourdomain.com.yourdomain.com. Check the saved result.
Then confirm that the world can see it before you touch the Admin console. From a command prompt:
nslookup -type=TXT google._domainkey.yourdomain.com 8.8.8.8You should see the full value come back. Google says it can take up to 48 hours for DKIM authentication to start working, and tells you not to click Start authentication until the DNS record is in place. Once the lookup shows your key, click Start authentication. The status should change to Authenticating email with DKIM.
A PASS in the header is not the finish line
Send a message from a Workspace mailbox to a Gmail address you control, open it, choose Show original, and read the summary at the top. DKIM should say PASS. Now look closer, because this is where setups that look finished are not.
Before you enable your own key, Google still signs outgoing mail, but with a shared signing domain on gappssmtp.com that has nothing to do with yours. That signature verifies, so a quick check shows DKIM: PASS. It cannot line up with your From address, though, which means DMARC has nothing from DKIM to work with and depends entirely on SPF. After a correct setup, the signature in the raw headers reads d=yourdomain.com and s=google. If you see gappssmtp.com as the signing domain, your own key is not active yet, whatever the summary says.
The mail Google never signs: your website
Everything above covers mail that leaves through Google’s servers. Your contact form, WooCommerce order emails and password resets are normally sent by WordPress itself, from your web server, using an address at your domain. Google never touches those messages, so your new key does not sign them. They need their own route: send them through an SMTP plugin connected to a proper mail service, and set up that service’s SPF and DKIM for your domain. SPF Records and Subdomains: How to Stay Under the 10-Lookup Limit shows what each extra sender costs against the 10-lookup limit, and the Microsoft 365 guide above has the full explanation of why the website is usually the sender that breaks DMARC.
Checklist before you close the tab
- 24 to 72 hours have passed since Gmail was turned on for the organization.
- A 2048-bit key published as a TXT record at
google._domainkey, or a 1024-bit key if your DNS host would not take the longer one. - The record answers a public lookup before you click Start authentication.
- A test message shows
d=yourdomain.comin the signature, notgappssmtp.com. - Website mail has its own signed route, because Google’s key does not cover it.
Checked for accuracy on 7 October 2026 against Google’s Workspace Admin documentation on setting up DKIM and live DNS lookups of the default google selector on 29 domains.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.