Google's troubleshooting page says a "Not authenticating" status on the Authenticate email page means setup isn't finished: the key exists, but nobody has clicked Start authentication. If that click doesn't fix it, the usual culprit is DNS that doesn't hold the exact record Google generated. Look up google._domainkey.yourdomain.com in public DNS, compare it character for character with the value in the Admin console, then click Start authentication and confirm dkim=pass with your domain in a real received message. Generating another key before you've checked DNS usually makes things worse, because the new value replaces the one you published.
Evidence and disclosure: We checked Google's Set up DKIM, Troubleshoot DKIM issues, Turn off DKIM and Set up DMARC pages, plus Gmail's sender guidelines FAQ, on October 16, 2026. UI labels, status messages and error codes below come from those pages. We did not run this in a private Admin console. The DNS output descriptions come from public lookups of existing google._domainkey records, not a test of your domain.
What the status or error is telling you
Find your symptom first. Each points to a different layer.
| What you see | Where | What it means | What to do |
|---|---|---|---|
| An error that the DKIM record wasn't created, after clicking Generate | Authenticate email | Gmail was turned on for the domain less than 24–72 hours ago | Wait out Google's stated window, then generate again |
| DNS Host name and TXT record value are blank | Authenticate email, selected domain | No key exists for that domain | Generate a new record (Step 1) |
| You must update the DNS records for this domain | Authenticate email | Google can show this for up to 48 hours after a correct publish | Verify DNS yourself; if the record is right, wait |
| Not authenticating | Authenticate email | Setup isn't complete | Confirm DNS, then click Start authentication |
| Authenticating email with DKIM | Authenticate email | Signing is on | Verify a received header (Step 5) |
| SMTP error 5.7.30 or 4.7.30 | Gmail rejection or deferral | Gmail says DKIM didn't pass for that message | Check which domain signed it and whether the key resolves |
| SMTP error 4.7.32 | Gmail deferral | From domain not aligned with the SPF or DKIM domain | See the alignment section |
dkim=fail (body hash did not verify) |
Recipient's Authentication-Results header | Message changed after Google signed it | Check outbound gateways, footers and forwarding |
Before you start
- Admin role. Google says generating the key requires a super administrator; the Authenticate email page needs the Gmail Settings administrator privilege.
- DNS access for every sending domain. That's whoever hosts the DNS, which isn't always the registrar. Google doesn't support third-party DNS providers, so use your host's documentation.
- Gmail active on the domain for at least 24–72 hours. For a secondary or user alias domain, Google's domain guide has you click Activate Gmail under Manage domains after verification. Generate the key only after that.
- A lookup tool.
digornslookupin a terminal, Google's Admin Toolbox Dig, or our DKIM checker.
A domain bought from a Google partner during signup may already have DKIM, Google notes. Check what's published first.
Step 1: Generate the key for the right domain
- In the Admin console, go to Menu → Apps → Google Workspace → Gmail.
- Click Authenticate email.
- In Selected domain, choose the domain that appears in your From address. A key for the primary domain won't sign mail from another domain as that domain.
- Click Generate New Record.
- Choose the key length and selector:
- 2048 if your DNS host supports it. Google notes that longer keys are more secure.
- 1024 only if your host can't take a 2048-bit record. Gmail's sender guidelines require at least 1024 bits for mail to personal Gmail accounts.
- Prefix selector: the default is google. Use a different prefix only if another service already publishes a key at
google._domainkeyon that domain.
- Click Generate and copy the DNS Host name (TXT record name) and the TXT record value.
Don't click Start authentication yet. And don't come back later and click Generate New Record "just to be safe": Google updates the TXT record value when you do, so a record you already published stops matching.
Step 2: Publish one TXT record at the selector host
Google's field mapping for your DNS host:
| DNS field | Value |
|---|---|
| Type | TXT |
| Host / Name | google._domainkey (or yourprefix._domainkey if you changed the selector) |
| Value | The full string from the Admin console, formatted v=DKIM1; k=rsa; p=... |
The common failures in this step are mechanical:
- Doubled domain. Some DNS panels append the zone name to whatever you type in Host. Enter
google._domainkey.example.comin such a panel and the record lands atgoogle._domainkey.example.com.example.com. Test it: ifdig +short TXT google._domainkey.example.com.example.comreturns your key, delete that record and recreate it with the short host. - Wrong zone. Run
dig +short NS example.com. The record must live at the provider those nameservers belong to. - Extra quotes or line breaks. Some panels add the surrounding quotes themselves. If you paste quotes too, or the copy picks up a line break, the published value no longer matches. The value should start with
v=DKIM1once you strip the quotes your lookup tool prints. - The 255-character limit. A 2048-bit key won't fit in a single DNS text string. Google's fix: split the key into several strings, put each inside quotes, and enter them one after another in the same record's Value field. You can also pick 1024-bit, or ask your host whether it accepts longer TXT values.
- Two records instead of one split record. Two separate TXT records at the same host isn't the same thing as one record with two strings. DKIM expects one key record per selector, so delete the stray or old one.
- Subdomains. If you send from a subdomain, Google says to check with your DNS host on how to add the record there.
Step 3: Confirm public DNS sees the whole key
Run one of these from a terminal (replace the domain):
dig +short TXT google._domainkey.example.com
nslookup -type=TXT google._domainkey.example.com
To skip resolver caches, ask the domain's own nameserver: dig +short TXT google._domainkey.example.com @ns1.your-dns-host.example.
A 1024-bit record comes back as one quoted string. A 2048-bit record usually comes back as one answer containing two quoted strings, which is normal: receivers join them. Google's troubleshooting page runs the same check in Admin Toolbox Dig: if every key character is there and in order, a two-part key is fine.
Our free DKIM checker does the same lookup and parses the key. Enter your domain under Signing domain (d=) and google (or your prefix) under DKIM selector (s=):
| Checker result | Likely Google Workspace cause | Fix |
|---|---|---|
| No TXT record at this selector | Wrong host, wrong zone, typo in selector, or not yet propagated | Recheck Step 2; query the authoritative nameserver |
| Multiple TXT records at this selector | Split key entered as two records, or an old key left behind | Keep one record with the current value |
| Record or key needs repair | Truncated key, stray quote, missing p= |
Re-copy the value from the Admin console |
| Public key found — review warnings | Often a 1024-bit key | Fine for now; plan a 2048-bit key if your host allows it |
| Public-key checks passed | DNS is right | Go to Step 4 |
A DNS lookup only proves the public key is published. It doesn't prove Google is signing with it. Google says DKIM can take up to 48 hours to start working after you add the key.
Step 4: Click Start authentication
- Go back to Apps → Google Workspace → Gmail → Authenticate email.
- Pick the same domain in Selected domain.
- Click Start authentication.
When it works, the status changes to Authenticating email with DKIM. If it stays on Not authenticating, our inference (Google doesn't spell this out) is that Google can't yet see a record matching the current key. Repeat Step 3 and give DNS time rather than generating a new key.
Step 5: Verify signing in a received message
Google says you can't verify DKIM by emailing yourself. Send a message from the Workspace mailbox to a different Gmail or Workspace account, then:
- Quick check: under the sender's name, click the Down arrow. Gmail shows a Signed by line with the signing domain. It should be your domain.
- Full check: next to Reply, click More → Show original. In
Authentication-Results, look fordkim=passwithheader.d=yourdomain.com. In theDKIM-Signatureheader,d=is the signing domain ands=is the selector, so you should seed=yourdomain.comands=google. Google's Messageheader tool parses a pasted header for you, and our email header guide explains the other fields.
If d= shows a domain that isn't yours, custom DKIM isn't signing mail for that From domain. Answers in Google's admin community describe Workspace's fallback signature as a Google-owned gappssmtp.com domain. It can pass DKIM without aligning with your From address.
If the mailbox sends through a sequencer, test that path too. Instantly's DNS guide and Smartlead's both point Google mailbox users to Google's DKIM setup, and connecting a mailbox through the Instantly Google OAuth setup or Smartlead Google OAuth setup doesn't configure DKIM. Send a campaign test to a Gmail address you control and read that header.
DKIM passes but DMARC fails: check alignment
DMARC needs the passing domain to line up with the From address. Google's DMARC page defines DKIM alignment as the From domain matching the d= domain exactly (strict) or matching it or being its subdomain (relaxed, the default). Gmail's FAQ says mail to personal Gmail accounts must align with SPF or DKIM; 4.7.32 is the temporary failure when neither does.
This bites multi-domain setups. If users send from a user alias domain address and only the primary domain has a key, the From domain and d= won't match. Google says to set DKIM up for each domain, with a unique key for each.
Google also recommends letting SPF and DKIM authenticate for 48 hours before adding DMARC. Check the published policy with our DMARC checker, and SPF with the SPF record checker. If SPF fails with a lookup-limit error, our guide to SPF too many DNS lookups covers the fix. If you run many domains, our comparison of DMARC monitoring tools for multiple sending domains covers the reporting side.
Several sending domains in one Workspace
Outbound teams often add extra domains to one Workspace to spread sending, and every domain repeats the whole sequence. Jan made the same point in a May 2023 cold email walkthrough: every inbox and domain should have SPF, DKIM and DMARC, with separate outreach domains protecting the main one. That's dated advice, not a current benchmark, and his "secondary domain" means a separate outreach domain rather than Google's domain type.
A per-domain tracker keeps the timing honest:
| Domain | Type | Gmail activated | Key generated (bits, selector) | DNS host | DNS verified | Start authentication | Header d= checked |
|---|---|---|---|---|---|---|---|
| example.com | Primary | ||||||
| example-mail.com | Secondary | ||||||
| example.co | User alias |
Each empty cell is a place where the setup can stall without anyone noticing: a key requested inside the 24–72 hour window, a record published at the wrong DNS host, or a domain where nobody clicked Start authentication. Fill the last column only from a real received header.
When the record is right but DKIM still fails
- Outbound gateways or footers. Google warns that a gateway that edits outgoing mail, for example by adding a footer, breaks the signature. The header shows
body hash did not verify. - Forwarding. Forwarded messages can fail DKIM even with a correct setup. Test with a direct message before chasing DNS.
- Too many signatures. Gmail checks only the first five DKIM signatures in the header. Stacked signing services can push yours out.
- DKIM passes but mail goes to spam. That's reputation or sending practice, not DNS. Start with Gmail's sender guidelines and our deliverability readiness test.
- Don't delete a fresh record in a panic. Google says to wait at least four days before removing a new DKIM TXT record, and to leave it in place even if you turn DKIM off.
Disclosure: OutboundXYZ has affiliate relationships with Instantly and Smartlead. That didn't decide anything here: every step is Google's documented process, and for Google mailboxes either sequencer relies on the same Workspace DKIM setup. For the broader tool decision, see our Instantly review and Smartlead review.
Frequently asked questions
How long does Google Workspace DKIM take to start authenticating?
Google says up to 48 hours after you add the key, and the "You must update the DNS records" message can linger that long even when the record is correct. On a newly activated domain, you can't generate the key at all until 24–72 hours after Gmail is turned on.
What is the DKIM selector for Google Workspace?
The default prefix selector is google, so the record lives at google._domainkey.yourdomain.com. If you chose a custom prefix, use that instead. To confirm what's actually in use, find s= in the DKIM-Signature header of a sent message.
Why does my DKIM checker say the selector isn't found?
The lookup found no TXT record at that exact host. Check for a doubled domain in the Host field, a record created at the registrar while DNS is hosted elsewhere, a typo in the selector, or a record that hasn't propagated. A missing result for google says nothing about other selectors on the domain.
Do I need a separate DKIM key for alias and secondary domains?
Yes. Google says to complete the setup for each domain with a unique key from the Admin console. Without one, mail from that domain usually can't pass DKIM aligned with its From address.
