Why does Google Workspace provide the same DKIM public key for all Workspace customers?

I’m setting up DMARC for several Google Workspace accounts (i.e., different domains using Workspace), so first I have to create SPF and DKIM records for domains missing either or both.

After retrieving the 2nd Workspace account’s DKIM record from within its Workspace admin controls, I noticed its public key is exactly the same as a completely unrelated Google Workspace account’s DKIM public key.

I then used the dig google._domainkey.domain txt command to look at several other Workspace accounts that already have DKIM and confirmed they all have the same public key: "p=MIIB…AQAB”.

Even online posts I found that show screenshots for Google Workspace DKIM setup show that public key.

In the 2nd Google Workspace account’s DKIM section, I clicked "Generate new record,” but it just presented the same one.

Google Workspace recommends using “google” as the selector. Does using a different selector create a different DKIM record (different public key)? I didn’t try it because Google discourages it even though the selector field is editable.

Is Google Workspace’s use of a common DKIM record for its Workspace customers ok?

I feel like I’m missing something obvious and hope to avoid redoing DKIM setup.

If it’s ok, do only mail hosts have unique DKIM records, not each customer at mail hosts?

I used several search engines but didn’t find a single article, post or comment about Google Workspace having a common DKIM record.

If Google Workspace’s common DKIM record is ok, I’ll be able to skip logging into each Workspace admin control to retrieve the DKIM record. I’ll be able to just go straight to each DNS host (registrar or webhost) and create the records, wait 2-3 days then log into Workspace admin to click the DKIM “Authenticate” button.

I have tested several google._domainkey TXT records, and none of them are the same from my end.

The majority (if not all) of them are however starting with “p=MIIB”, but they are definitely NOT 100% identical.


The DKIM public key can be used to verify that an email was signed with the corresponding private key.

As the customers don’t have access to the private key, there is no good reason to use different keys for different customers (opinions are going to differ here I guess).

On the other side, it makes things a lot easier if everyone can use the same public key. You don’t need any special infrastructure to allow a customer to retrieve “their” key, the manual can just say what DNS records to create.

But, as @DarkDeviL pointed out, Google Workspace does not use the same key for all customers. Many other email providers do.

1 Like


I suspected this forum would know the answer.

I obviously didn’t compare enough of the keys. I mistakenly thought like hashes the probability they’d uld start and end the same would be extremely low.

I just loaded two them into a spreadsheet and see that they both start with:

And both end with: IDAQAB

The middles are different as you explained.

I really thank you for straightening me out!

Great forum.

Thanks. Two great answers to my misstated question.
And both within minutes of posting.
Thank you both so much!

1 Like

FYI – nothing useful but…

I pasted four Google Workspace public keys from 2048-bit records into a spreadsheet.

They all start with the same 44 characters (header, I guess):

then characters 45-237 are random

then all have two double-quotes ( “” ) – delimiter, I guess

then 149 more random characters

then end with 6 characters:

A shorter DKIM record (<2048 bits) also ends with IDAQAB but starts differently and I only had one to examine.

FYI – nothing useful update:

The double-quote space double-quote character group isn’t really part of the public key.

They only appear in dig’s answer ( dig google._domainkey.domain txt ) and aren’t in the DKIM record’s public key copied directly from Google Workspace admin DKIM section.

The double-quote space double-quote might signify a split record, perhaps related to some old DNS providers not being able to fit 2048-bit records in one TXT record (they split them into two TXT records).

Looks like either dig inserts them or DNS provider replies with them. The 5 Workspace accounts I checked all have DNS providers (registrars and web hosts) that fit the DKIM 2048-bit record into one TXT record (i.e., don’t have to split them).

If you are interested, you can look that up in RFC 1035

The short version is:
A TXT record consists of one or more <character-string> structures.
A <character-string> consists of up to 255 characters.

As you see, a TXT record that is longer than 255 characters must be split into multiple <character-string> structures. And each of these is surrounded by quotes.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.