This guide concerns your own domain in Google Workspace with Gmail. It does not describe personal Gmail account settings or the setup of an additional newsletter or website sending service.
Check prerequisites and the existing state
You need the super administrator sign-in specified by Google for this task, plus access to the DNS administration for the domain concerned. The menu area requires the Gmail Settings administrator privilege. First check which domain and sending route are involved and whether a DKIM configuration already works. Automatically prepared or existing settings are not a reason to generate a new key immediately.
DNS may be hosted by a different service from the domain registrar or Google Workspace. If you have several domains, select each one explicitly; their key values are not interchangeable. An outbound gateway may change messages after signing. Record such routes before setup, especially appended footers or other content changes.
General DKIM setup explains how to identify the signer, selector and DNS. The DKIM chapter explains d=, s= and the limits of signatures.
1. Generate the key for the correct domain
For a new setup, the documented Admin Console route is Apps → Google Workspace → Gmail → Authenticate email. Select your own domain, then Generate New Record. Interface labels may change with the language and product version.
Choose 2048 bits if your DNS administration supports the required complete TXT value. Google also offers 1024 bits. Distinguish this from the DKIM standard: RFC 8301 requires RSA signing keys of at least 1024 bits and recommends at least 2048 bits. An existing 1024-bit key is not invalid solely because of that size; 2048 bits is the sensible starting point for new keys.
The default selector is google. If that name is already occupied by a configuration still needed, use another prefix according to Google’s instructions. Record the value actually chosen. The later DNS query must match it; google is not a mandatory universal value.
After you select Generate, Google displays the DNS host name and TXT value. Copy both in full. Google manages the private key; you do not need to generate or upload a private key for this process. Do not select Start authentication yet.
The sequence and key selection are documented in Google’s DKIM setup guide, step 1.
2. Publish the complete TXT record
Open the active DNS zone for this domain. Copy the values from the Admin Console into the appropriate fields in your DNS administration:
On narrow screens, scroll the table sideways.
| DNS field | What to enter |
|---|---|
| Type | TXT |
| Name / Host | The displayed record name, in the format expected by your DNS administration. For the default selector, the relative name is google._domainkey. |
| Value | The complete TXT value provided by Google, including tags and the public key. |
| TTL | A value suitable for your DNS operation; it does not imply a guaranteed activation time. |
For example.com and the default selector, the full name would be google._domainkey.example.com. Check whether the interface appends example.com itself. Appending the domain suffix twice creates a different name.
This example shows only the format. PUBLIC_KEY_BASE64 is a placeholder, not a usable key:
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_BASE64"Do not shorten the real key. Long values can be represented as several character strings within one TXT record. The 255-octet limit applies to each string. Several separate TXT records at the same selector are not a valid way to split the key. The input format depends on the DNS provider; check its requirements before reducing key length because of an interface limit. Google: troubleshooting, RFC 6376, section 3.6.2.2.
Retrieve each additional Workspace domain’s own values from the Admin Console. A record for the main domain does not automatically configure another domain or a separate sending service.
3. Check DNS, start authentication and verify a message
Check the published record
Replace the example name and, where applicable, the selector with your actual values. On a system with dig:
dig TXT google._domainkey.example.com +shortOn Windows with the DnsClient module:
Resolve-DnsName -Name google._domainkey.example.com -Type TXT -DnsOnlyCompare the full public value with the Admin Console. The commands read DNS; they neither activate DKIM nor check a message. If a short response is empty or unclear, read the full DNS output, for example without +short, rather than treating a missing key as proven. DNS errors, cache state and an incorrect query name are separate possibilities.
Check activation separately
Once the matching DNS configuration has been published, return to Authenticate email for the same domain and select Start authentication. Google identifies a working setup with the status Authenticating email with DKIM. This is an administrative status; the evidence from reception of a specific message comes afterwards.
Google states that DKIM can take up to 48 hours to start working after the key is added. According to Google, the notice to update DNS records may also remain visible for up to 48 hours. This means neither that you must wait exactly 48 hours after every activation click nor that completion is guaranteed afterwards. Waiting does not correct a missing activation step or an incorrect record. Google: setup.
Check a message on the actual sending route
Use a message of your own, sent through the Workspace route under examination to a separate recipient you are authorised to use. For its verification, Google recommends another Gmail or Workspace recipient and rules out a message to yourself as a sufficient test. Open the original headers there; in Gmail, use Show original.
Identify the expected signature by d= and s=. Then read the trusted recipient’s corresponding DKIM result in Authentication-Results. An existing DNS key, a visible signature and dkim=pass answer three different questions. The result applies to the message examined and the observed route. A different From address, sending application or gateway may involve another route.
The guide to interpreting header findings explains the choice of evidence. Successful DKIM does not yet mean DMARC alignment with the visible From domain; follow with the DMARC assessment. A pass promises neither inbox placement nor harmless content. DMARC can pass through successful aligned SPF or DKIM. A published DMARC policy guarantees neither rejection, delivery nor complete phishing protection.
Typical paths when a signature is missing or invalid
On narrow screens, scroll the table sideways.
| Observation | What to check next |
|---|---|
google._domainkey returns no matching value | Compare the selector actually chosen, the selected domain, active zone and full record name. default is wrong only if the signer uses a different name. |
| Record visible, status not yet authenticating | Check whether Start authentication was performed for the same domain. Read the notes on DNS publication and timing in the correct context. |
| Expected signature absent from the message | Establish the actual Workspace sending route, activation and selected test recipient. One message does not prove that all mail from the domain is unsigned. |
Signature present, recipient reports fail | Check the key/selector and the recipient’s exact diagnosis; changes by a footer, gateway or forwarding are possible causes, not a diagnosis proven by fail alone. |
| The DNS interface rejects the 2048-bit value | Check the full value and support for multiple character strings; do not truncate it or create separate TXT records for the key. |
| Workspace message passes DKIM, newsletter message does not | Configure the additional service separately and check its own message. The Workspace key does not configure that service. |
The official Google troubleshooting guide covers administrative status, TXT values and message checks. Accurately diagnosing an error requires this evidence, not a guessed general ranking of common causes.
Prepare a key change
Where DKIM is already operating, a new key changes the sending route. Record the domain, current selector, DNS value and actual state beforehand. For a planned new key, use an unused selector under Google’s procedure rather than simply overwriting the old DNS value while it is still needed.
Before making a change, check the Google instructions current at that time and your domain’s state. Generating a new record, publishing it and having the signer use it are separate steps. This guide does not demonstrate uninterrupted Workspace rotation. After the change, check a new message for s=, d= and the recipient’s result. Retain older public keys for as long as messages that still matter need them; DNS caches and message transit times do not yield a universal deletion period.
A suspected key incident requires a separate response plan. The general DKIM rotation guidance explains the considerations; no automatic rotation service is promised here.
Choose the appropriate Wolf check
For the published DNS state, use the Email Security Check with the selector actually in use. It examines publicly discoverable keys within its limited scope. Failure to find one does not prove DKIM is absent; finding one does not prove active signing. The DNS check does not read messages or automatically monitor subsequent changes.
For a new message of your own, the free German test email beta with its limited initial eligibility and scope is available through the Email Check. Check the requirements stated there. The private test email finding and domain finding remain separate. A complete English service flow is not currently enabled.
If you need a working document after a change, the report overview explains what each document records. Keep the domain, selector, time, observed sending route and open questions separate. A DNS or test email finding is not comprehensive evidence for an audit, delivery or compliance; no purchase flow is offered here.
Frequently asked questions
Must the selector always be called google?
No. That is Google’s recommended default prefix. Google provides for a different prefix if the name is already in use. What matters is that the values in the Admin Console, DNS and the signature actually generated match.
Can I use another domain’s TXT value?
No. Obtain each domain’s own values from the Admin Console. Merely changing the name of another domain’s example key does not configure your domain.
Why does my message reach spam despite dkim=pass?
DKIM assesses a signature. Recipients consider other signals when accepting and classifying messages. The pass alone neither explains the inbox decision nor rules out other problems.
Further setup guides
DKIM foundations, general DKIM setup, SPF and understanding DMARC alignment complement this task.
More DKIM guidance: Microsoft 365
Sources and testing limits
Google: set up DKIM, Google: troubleshoot DKIM, RFC 6376, RFC 8301, Resolve-DnsName.
Primary sources checked on 29 September 2026; the Google setup page read for that check gave 24 September 2026 as its update date. No Workspace account was opened, no record changed, and no message or rotation tested in practice at Google. The local signature tests in the general DKIM guide do not demonstrate Google activation or delivery. The provider commands and schematic DNS example were not executed here; values and the interface must match the specific environment.