Why Your google._domainkey Isn't Signing: A Workspace DKIM Deep Dive

You hit the 'Start authentication' button in the Google Workspace Admin console. You’ve generated the new record, dutifully copied the TXT value into your DNS provider, and waited. And waited. Hours later, the status still stubbornly reads 'Not authenticating'. Your DMARC reports are a sea of red failures from Google's own IP ranges, and you’re starting to question your sanity.

This is a common scene. The problem is rarely on Google's side. Their mail transfer agents (MTAs) are humming along, ready to sign your outbound mail with a cryptographic signature. But they won't, and they can't, until they can successfully retrieve the public key you've published.

The breakdown isn't in the signing process itself, but in the chain of trust established via DNS. When you see 'google workspace dkim not working,' it's an investigation that starts not in the Admin console, but with a simple DNS query. Let's walk through the points of failure.

The Workspace DKIM Handshake: From UI to MTA

Before we debug, let's trace the intended flow. DomainKeys Identified Mail (DKIM), defined in RFC 6376, is designed to prove that an email was sent by a specific domain and that its content hasn't been tampered with in transit. It's a digital signature, plain and simple.

When you click 'Generate New Record' in Google Workspace, two things happen. First, Google generates a private/public key pair. The private key is stored securely on their signing infrastructure. The public key (`p=`) is presented to you. Second, Google tells you the 'selector' to use. In this case, it's `s=google`. A selector is just a label, allowing a domain to have multiple DKIM keys for different services or purposes.

Your job is to publish that public key in a TXT record at a specific DNS location: `google._domainkey.yourdomain.com`. When one of Google's MTAs sends an email from your domain, it creates a signature using the private key and includes it in the `DKIM-Signature` header. The receiving mail server sees the signature, notes the domain (`d=yourdomain.com`) and selector (`s=google`), and performs a DNS lookup for `google._domainkey.yourdomain.com` to retrieve your public key. If the public key can decrypt the signature, the mail passes DKIM verification. If not, it fails. The system is elegant, but its reliance on DNS creates several points of failure.

Pitfall #1: DNS Is Slower Than You Think

The most common culprit is time. After you publish the TXT record, Google's systems need to see it. This isn't instantaneous. Their validators will query the public DNS system, but the result they get is subject to caching.

The TTL Waiting Game

Every DNS record has a Time To Live (TTL) value, measured in seconds. This tells DNS resolvers how long they should cache the record before asking for it again. If you're updating an existing `google._domainkey` record that had a high TTL (like 86400 seconds, or 24 hours), it could take a full day for Google's systems to see your change. Even with a fresh record, propagation across the globe isn't instant.

Before you even start troubleshooting, give it some time. An hour is reasonable. If your TTL is set to something low like 300 (5 minutes), great. If it's over 3600 (1 hour), you're in for a wait. Patience is the first debugging tool.

Playing Detective with `dig`

Don't trust the Admin console's status. Verify for yourself. Using `dig` (or an online equivalent) is the ground truth. The key is to check from multiple perspectives. First, check your own authoritative nameserver. Then, check a major public resolver like Google's (`8.8.8.8`) or Cloudflare's (`1.1.1.1`).

dig TXT google._domainkey.yourdomain.com @1.1.1.1

If the query to `1.1.1.1` returns your key but the Workspace admin panel is still red, it's likely a matter of internal propagation on Google's side. But if that command returns `NXDOMAIN` (non-existent domain) or an old record, the problem lies with your DNS configuration or its propagation, not Google.

Pitfall #2: TXT Records Are Brittle Creatures

So, `dig` shows the record isn't resolving correctly. The next area to inspect is the format of the TXT record itself. DNS is notoriously picky, and the long, complex string of a DKIM key is a minefield for syntax errors.

Quotes, Spaces, and Concatenation

This is the big one. A single DNS TXT record string has a maximum length of 255 characters. Google's 2048-bit DKIM keys are much longer than this. The correct way to handle this, per the RFCs, is to split the key into multiple double-quoted strings, all within the same TXT record line.

It should look like this: `"v=DKIM1; k=rsa; p=stringpart1" "stringpart2" "stringpart3"`. The receiving server automatically concatenates these parts. The problem is that every DNS provider's UI handles this differently. Some providers have a single text field where you paste the whole key, and they correctly split it behind the scenes. Others require you to manually enter the key in separate fields or with explicit quotes. Pasting a key that already contains quotes into a UI that adds its own will lead to escaped, broken records. Conversely, pasting a key without quotes into a UI that expects them will also fail.

The rule: Check what your DNS provider's documentation says about long TXT records. When in doubt, use a third-party DKIM checker tool to attempt a lookup. It will often show you the raw, malformed record it received, pointing you directly at the syntax error.

Copy-Paste Contamination

Never underestimate the damage a rich-text editor can do. Copying the key from the Google Admin console and pasting it into a document, a chat window, or a ticketing system before pasting it into your DNS can introduce invisible characters, smart quotes, or unwanted line breaks. This will invalidate the key. Always copy directly from the source to the destination. If you must use an intermediary, paste it into a plain text-only editor (like Notepad or a proper code editor) to strip any formatting.

Proof Is in the Headers, Not the Admin UI

Once you've confirmed with `dig` that your TXT record is published and correctly formatted, the Google Admin UI should eventually turn green. But the real final check is to inspect the headers of an email sent through your Workspace account.

Send an email from your Workspace account to an external address you control (like a personal Gmail or Outlook account). Once it arrives, view the original message source. You are looking for the `Authentication-Results` header, which is added by the receiving mail server. This is the official verdict.

Authentication-Results: mx.google.com;
dkim=pass header.i=@yourdomain.com header.s=google header.b=AbcDefG;
spf=pass (google.com: domain of sender@yourdomain.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=sender@yourdomain.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com — Authentication-Results header from a receiving server

Look for `dkim=pass`. This is non-negotiable proof. You should also see `header.s=google`, confirming it used the correct selector. If you see `dkim=fail` with a reason like 'body hash did not verify', that points to a different problem, often related to email forwarders or MTAs modifying the message body after it was signed. But if you see `dkim=neutral` or `dkim=none`, it means the receiver couldn't find or use a signature, bringing you right back to your DNS or Google's signing status.

This header is also critical for DMARC (RFC 7489). For DMARC to pass using DKIM, the domain in the `d=` tag of the DKIM signature must *align* with the domain in the `From:` header. With Google's setup, this alignment is guaranteed, which is why getting DKIM working is a foundational step for enforcing a `p=reject` DMARC policy.

The takeaway

The 'Not authenticating' status in the Workspace console is just a symptom. It tells you there's a problem, but not where. The root cause is almost always a breakdown in the trust chain between your DNS and Google's MTAs. Stop refreshing the admin panel and start investigating the path. Verify your public record exists and is syntactically correct first. Then, and only then, check the headers of a live email for the final verdict.

The truth is always in the headers. They provide an undeniable log of what each server saw and how it judged your message's authenticity. For a continuous, automated view of these headers and DMARC results across your entire mail flow, platforms like MailSleuth.AI can provide the necessary context without requiring you to run manual commands for every incident.