Beyond google._domainkey: Adding a Second DKIM Key in Workspace

Pop open the headers of any email sent from a Google Workspace account, and you'll find it. Tucked inside the Authentication-Results header is the familiar selector `s=google`, a reference to the default `google._domainkey` TXT record published in your DNS. It works. It passes DMARC. For most organizations, this is where the story ends.

But what if it shouldn't be? Relying on a single, static signing key is like using the same password for a decade. It's functional, but it's not resilient. What's your process for key rotation if that private key is ever compromised? How do you segment signing authority for different business units or high-volume automated systems?

Adding a second, or even third, DKIM key isn't a feature reserved for massive enterprises. It's a straightforward, high-impact tactic available to any Google Workspace administrator. It’s the difference between a set-and-forget configuration and a managed, defensible email security posture. Let's walk through how to do it right.

Why Bother with a Second DKIM Selector?

The existence of that default `google._domainkey` makes it easy to get complacent. It's generated, you publish it, and email flows. The primary drivers for adding another key are about control, security hygiene, and minimizing the blast radius when things go wrong.

Phased Key Rotation Without Downtime

Security best practices and some compliance frameworks mandate periodic key rotation. But you can't just generate a new key and replace the TXT record at `google._domainkey`. DNS is a distributed system; propagation isn't instant. For a period of minutes or hours, receiving mail servers with a cached copy of your old public key will fetch a signature made with a new private key. The result? A hard `dkim=fail`.

The correct procedure is a phased rotation. You introduce a new key with a new selector — say, `google-q3-2024._domainkey`. For a time, both the old and new keys are active. Once you've verified the new key is being used in the wild and has fully propagated, you can decommission the old one. This make-before-break approach ensures uninterrupted signature validation.

Departmental or Service-Specific Signing

Imagine your marketing team starts using a new automation platform that routes mail through your Workspace account. Or maybe an internal application sends critical alerts via a service account. Lumping all this mail under a single `google._domainkey` signature merges their reputation with your primary corporate mail flow.

By generating a dedicated key—for instance, one with the selector `mktg`—you create cryptographic separation. If that marketing platform is ever misconfigured and sends spam, the resulting reputational damage is tied to the `mktg` selector, not your primary `google` selector. An analyst investigating a blocklisting can immediately trace the issue to a specific mail stream instead of having to guess which of your dozen systems is the culprit. This is about segmentation and precise attribution.

Forging the New Key in the Admin Console

Generating the key itself is the easy part. In the Google Admin Console, navigate to Apps > Google Workspace > Gmail. From there, click on 'Authenticate email'. You'll see your existing `google._domainkey` entry, likely with a status of 'Authenticating email'.

Click the 'GENERATE NEW RECORD' button. This brings up a dialog that’s more important than it looks. You have two decisions to make: the key bit length and the selector prefix. Both have consequences.

Choosing Key Length and Selector Prefix

For key length, always choose 2048 bits. While RFC 6376 technically allows for shorter keys, 1024-bit keys are considered weak against modern computational power. Many secure email gateways and major inbox providers are beginning to treat 1024-bit signatures with suspicion, and some may even fail them outright. Choosing 2048 bits is non-negotiable for new deployments.

The selector prefix is your namespace. You cannot reuse `google`. This is your chance to create a meaningful identifier. Avoid generic names like `key2`. A good convention is time-based for rotation, like `google-2024-q3`, or function-based, like `marketing` or `alerts-prod`. A readable selector makes debugging mail headers dramatically faster for your security team.

DNS Host name (TXT record name): google-2024-q3._domainkey
TXT record value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...your...long...public...key...data...AQAB

After generation, Google will show you the new record with a status of 'Not authenticating email'. This is correct. Do not click 'Start Authenticating' yet. First, we have to publish this key to the world via DNS.

Publishing the Key and Practicing DNS Patience

Your task is to create a new TXT record on your domain's authoritative DNS servers. The hostname for the record is the one Google provided: `[your-new-selector]._domainkey`. The value is the entire `v=DKIM1;...` string.

Common DNS Pitfalls

This is where most implementations fail. Be meticulous. Many DNS providers automatically append your root domain (`yourdomain.com`), so you should only need to enter `google-2024-q3._domainkey` in the host field. Entering the full `google-2024-q3._domainkey.yourdomain.com` might result in an incorrect record like `google-2024-q3._domainkey.yourdomain.com.yourdomain.com`.

The other classic failure mode involves the TXT record value. Some DNS interfaces have trouble with the length of a 2048-bit key and require you to split the string into multiple quoted segments. This is fine and compliant with RFC 7208's guidance on TXT records; receivers will concatenate them automatically. However, some panels might incorrectly handle the semicolons or add extra quotes. Your best bet is to publish the record and then immediately use an external tool to verify it.

Use a public DNS resolver for verification, not your local machine which might have a cached (and wrong) result. A simple `dig TXT google-2024-q3._domainkey.yourdomain.com @1.1.1.1` will show you exactly what the world sees. If the value matches what Google provided, you're good. If not, troubleshoot your DNS provider's input formatting. Keep the TTL low (like 300 seconds) during this phase. Once verified, you can go back into the Google Admin Console and click 'Start Authenticating'.

The Selector Lottery and Live Confirmation

Here’s the most misunderstood part of the process. Once you have two or more keys active for the same domain in Google Workspace, you do not get to choose which key signs a specific email. There is no policy engine, no organizational unit setting, no content rule that says 'use this key for the finance team' and 'use that key for marketing'.

Instead, Google's outbound mail transfer agents (MTAs) will pick from the pool of active keys. Based on observation, this appears to be a probabilistic or round-robin selection. If you send five emails, you might see three signed with `s=google` and two with `s=google-2024-q3`. This is intentional. During a key rotation, this behavior ensures that both the old and new keys get exercised, forcing receiving servers across the internet to cache both public keys.

Reading the Headers for Proof

The only way to confirm your new key is live is to inspect the headers of a delivered email. Send a test message from a Workspace account to an external inbox you control. Once received, view the raw source of the message (`Show original` in Gmail). You're looking for the `Authentication-Results` header, which is added by the first major MTA to receive the message.

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

The prize is `dkim=pass` coupled with `header.s=google-2024-q3`. The `s=` tag identifies the selector used for the signature. If you see this, it's working. You have successfully published your key, enabled it in Workspace, and Google's MTAs are using it to sign mail. If your first test email still shows the old `s=google` selector, don't panic. Just send a few more. The new selector will eventually appear in the lottery.

Completing the Rotation and Cleaning Up

If your goal was a key rotation, the final step is decommissioning the old key. It's critical to do this gracefully. After you've confirmed the new key is signing mail correctly and has been active for at least 48-72 hours to allow for DNS propagation, you can proceed.

Go back to the 'Authenticate email' section in the Admin Console. Locate the record for the old key you're retiring (e.g., the original `google._domainkey`). Instead of deleting it, click 'Stop authenticating'. This tells Google's MTAs to remove that key from the signing pool for all future emails. The key is now inactive for signing but still defined.

Crucially, do not delete the old TXT record from your public DNS yet. Leave it in place for at least another week, maybe two. Emails signed with that old key may still be in transit, sitting in quarantine, or waiting to be processed by a slow mail forwarder. A receiving server or an ARC validation chain (as defined in RFC 8617) may still need to look up that old public key to validate an old signature on a forwarded message. Deleting the DNS record prematurely will cause those checks to fail, potentially leading to deliverability problems for week-old emails. After a safe waiting period, you can finally remove the old TXT record from your DNS zone.

The takeaway

Implementing a multi-key DKIM strategy in Google Workspace moves your email authentication from a static, fragile state to a managed, resilient one. It's a sign of operational maturity that gives you the flexibility to rotate credentials without service interruption and to segment sender reputation, making incident response faster and more precise.

This isn't just a matter of following RFCs—it's about controlling your domain's identity in a threat landscape where email is the primary vector for attack. Digging through raw headers to confirm which selector is in play can be tedious, but understanding what you're looking at is a core skill. Tools like MailSleuth.AI can make parsing these headers and visualizing DMARC alignment across multiple signing keys far more efficient, but they're no substitute for knowing the underlying mechanics.