Google Workspace needs three TXT records: SPF with include:_spf.google.com, a DKIM key at google._domainkey generated in the Admin console, and DMARC at _dmarc. With all three, Gmail mail can pass DMARC on SPF and DKIM. In our scan of the Tranco top 1,000 domains on 19 October 2026, 198 of the 753 SPF records we found included _spf.google.com.
The records at a glance
| Record | Type | Host | Value |
|---|---|---|---|
| SPF | TXT | @ |
v=spf1 include:_spf.google.com ~all |
| DKIM | TXT | google._domainkey |
v=DKIM1; k=rsa; p=<key from Admin console> |
| DMARC | TXT | _dmarc |
v=DMARC1; p=none; rua=mailto:dmarc@example.com |
The DKIM key is unique to each domain. Google says you must generate a separate one in the Admin console for every domain you add.
SPF: the include and where it goes
Google's Set up SPF page gives this record for a domain that sends only through Google Workspace:
v=spf1 include:_spf.google.com ~all
There is nothing to switch on in the Admin console for SPF. You add the TXT record at your DNS host, with @ as the host for the root domain. Google recommends ~all rather than -all. That is the same choice google.com makes: on 19 October 2026 its own record read v=spf1 include:_spf.google.com ~all.
If other services send for you, merge them into one record. Google's own example for Workspace plus Microsoft 365 is v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all. Never publish a second v=spf1 record; two SPF records is a permanent error under RFC 7208.
Watch the lookup count. RFC 7208 allows 10 DNS lookups per SPF check. When we resolved _spf.google.com on 19 October 2026 it held IP ranges only, so it cost one lookup. Third-party includes often cost three or four each. Paste your domain into the SPF checker to see the running total.
Google notes that each subdomain that sends mail needs its own SPF record. A record on example.com does not cover news.example.com.
DKIM: generate the key in the Admin console
You need a super administrator account. Google adds a wait: after Gmail is turned on for a new organisation, it can take 24 to 72 hours before the Admin console will create a key.
- In the Google Admin console, go to Menu, then Apps, then Google Workspace, then Gmail.
- Click Authenticate email.
- Choose the domain in Selected domain.
- Click Generate New Record.
- Choose the key length (2048 or 1024) and keep the prefix selector as
googleunless that selector is already taken on your domain. - Click Generate, then copy the DNS Host name and the TXT record value.
- Do not click Start authentication yet.
At your DNS host, create a TXT record. The host is the selector plus ._domainkey, so google._domainkey for the default. The value has the form v=DKIM1; k=rsa; p= followed by the key.
The 255-character problem
A 2048-bit key is longer than the 255 characters a single DNS string can hold. Google's troubleshooting page gives the fix when your host rejects or truncates it: split the value into several strings, wrap each in double quotes, and enter them one after another in the same value field.
google._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...first part..."
"...second part...IDAQAB"
Resolvers join the strings back together. Many hosts accept the whole key in one field and split it themselves. Use 1024 only if your host cannot store the longer value at all.
Turn signing on
Google says the key can take up to 48 hours to work after you publish it. The Authenticate email page may also keep warning "You must update the DNS records for this domain" for up to 48 hours, even when the record is right. When a lookup returns the full key, go back to Authenticate email and click Start authentication. The status changes to "Authenticating email with DKIM".
Check the record with the DKIM checker, replacing example.com with your domain.
How Google Workspace aligns for DMARC
DMARC needs SPF or DKIM to pass and to align with the domain in the visible From address.
- DKIM alignment. Once you click Start authentication, Gmail signs with your own key, and the
d=tag in the signature is your domain. That aligns. Check it: theDKIM-Signatureheader should readd=yourdomain.com; s=google. - SPF alignment. SPF aligns when the Return-Path domain matches the From domain, as Google's DMARC page defines it. In Show original, read the
Return-Pathheader of a test message. If it shows your domain and_spf.google.comis in your record, SPF aligns too.
Having both is the point. A forwarded message usually breaks SPF but keeps the DKIM signature intact, so DKIM carries DMARC through mailing lists and forwards. An outbound gateway that rewrites messages, for example by adding a footer, breaks DKIM instead. Google warns about this on its DKIM page.
DMARC: add the record last
Google's Set up DMARC page asks you to let SPF and DKIM run for at least 48 hours before you publish DMARC. The host is _dmarc.example.com, and Google notes that some hosts add the domain name for you, so you may only need to type _dmarc. Start with monitoring:
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Google recommends a group or dedicated mailbox for reports, since a busy domain can receive hundreds of reports a day. If the report address is on another domain, that domain has to publish an authorisation record. The DMARC generator builds the record, and the analyzer reads the XML reports in your browser.
Checking the result
Send a message from a Workspace account to an outside Gmail address. Google says a test sent to yourself does not prove DKIM is on. In Gmail, open the message, choose Show original, and look for SPF: PASS, DKIM: PASS and DMARC: PASS. The DKIM-Signature header should show d=yourdomain.com and s=google.
Then check each record from outside: the SPF checker for the lookup count, the DKIM checker for the key, and the DMARC checker for the policy. Once a few weeks of reports show every legitimate sender passing, move from p=none to p=quarantine. The rollout guide covers that step.