Google Workspace signs your mail with your domain’s DKIM key only after two things happen: the TXT record from the Admin console is published in your DNS, and you click Start authentication. Check the record below; if it’s right, the page tells you the step that’s left.
Last verified 9 October 2026.
You’ll see the status in the Google Admin console under Apps > Google Workspace > Gmail > Authenticate email, once you select the domain. Google’s troubleshooting page says:
If you get a “Not authenticating” error after you create a DKIM record and add it to your domain, you need to complete your setup. Recommended step: Go to the Authenticate email page and click Start authentication.
Google’s setup has three steps, in this order:
google._domainkey) and whose value is the TXT record value shown, which starts with something like v=DKIM1.So “Not authenticating” is a setup status, not a bounce. Mail still goes out, but without your domain’s DKIM signature, so it can’t pass DMARC through DKIM. DMARC then rests on SPF alone, and forwarded mail, which often fails SPF, can fail DMARC. Google’s Email sender guidelines require SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day to personal Gmail accounts, and say messages that aren’t authenticated “might be marked as spam or rejected with a 5.7.26 error”. See fixing Gmail’s 550 5.7.26 bounce.
Timing, also from Google: “After adding a DKIM key, it can take up to 48 hours for DKIM authentication to start working.” The Authenticate email page “might continue to display this message for up to 48 hours: You must update the DNS records for this domain. If you’ve correctly added your DKIM key at your domain provider, you can ignore this message.” And after you turn on Gmail for a new organization, “you must wait 24–72 hours before you can get your DKIM key in the Admin console.”
Sources: Google Workspace Help, Troubleshoot DKIM issues and Set up DKIM (both last updated 7 October 2026; checked 9 October 2026). DKIM key records: RFC 6376 §3.6.1.
Enter the domain selected under Authenticate email. Leave the selector as google unless you typed a different prefix selector when you generated the record. The lookups run in your browser against public DNS.
Next steps
This reads public DNS only. It can’t see the status in your Admin console, which key the console generated, or whether your messages are signed. Compare the record shown here with the TXT record value in the Admin console.
What this can and can’t tell you: it queries <selector>._domainkey.<domain>, the name receivers use, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails), follows CNAMEs, and reads the record’s v=, k= and p= tags the way a verifier does, including the RSA key size read from the key itself. It flags more than one TXT record at the name. When nothing is there, it also looks for the record with your domain typed twice. A lookup that fails shows as “couldn’t check”, never as missing. For any other selector, or a header from a failing message, use the DKIM key check.
The record is published and checks out, but the status hasn’t changed. This is the case Google’s troubleshooting page names for “Not authenticating”: go to Authenticate email, select the domain and click Start authentication. Google’s Step 1 says not to click it yet, so it’s easy to forget to come back once the record is in DNS.
Google allows up to 48 hours for DKIM authentication to start working after you add the key. If this page already shows a valid key, the record is visible to public resolvers; click Start authentication and give it time.
Google’s example host name is just google._domainkey, and many DNS hosts add your domain to that field themselves. On those hosts, typing the full name produces google._domainkey.example.com.example.com, where receivers never look. The checker looks for this when the record is missing. Delete that record and add it again with only google._domainkey as the name.
Clicking Generate new record updates the TXT record value in the console. If someone generated a record after the old one was published, DNS holds a valid key that isn’t the one the console shows. Google’s advice: “Compare the DKIM TXT record value at your provider with the value in your Admin console”. Publish the console’s value. Setting up several domains? “You must get a unique DKIM key from the Admin Console for each domain.”
Google: “Most DKIM TXT records can have up to 255 characters. You can not enter a 2048-bit key as a single text string with a 255-character TXT record limit. Your DKIM key might be truncated, or your DKIM records might be sent out of order.” Google’s fix is to split the key into several strings, put each inside quotes, and enter them one after another in the value field, or to generate a 1024-bit key. The checker flags quotes left inside the value and keys that don’t decode.
An old record left beside the new one makes two TXT records at the same name. RFC 6376 §3.6.2.2 says the results are then undefined. Keep only the one that matches the Admin console.
Google Workspace gives a TXT record. A CNAME at google._domainkey (left over from another service, or added by mistake) sends receivers to someone else’s record. Delete it and add the TXT record.
If google was already taken and you typed another prefix when you generated the record, check that selector instead. For a subdomain, the record lives under it (google._domainkey.mail.example.com); Google says to check with your domain provider how to add a TXT record for subdomains.
Then the cause is after signing. Google lists forwarding, outbound gateways that change messages (such as adding a footer: “body hash did not verify” in Authentication-Results), and signatures listed after the first five: “Gmail checks only the first 5 signatures”. If DKIM passes but DMARC fails, see DMARC alignment failed.
Publishing the record is only part of the setup. Google says that if you get a “Not authenticating” error after you create a DKIM record and add it to your domain, you need to complete your setup: go to the Authenticate email page and click Start authentication. Check first that the record is at google._domainkey on your domain and matches the TXT record value in the Admin console.
Google says that after adding a DKIM key, it can take up to 48 hours for DKIM authentication to start working. The Authenticate email page can also keep showing “You must update the DNS records for this domain” for up to 48 hours; Google says you can ignore it if you added the key correctly.
No. It reads public DNS only: the record receivers fetch at the selector name. It can’t see the status in the Admin console, which key the console generated, or whether your messages are signed. To confirm signing, send a message to someone else’s Gmail or Google Workspace address and look for dkim=pass in its Authentication-Results header.
Google says to choose 2048 if your domain provider supports 2048-bit keys, since longer keys are more secure, and 1024 if your domain host doesn’t support them. A 2048-bit key is longer than the 255 characters one TXT string holds, so some DNS hosts need it entered as several quoted strings.
Usually the host added your domain to the name you typed. If you enter google._domainkey.example.com in a field that already adds example.com, the record ends up at google._domainkey.example.com.example.com. When the key is missing, the checker looks there too and tells you if it finds it. Enter only google._domainkey as the name.
If you manage sending domains for clients or brands, Email Security Signals runs DKIM, SPF and DMARC checks on a whole list and returns one row per domain with the DKIM selectors found, the DMARC policy, SPF lookup count and an A–F grade, ready to export as CSV. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Check a list on the Apify Store →Related: fixing DKIM “no key for signature”, Microsoft 365 DKIM “CnameMissing”, fixing Gmail’s 550 5.7.26 bounce and the free DMARC, SPF and DKIM checker.