Set up DKIM for Google Workspace: DNS record, signing and checks

Google Workspace DKIM is complete only when messages leaving your domain carry a valid signature that aligns with the address in the visible From header. Generating a key in the Admin console does not enable signing by itself, and publishing a DNS record with a typo does not produce a useful signature. Complete all three stages: generate, publish, then start authentication.

Check the prerequisites first

You need access to the Google Workspace Admin console and to the authoritative DNS zone for the domain that appears after the @ sign in your users’ From addresses. The domain must be verified in Workspace. If DNS is managed by a registrar, Cloudflare, or another provider, use that provider’s DNS interface; Workspace only supplies the record.

Decide which sending domains need a key. A separate brand domain, a marketing subdomain, and the primary company domain may each require their own setup. The correct rule is simple: set up DKIM for every domain that Google Workspace sends as, rather than assuming a key on the parent domain covers every possible From domain.

Before changing anything, look for an existing TXT record at the selector Google will use. A domain can publish multiple selectors, but one hostname must have only one DKIM TXT value. Replacing another service’s record at the same hostname breaks that service’s signatures.

Generate the record in Admin console

In the Admin console, open Gmail’s authentication settings for the chosen domain and choose to generate a new record. Google shows a selector and a TXT value. Select a 2048-bit key where the interface offers the choice; it gives receivers a stronger public key while staying within normal DNS support.

The screen will provide a hostname shaped like this:

google._domainkey.example.com

Some DNS interfaces automatically append example.com. In those interfaces, enter only google._domainkey as the name. Others require the fully qualified hostname. Read the provider’s field hint and then inspect the resulting published record. An accidental google._domainkey.example.com.example.com record cannot be found by recipients.

Use Google’s displayed value exactly. It will look broadly like this, with a much longer public key:

google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Do not invent line breaks inside the key and do not add an SPF value to this record. DKIM, SPF, and DMARC are separate DNS records with separate jobs.

Publish and inspect the DNS result

Create the TXT record in the authoritative DNS zone, then query public DNS before turning signing on. From a terminal, run:

dig +short TXT google._domainkey.example.com

The answer should contain v=DKIM1, k=rsa, and the public-key value beginning p=. DNS providers may display a long TXT value as adjacent quoted strings. That is valid DNS behaviour as long as the strings reconstruct to the exact value Google provided.

If the lookup is empty, check the record name first. If it returns a value without v=DKIM1, a pre-existing record may be occupying the selector. If the key is visibly shortened, copy it again from Workspace rather than trying to repair individual characters.

Turn signing on and test a real message

Return to the same Workspace setting and choose to start authentication after the public lookup returns the record. Then send a fresh message from a mailbox at that domain to a Gmail or Outlook test inbox. It must be a new message: a message sent before signing started cannot acquire a signature later.

In Gmail, open the message menu and choose Show original. Look for a passing DKIM result and check the signing domain:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com;
  dmarc=pass header.from=example.com

The valuable detail is header.i=@example.com. A message can have some DKIM signature and still fail DMARC alignment if the signature belongs to another domain. For normal Workspace sending, the signing domain should align with the visible From domain or, under relaxed alignment, its organizational domain.

Also inspect the selector in the DKIM-Signature header. It should match the hostname you published. This catches a common transition error: the DNS record is live, but an old selector remains configured for sending.

Troubleshoot in the right order

If signing will not start, do not repeatedly regenerate keys. First confirm that public DNS returns the exact current record. Regenerating invalidates the previous public key and makes it harder to identify which value you actually published.

If signing starts but the test says dkim=fail, compare the selector from the message header with the selector in DNS. Then check whether a DNS proxy or security product is rewriting records. If the result says dkim=pass but dmarc=fail, inspect SPF alignment and the visible From domain rather than replacing the DKIM key. DMARC passes when either aligned SPF or aligned DKIM passes; a valid but unaligned signature is not enough on its own.

Avoid using an unrelated third-party signing service for messages Google Workspace sends unless you understand exactly how the message route and From domain work. Multiple valid signatures are permitted, but they do not substitute for a correctly configured Workspace signature on its own sending path.

Keep the record maintainable

Record the selector, the DNS owner, and the date it was enabled in your internal documentation. When rotating a key, publish the replacement before switching the sender, and leave the old key available while mail signed with it may still be evaluated. Do not delete a key merely because the new one is visible in DNS.

DKIM is only one part of the setup. Keep a single valid SPF record for the domain and publish DMARC so receivers can evaluate alignment and send aggregate reports. MailPilot checks those published authentication records alongside mailbox reputation, helping you spot a broken DNS change before it becomes an inbox-placement problem.