Upgrading Google Workspace DKIM to 2048-bit, without believing the zero-downtime myth

Search "upgrade Google Workspace DKIM to 2048" and you'll find a dozen guides that all tell you the same comforting story: generate a new key under a fresh selector like google2048, publish it, wait for it to go live alongside the old one, then calmly switch over with zero downtime. Generate, publish, wait, switch. Lovely.

It's also wrong. That workflow is lifted, almost word for word, from Microsoft 365 guides, where it genuinely works. Google Workspace doesn't behave that way, and copying the M365 dance onto a Workspace domain is how you end up confused about why your "second selector" never came alive.

The thing every guide gets wrong

Google Workspace lets you have exactly one DKIM key per domain at a time in the Admin console. Not two. Not a clean overlap of old and new while DNS catches up. One.

So the trick that makes M365 seamless, two selectors signing in parallel while you migrate, simply isn't available to you. The moment you generate a new key in the Authenticate email screen, Workspace stops authenticating with the old one. It doesn't keep signing on the old key as a courtesy while you sort out DNS. It just stops, and waits for you to publish the new record and click the button.

On Google Workspace there is no overlap. Generating a new DKIM key drops authentication until you publish the new DNS record and restart signing. The "two selectors live at once" trick is M365 behaviour. It does not exist here.

Which means there is an unavoidable signing gap. Anyone who tells you otherwise is selling you a Microsoft article with the logos swapped. The job, then, isn't to avoid the gap. It's to make the gap so short and so well-padded that nobody, human or mailbox provider, ever notices it happened.

Why bother upgrading at all?

Fair question, because 1024-bit DKIM still technically works and your mail still flows. Two reasons it's worth the small faff:

A 1024-bit RSA key is below the line the industry now draws. The M3AAWG best practice is 2048-bit RSA, and deliverability tooling increasingly flags 1024 as weak. It's not on fire, but it's the email equivalent of still running an unsupported OS: fine until it isn't.

And while you're in there, you should be rotating anyway. M3AAWG's other recommendation, the one nobody follows, is to rotate DKIM keys at least every six months, regardless of key length. A key that has signed your mail untouched since 2019 is a key that has had years to leak, be cracked, or be quietly copied off a backup. Rotation is hygiene, not paranoia. The 2048 upgrade is just a good excuse to finally do the rotation you were supposed to be doing twice a year.

Doing it without anyone noticing

The gap is real but it's measured in minutes if you prepare. Here's the order of operations that keeps it boring.

First, lower the TTL a day ahead. This is the step the copy-paste guides skip, and it's the one that actually matters. Find your existing google._domainkey TXT record at your DNS host and drop its TTL to 300 seconds the day before you swap. When the gap opens, you want the new record propagating in five minutes, not stuck behind yesterday's hour-long cache. Telling people to "set TTL to 1 hour" during an active outage, as one popular guide does, is exactly backwards.

Second, confirm SPF is your safety net. During the brief window where DKIM isn't signing, SPF is the only authentication mechanism still passing for DMARC. So before you touch anything, check that your SPF record is valid, aligned, and covers Google's sending infrastructure. If SPF holds, a DMARC pass still happens on alignment alone and the gap is invisible to receivers. If SPF is also broken, you've turned a 5-minute DKIM blip into a deliverability incident. Don't skip this.

Third, do it out of hours. Lowest-volume slot you have. There's no prize for upgrading DKIM at 11am on month-end.

Now the actual swap, which is quick:

1. Go to the Admin console at admin.google.com/ac/apps/gmail/authenticateemail and select your domain.
2. Generate a new record. Choose 2048 for the key length. The selector prefix doesn't need to be clever, google is fine; changing it to google2048 buys you nothing here, because you still can't run two keys at once. Copy the TXT value Google hands you.
3. Immediately replace the existing DKIM TXT record at your DNS host with the new value. Speed matters now, not cleverness.
4. Wait for propagation, which with the lowered TTL is minutes. Back in the console, click Start authentication and watch the status flip to Authenticating.
5. Verify. Send a test message and check it shows dkim=pass with a 2048-bit key, or just drop the domain into the DKIM checker and the Google Workspace checker and read it back to yourself.
6. Restore the TTL on the record to something sensible once you're confident it's stable.

That's the whole thing: a DNS swap and a button click.

A note on the key being long

A 2048-bit DKIM value is over 255 characters, and some older DNS interfaces choke on that, demanding you split it into quoted chunks. Most modern hosts (Cloudflare, Route 53, Google's own DNS) handle the long string for you and you'll never notice. If yours doesn't, paste the value into the TXT record splitter and it'll chop the string into the 255-character quoted chunks your DNS host wants. If you'd rather not hand-build the record at all, the DKIM record generator will format it for you.

Our take

The Google Workspace DKIM upgrade is genuinely easy. It only goes wrong when you treat the short signing gap as a disaster to dodge instead of a few minutes to prepare for. Accept that there's a gap, lower your TTL, make sure SPF is solid, and it stops mattering. Then put a reminder in the calendar for six months out, because the upgrade isn't the last time you should be doing this, it's the first.

Once your authentication is clean, the natural next step is enforcement: see DMARC from p=none to p=reject. And if you're running Microsoft 365 anywhere in the estate, the M365 version of this job is a very different, much smoother story.

What to do

1. The day before: lower your google._domainkey TXT record's TTL to 300s, and confirm your SPF record is valid and aligned as a fallback.
2. In the Authenticate email console, generate a new 2048-bit record and copy the TXT value.
3. Replace the old DKIM TXT record at your DNS host immediately, wait for propagation, then click Start authentication.
4. Confirm dkim=pass at 2048-bit with the DKIM checker, restore the TTL, and diarise the next rotation for six months out.