Google Workspace DKIM 2048-bit: 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 gives you one DKIM signing configuration per domain in the Admin console. Generating a new key replaces the record the console holds; there is no built-in handover from the old key to the new one while DNS catches up.

So the automatic switch that makes M365 smooth isn't available to you. (Microsoft's two selectors are not both signing either, but its inactive one is pre-published and Microsoft moves signing to it for you.) You can still get the overlap by hand, by publishing the new key under a different selector prefix and leaving the old record up, which is what RFC 6376 §3.1 describes. 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 nothing hands over for you. Generating a new DKIM key drops the domain out of its authenticating state until you publish the record and restart signing. If you overwrite the existing record you get a gap; if you publish the new key under a new selector prefix, the old record stays valid throughout.

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:

RFC 8301 §3.2 says signers MUST use RSA keys of at least 1024 bits, and SHOULD use at least 2048. So a 1024-bit key still conforms. It is the weaker of the two options on offer, and our own DKIM checker flags it on that basis.

And while you're in there, you should be rotating anyway. M3AAWG says to rotate DKIM keys at least every six months, regardless of key length. (That document, last revised in March 2019, still calls 1024 bits "the current recommended length", so it is the source for the interval and not for the key size.) 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. Consider changing the prefix from google to something else, such as a dated g2026a: RFC 6376 §3.1 describes rotation as publishing the new key at a new selector and leaving the old record up through the transition, and Google documents entering a different prefix when one is already in use. 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.