Does Google Workspace rotate DKIM keys for me?

No. The Admin console gives you a button to generate a new record and a control to start authentication, so the rotation is a decision you make and a sequence you run. Google's published requirement for mail to personal Gmail accounts is a key of 1024 bits or longer, with 2048 recommended, not a rotation interval.

How long should I leave the old DKIM record in DNS?

Long enough that no message signed with the old key is still waiting to be verified. RFC 6376 expects both public keys to be published during the transition. We leave two weeks on client domains, counted from the moment signing moves to the new selector, and read a full cycle of DMARC aggregate reports before deleting anything.

Will rotating the key break DMARC?

Not if you publish the new record under a new selector, wait for it to resolve, verify a real message passes DKIM with it, and leave the old record in place for a couple of weeks. The failure mode is deleting the old record early, which matters most on a domain at p=reject.

DKIM key rotation in Google Workspace: the safe sequence

Say a 30-person logistics company moved to Google Workspace in 2019 and has signed every message it has sent since with the same DKIM key. Nobody remembers generating it. The selector is still the default one, the key is 1024 bits, and it works, which is exactly why no one has looked at it. Then a customer's security review asks when the signing key was last changed, and the honest answer is never.

Rotating that key takes about ten minutes in the Admin console and about two weeks in DNS. The gap between those two numbers is where mail gets lost. The usual failure looks like this: an admin generates a new record, publishes it, turns authentication on, and deletes the old TXT record the same afternoon. Every message that was already sitting in a receiving queue, waiting at a forwarder, or stored somewhere that will verify it later now fails DKIM, because the key it was signed with is gone. On a domain at p=reject, failing DKIM with nothing else aligned means rejected mail. The order matters. Everything below comes from Google's own documentation and the DKIM RFCs, checked 6 October 2026.

Why a Workspace domain would rotate at all

Three reasons come up in real accounts, and only the first is urgent.

The key is from the 1024-bit era. RFC 8301 says signers must use RSA keys of at least 1024 bits and should use at least 2048. Google's sender guidelines say mail to personal Gmail accounts needs a key of 1024 bits or longer, and recommend 2048 where your domain provider supports it. A key generated years ago on a DNS panel that could not hold a long value is usually 1024, and upgrading it is a rotation whether you call it one or not.

Nobody knows where the key came from. You inherited the domain, or a gateway vendor generated a key for it once, or there are two records at _domainkey and only one of them signs anything. Rotating to a key you generated yourself, under a selector you chose, replaces a question with a fact.

Somebody asked. Security questionnaires and internal policies often want periodic rotation. RFC 6376 built selectors for this: a signing domain can advertise more than one public key at a time, so keys can be replaced on a routine basis without a gap.

One honest limit. On Google Workspace the private key is generated and held by Google, and you never touch it, so rotation here is hygiene and key length rather than something you would do in response to a leak. If you have a key you generated outside Google, on a mail gateway or a server, and you think the private half was exposed, that is a different and more urgent job. Google's published requirement is a minimum key length, not a rotation interval, so nothing expires if you leave the key alone.

What we check before touching the record

Knowing what signs your mail today is the part that saves you. Four checks, in this order.

Which selector is live, and how long the key is. Read the signature on a message the domain actually sent, then look up the record it points at. The s= tag in the DKIM-Signature header is the selector, and the published value is a TXT record under that selector:

dig +short TXT google._domainkey.example.com

A short p= value is a 1024-bit key. A long one, usually published as several quoted strings, is 2048. Google's own troubleshooting page covers the 255-character limit that makes the long value awkward on some providers, and our guide to DKIM failures on Google Workspace walks through the record that will not fit and the selector that is not there.

Whether Google is the signer that matters. Google signs mail that leaves Google. Your invoicing platform, CRM and e-commerce checkout sign with keys of their own, and rotating the Workspace key changes nothing for them. If the problem you are trying to solve is a vendor failing DMARC, this is the wrong job.

Your DMARC policy. At p=none a mistake during rotation produces a bad line in a report. At p=reject it produces rejected invoices. Same procedure either way, but the overlap window stops being optional.

What else handles the mail on the way out. A security gateway or an appliance in front of Gmail can modify a message after Google signs it, which breaks the signature no matter which key is current. Rotating into an existing breakage makes the breakage look new.

The rotation, in the order that keeps mail signed

Generate the new record under a different selector. In the Admin console, on the Authenticate email page, pick the domain and generate a new record. Google's setup page is explicit that if your domain already uses a DKIM key with the prefix google, you enter a different prefix in the generate form. Pick something you will recognise later, like the year and the month. Choose 2048 bits unless your DNS provider cannot hold the value.
Publish the new TXT record and leave the old one alone. The new key goes under its own host name, so the two records coexist without touching each other:
```
gt2610._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."   (leave this)
```
If your provider rejects the long value, split it into quoted strings one after another in the same record, which is what Google's troubleshooting page tells you to do.
Wait before you turn anything on. Google documents that after you add a DKIM key it can take up to 48 hours for DKIM authentication to start working, and that the Authenticate email page may keep telling you to update your DNS records for up to 48 hours even when the record is correct. A failed lookup in the first minutes usually means a negative answer is still cached, not that you made a mistake.
Start authentication. Back on the Authenticate email page, start authentication so Google signs with the new selector.
Prove it with a real message. Send one to a mailbox you control, open the full headers, and check two things: the s= tag names your new selector, and the authentication results show DKIM passing with your domain. The console confirming the record exists is one thing. A header is proof that mail is being signed with it.
Do not delete the old record. Not today, and not this week.

How long to keep the old key published

RFC 6376 answers this directly: during a transition, both public keys are advertised at the same time, for as long as mail signed with the older one may still be in transit before it is verified. That is longer than most people assume.

Deferred mail. A receiver that temporarily rejected your message will retry it for hours or days, and it verifies when it finally accepts.
Forwarders and lists. A message that hops through a forwarding address or a mailing list gets verified again at each stop, at whatever time that stop happens.
Anything that verifies on access. Archives, journaling systems and security tools often re-check a signature when a message is opened or reported, which can be weeks after delivery.

Our practice on client domains is two weeks, and the clock starts when signing moves to the new selector, not when the record is published. Before deleting, we read one full reporting cycle of DMARC aggregate reports and want to see the new signing path passing across every source that matters. Many reporters name the selector in the DKIM result, which makes the switch easy to watch. Reading those files is its own job: how to read a DMARC aggregate report.

Two rules from RFC 6376 worth keeping. Do not reuse a selector for a new key: if you overwrite the old record with the new value, a message that fails because the key is gone becomes indistinguishable from a forgery, and that is why new keys get new selectors. And when the window closes, deleting the record is enough. The RFC notes there is no defined semantic difference between a revoked key and a removed one, so you do not need to publish an empty key first.

The senders that rotate without you, and the ones that never will

Where a vendor had you publish CNAME records instead of TXT records, the vendor owns the key behind them and can rotate it without asking you. Microsoft 365 is the clearest example of the model: it has you publish two selector CNAMEs, keeps one active at a time, uses the second one for the next rotation, and Microsoft's documentation notes that a rotation is not immediate, with roughly four days before the new private key starts signing.

Where a vendor gave you a TXT value to paste, nothing rotates until a person does it, and that person is usually nobody. When we inventory senders on a domain we list those separately, because each one is a manual rotation on somebody else's schedule and each one deserves its own week. One authentication change at a time is slower and it is the reason the rollbacks stay small.

What we watch afterwards

For the two weeks between the switch and the deletion we want three things true: the Admin console reports authentication on for the domain, a test message from each real sending path passes DKIM with the new selector, and aggregate reports show no source still relying on the old key. If a report shows a source failing after the switch, the old record is still there, which is the entire point of leaving it.

Keep the policy work separate. If your DMARC policy is due to move up, that is its own project with its own rollback, described in moving DMARC from p=none to p=reject. Rotating a key in the same week as a policy change means that when something breaks you will not know which change did it.

Then write down the selector you chose and the date you switched, somewhere the next admin will look. The six-year-old key in the opening paragraph exists because nobody wrote anything down, and that is the part of this job that actually repeats.

How Guanacos Tech helps

We do key rotations as part of authentication work for small and mid-sized companies across North America and Latin America, in English and Spanish, through our email deliverability consulting for small business engagements. Most of the value is the inventory of what signs your mail, the overlap window held open long enough, and somebody watching the reports while the old key is still live. A 30-minute call is enough for us to read your current record, your DMARC reports and one set of raw headers, and tell you whether a rotation is worth doing now or something else is the real problem.

Rotating a Google Workspace DKIM key without losing a signed message