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. What you can see is the console's side. Google's troubleshooting page says a domain shows "Not authenticating" after you create a DKIM record and add it to your domain, until you click Start authentication3. What Gmail does with outbound signing in between, Google does not document, and we have not measured it.

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.

If you keep the google selector and overwrite the record, which is what most people do, plan for a short gap. It worked for one of our clients, and their rollout is below. If you want to be more exact, publish the new key under a selector that isn't the same as the previous one and leave the old record up until the switch is done. That is the rotation RFC 6376 §3.1 describes1. We have done that with several clients, both when a domain's DKIM record had been removed from DNS and it needed a new key, and when we added a new key while the old record was still live and its TTL had not expired. Once we switched over, outgoing mail was signed with the new selector7. Either way, the job is to make any gap short and well padded, so nobody, human or mailbox provider, 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 20484. 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 length5. (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

On the overwrite route the gap is real, and with preparation it is short. Google's own figure is that "it can take up to 48 hours for DKIM authentication to start working" after you add a key2; for our client it took about fifteen minutes. Here's the order of operations that keeps it boring.

First, lower the TTL a day or more 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 well before you swap. A lower TTL only helps once the old one has expired in every cache, so give it at least the old TTL's worth of lead time. 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 short 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. Open Authenticate email in the Admin console and select your domain.
2. Generate a new record. Choose 2048 for the key length. Leave the prefix as google if you are overwriting. For the more exact route, enter a different prefix, such as a dated g2026a; Google's page says "If your domain already uses a DKIM key with the prefix google, enter a different prefix in this field"2. Copy the TXT value Google hands you.
3. Publish it at your DNS host. On the overwrite route, replace the existing google._domainkey record with the new value. On the new-prefix route, add the new record and leave the old one where it is.
4. Wait for propagation, which with the lowered TTL is minutes. Google's own instruction at this point is "Do not click Start Authentication yet" until the record is in place2. Then, 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.

What it looked like at an 800-mailbox client

We took over a Google Workspace client of about 800 mailboxes whose domain was still signing with a 1024-bit key, and suggested moving to 2048. We kept the google selector and overwrote the record.

On the Wednesday before, we lowered the DKIM record's TTL from eight hours to five minutes. The change itself went in last thing on a Friday, after work hours, and everyone was asked to stop sending mail from 17:00 to 18:00 as a precaution. SPF was fully compliant for Google, so the gap did not worry us much.

Then the sequence above: generate the new key in the Admin console, put the new record in DNS, start authentication. The whole thing took about fifteen minutes, and the domain was authenticating again afterwards. The DKIM checker showed the key at 2048 bits, and the weak-key warning on the record was gone. Once we saw it authenticating, we moved the TTL back to eight hours. There wasn't a DKIM failure that evening6.

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 signing gap as a disaster to dodge instead of something to prepare for. If you overwrite, accept a short gap, lower your TTL, make sure SPF is solid, and it stops mattering. If you want no gap at all, use a new selector. 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. A day or more 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. Publish the new record (replace google._domainkey, or add it under a new prefix if you want to be exact), 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.

Sources checked

Each sourced claim above was checked against the page named here on 4 October 2026. Google moves its help pages, so follow the link rather than trusting the date.

1. Selectors "make it possible to seamlessly replace public keys on a routine basis": both public keys are "advertised in the public-key repository concurrently for the transition period", and the old one is removed at the end of it. Source: RFC 6376 §3.1 ↩
2. The prefix field ("The default prefix selector is google"; "If your domain already uses a DKIM key with the prefix google, enter a different prefix in this field"), "Important: Do not click Start Authentication yet", and "After adding a DKIM key, it can take up to 48 hours for DKIM authentication to start working." Read 4 October 2026. Source: Set up DKIM (Google Workspace Admin Help) ↩
3. "If you get a “Not authenticating” error after you create a DKIM record and add it to your domain, you need to complete your setup", with the fix "click Start authentication". Read 4 October 2026. Source: Troubleshoot DKIM issues (Google Workspace Admin Help) ↩
4. "Signers MUST use RSA keys of at least 1024 bits for all keys." and "Signers SHOULD use RSA keys of at least 2048 bits." Source: RFC 8301 §3.2 ↩
5. "DKIM keys should be rotated at least every six months." The same March 2019 document calls 1024-bit keys "the current recommended length", so it is the source for the interval only. Source: M3AAWG DKIM Key Rotation Best Common Practices ↩
6. From the author's own client work: an 800-mailbox Google Workspace domain moved from 1024-bit to 2048-bit DKIM on the google selector, checked afterwards with the DKIM checker. No outside source. ↩
7. From the author's own client work: the new-selector route used at several Google Workspace clients, including domains whose DKIM record had been removed from DNS and domains where the old record was still live; outgoing mail was signed with the new selector after the switch. No outside source. ↩