Google Workspace DKIM Setup: The Record, the Wait, the Checks

To set up DKIM in Google Workspace, open the Admin console at Menu > Apps > Google Workspace > Gmail > Authenticate email, generate a 2048-bit key, publish it as a TXT record at google._domainkey.yourdomain.com, then return and click Start authentication. Allow up to 48 hours, and confirm by checking that a sent message's headers show dkim=pass for your own domain.

The steps below follow Google's Set up DKIM help page, read on 6 October 2026, and add the checks that tell you it actually worked. If your domain already has a Google key and you want to replace it, that is rotation, covered in DKIM key length and rotation.

Before you start

You need an administrator sign-in for the Admin console, access to your domain's DNS, and Gmail switched on for at least 24 hours. Google's help page is explicit about the last one: "after you turn on Gmail for your organization, you must wait 24–72 hours before you can get your DKIM key". If you have only just moved a domain onto Workspace and the Authenticate email page will not generate a record, that waiting period is the usual reason.

It is also worth knowing why you are doing this. Google's email sender guidelines require every sender to use SPF or DKIM, and require bulk senders (more than 5,000 messages a day to Gmail) to have SPF, DKIM and DMARC, with "the domain in the sender's From: header ... aligned with either the SPF domain or the DKIM domain". A DKIM signature for your own domain is the alignment that survives forwarding, which SPF does not.

Step 1: generate the key

In the Admin console, go to Menu > Apps > Google Workspace > Gmail > Authenticate email, choose the domain, and click Generate New Record. You will be asked for two things:

• Key length. Google's page says to select 2048 "if your domain provider supports 2048-bit keys", and 1024 otherwise. Gmail's sender guidelines require "a DKIM key of 1024 bits or longer" and recommend 2048.
• Prefix selector. The default is google, and Google recommends keeping it. Use a different prefix only if your domain already has a record at google._domainkey, for example from an earlier setup you want to leave in place during a changeover.

If you run several domains in one Workspace account, repeat this for each. Google's page says: "You must get a unique DKIM key from the Admin Console for each domain."

Step 2: publish the TXT record

The console gives you a host name and a TXT value; copy both exactly into your DNS host as a TXT record.

Field	What Google shows	What to enter
DNS Host name	google._domainkey	google._domainkey (most DNS hosts add your domain automatically)
Record type	TXT	TXT
TXT record value	Starts with v=DKIM1; k=rsa; p=	The whole string, unchanged

Two things go wrong here more than anything else.

The host name gets the domain twice. If your DNS host appends the zone automatically and you type google._domainkey.example.com, the record ends up at google._domainkey.example.com.example.com. Enter only google._domainkey unless your provider asks for the full name.

The 2048-bit key is too long for one string. Google's Troubleshoot DKIM issues page says most TXT records "can have up to 255 characters" and that a 2048-bit key cannot be entered as a single string under that limit. The fix it gives is to split the key into multiple quoted strings in the same TXT record value. Receivers join the strings back together. You can see what this looks like on a real domain: when we ran dig TXT google._domainkey.zapier.com on 6 October 2026, the answer came back as two quoted strings, "v=DKIM1; k=rsa; p=MIIBIjANBg..." followed by "7ixR8ZRj...", which is a 2048-bit key published in two parts.

If your DNS host rejects long TXT values and does not accept split strings, Google's troubleshooting page suggests using a 1024-bit key or asking the provider whether it supports records over 255 characters.

Step 3: start authentication

Once the record is published, go back to Authenticate email, select the same domain and click Start authentication. When it is working, Google says the status at the top of the page changes to Authenticating email with DKIM.

Do not be alarmed if it does not change straight away. Google's setup page says "it can take up to 48 hours for DKIM authentication to start working", and that the console "might continue to display this message for up to 48 hours: You must update the DNS records for this domain" even when the record is correct. Check the record yourself rather than waiting on the console.

Step 4: check that it works

Confirm the record is visible in DNS, then confirm a real message is signed by your domain. A record that exists is not the same as mail that passes.

From a terminal:

dig +short TXT google._domainkey.yourdomain.com

You should get back a string beginning v=DKIM1. If you get nothing, the record is missing, misnamed, or not yet propagated. The DKIM checker does the same lookup for a domain and selector if you would rather not use a terminal.

Then send a message from a Workspace mailbox to an address at a different provider and open the original headers. Look for the Authentication-Results line. Google's help says to look for DKIM=pass or DKIM=OK. What matters for DMARC is which domain passed, shown as header.d= or header.i=@:

Authentication-Results: mx.example.net;
  dkim=pass header.d=yourdomain.com header.s=google

If header.s=google and header.d= is your domain, setup is done. If the signature that passed belongs to some other domain, your own key is not signing yet. Our guide to reading email headers walks through the rest of that block.

Common errors after setup

Most failures after a correct-looking setup come from something touching the message after Google signs it, or from too many signatures. Google's troubleshooting page lists the cases worth knowing:

What you see	What it means
Authenticate email shows blank host name and value	No DKIM record has been generated for that domain yet
dkim=fail, reason "body hash did not verify"	The message was changed in transit, for example by an outbound gateway, footer tool or disclaimer service
dkim=neutral	Often forwarding through a service that modifies content, or a valid signature that is not among the first five checked
DMARC fails although one signature passes	Gmail evaluates only the first five DKIM signatures; a passing one further down is ignored

The last row matters if mail passes through several systems that each add a signature. Google's troubleshooting page also asks you to check that services sending on your behalf do not use the DKIM length tag (l=), which RFC 6376 treats as a security weakness because it lets content be appended after the signed portion.

DMARC alignment and your other senders

The Google key only signs mail that leaves through Gmail, so every other service that sends as your domain needs its own DKIM setup. Newsletter platforms, CRMs, help desks and billing systems each sign with their own key. Most give you a CNAME or TXT record to publish under their own selector name, which can sit alongside google._domainkey without conflict, because the selector named in each signature tells receivers which key to fetch.

For DMARC, the signature has to be for a domain that matches your From address. Under RFC 7489, DKIM alignment is relaxed by default, so a signature for mail.yourdomain.com aligns with a From of yourdomain.com because they share an organisational domain. A signature for the ESP's own domain does not align, even if it passes. An ESP that signs only as itself will show dkim=pass in headers and still fail DMARC.

Before tightening DMARC, list every service that sends as your domain and check each one's headers the same way. That inventory is the first step in moving DMARC from p=none to p=reject. If you have not published a DMARC record at all, the DMARC generator builds a starting p=none record.

Practical checklist

1. Wait 24 to 72 hours after turning on Gmail before trying to generate a key.
2. Generate a 2048-bit key at Menu > Apps > Google Workspace > Gmail > Authenticate email, keeping the google prefix unless it is taken.
3. Publish the TXT record at google._domainkey, without the domain doubled, splitting the value into quoted strings if your host needs it.
4. Click Start authentication, and allow up to 48 hours.
5. Check with dig, then check a real message for dkim=pass with your domain in header.d=.
6. Set up DKIM separately for every other sender, then work on DMARC.

To check the rest of your domain's authentication at the same time, the deliverability audit looks up MX, SPF, DKIM, DMARC and blocklist status in one pass.