How to set up DKIM for Google Workspace

Which setup method should I use?

Use the DKIM record generated in the Google Workspace Admin console for the exact domain that sends mail. Google documents google as the default selector, but a different selector is appropriate when google._domainkey is already in use for that domain. Select a 2048-bit key if the DNS provider supports the record length. Use 1024-bit only when the DNS provider cannot support the longer key.

Google Workspace uses a TXT record for this setup. Do not replace an active selector just to match an example. If an existing Google Workspace DKIM key needs replacement, use a separate selector and follow a controlled key-rotation change so messages already in transit can still be verified.

The controls below show the documented Google Workspace DKIM configuration context. The path and labels were checked against Google's official setup guidance on 2026-08-13.

How do I configure DKIM for Google Workspace?

Google's sender guidance says all senders to Gmail need either SPF or DKIM, while bulk senders that send 5,000 or more messages per day to Gmail personal accounts need SPF, DKIM, and DMARC. Review Google's sender guidelines separately if that threshold applies to your organization.

1. Open Authenticate email

In the Admin console, open Apps > Google Workspace > Gmail > Authenticate email. The path is verified from Google's official documentation.

Select the domain used in the visible From addresses for the Google Workspace mail route you will test. Check the selected domain before generating anything, especially when the account has multiple domains or aliases.

2. Generate the DKIM record

Select Generate New Record. Choose the selector and key length, then generate the record. Google displays the DNS host name and TXT record value to publish.

Copy the complete values to the approved DNS change. The value is account-specific configuration, even though the public key is intentionally published in DNS. Do not place a generated key in a reusable DNS template.

3. Publish the Google Workspace DNS record

Google's DKIM instructions provide the host and value for the selected domain. DKIM verifiers query the selector under _domainkey, and RFC 6376 defines the DKIM public-key record syntax.

Record type: TXT

Host, illustrative only:

google._domainkey

Value, illustrative only:

v=DKIM1; k=rsa; p=<public-key-generated-by-google-workspace>

Do not publish this example. Generate the real host and complete TXT value in the Google Workspace Admin console for the account and domain you are configuring.

Some DNS providers append the zone name automatically. If your DNS zone is yourdomain.com, entering google._domainkey.yourdomain.com into a host field that appends the zone can create google._domainkey.yourdomain.com.yourdomain.com. Check the final fully qualified owner name before saving, then compare the published record with Google Workspace using Google's DKIM troubleshooting guidance.

4. Start authentication in Google Workspace

Wait until the exact generated TXT record resolves publicly, then return to Authenticate email and select Start authentication. Google documents that the Admin console can take up to 48 hours to recognize a correct DNS update.

Record the time the DNS answer appeared and the time authentication was started. If Google still reports a DNS issue, compare the authoritative DNS answer with the complete generated value before editing the record again.

5. Send a real test message

Send a new message through the same Google Workspace path that users or customers receive. Send it to a mailbox where you can inspect the raw message source.

Do not use a message sent before authentication started. Google notes that a message sent from an account to itself might not be signed, so use a separate receiving mailbox for this test. Test each materially different path, including any outbound gateway or relay.

How does this setup affect DMARC?

DKIM helps DMARC only when the domain in the passing DKIM signature aligns with the visible From domain. A signature can pass cryptographic validation yet fail DMARC alignment if its d= domain is unrelated to the From domain. RFC 9989 defines the alignment test.

Use the DMARC checker to inspect the published DMARC policy before changing it. A public policy lookup does not show which production senders are aligned or whether a receiver accepted a particular message. For the alignment failure case, see why a DKIM signature can fail DMARC alignment.

How do I validate the setup?

Check public DNS

Query the exact selector Google generated, including the sending domain:

dig +short TXT google._domainkey.yourdomain.com

Compare the authoritative DNS response and at least one public resolver response. You can also use Palisade's DKIM checker to inspect the publicly available record. A public lookup confirms DNS visibility. It does not prove Gmail is using that selector.

Check the vendor status in Google Workspace

Return to Authenticate email and confirm that authentication is active for the selected domain. This confirms that the Google Workspace account accepted the DNS configuration for that domain.

A green Google Workspace status is not proof that every outbound route signs mail. A gateway, relay, or separate sender can use a different configuration.

Inspect a delivered message

Open a newly delivered test message and inspect its raw headers. In a Gmail test mailbox, use Show original to open them. Confirm that DKIM-Signature includes the expected signing domain and selector. Then find the receiver-added authentication result.

RFC 8601 defines the Authentication-Results field, including dkim= results and the header.d= and header.s= properties used to identify the signing domain and selector.

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

Accept the DKIM setup only when the delivered message shows the expected selector, a trusted receiver result reports dkim=pass, and the signing domain aligns with the visible From domain when DKIM is expected to satisfy DMARC.

Review DMARC reports

After aggregate reports accumulate, review Google Workspace traffic separately from other sources that send as the same domain. RFC 9990 defines the source-level authentication and alignment results in aggregate reports. They do not replace investigation of an individual failed message.

Troubleshooting

Google Workspace cannot generate a DKIM record

Confirm that Gmail is enabled for the domain and that the account has the required administrative access. Google documents a 24 to 72 hour wait before key generation can become available after Gmail is activated.

The DKIM record does not resolve

Check the full owner name in authoritative DNS. A duplicated zone suffix, a truncated TXT value, or a record published under the wrong domain are likely causes. If a checker reports no record, compare the queried name with the generated host and review how to fix a missing DKIM record.

Google Workspace still reports a DNS update problem

Compare the exact TXT content from Authenticate email with the authoritative DNS answer. Google documents up to 48 hours for its status to reflect the DNS update. Do not generate a second key or replace the record before confirming that the selected domain, selector, and complete public key match.

DKIM passes but DMARC fails

Compare the visible From domain with header.d= in the receiver's Authentication-Results header. A passing DKIM signature from another domain does not provide DKIM alignment for DMARC. Investigate the aligned signing domain before changing the DMARC policy.

A direct Google Workspace message passes but gateway mail fails

Compare raw headers from a direct Gmail route and the gateway route. The gateway may modify signed content, remove a signature, or re-sign with another domain. This is an inference from the differing message evidence, not a Google Workspace diagnosis. Configure the final signing point after required modifications, then retest that same route.

Check the published Google Workspace DKIM record, then track the remaining senders

Use the DKIM checker to inspect what public DNS returns for the domain and selector you configured. Compare that result with the Admin console and a new delivered message before treating the change as complete.

A DNS lookup cannot prove that Google Workspace signs every production message, that the DKIM domain aligns for DMARC, or how a recipient will handle future mail. For IT teams and MSPs that need to identify all sending sources from DMARC aggregate-report data and prioritize the next review, Start with Palisade. A human should still review the evidence and apply any DNS or policy change.