Workspace gets you most of the way with two records, and then has one step that is genuinely easy to miss — the key exists, the DNS is right, and nothing is being signed because a button was never clicked. That is covered below.
1. SPF
example.com. IN TXT "v=spf1 include:_spf.google.com -all"
Historically this include nested three more (_netblocks, _netblocks2, _netblocks3), costing four lookups. Google has since flattened it — today it resolves to literal ranges and costs one:
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"
Worth re-checking your count
Any domain that squeezed itself under the limit back when Google cost four lookups has three spare it does not know about. The SPF Inspector shows the current attribution per include.
2. DKIM — generate, publish, then start
Three steps, and the third is the one that gets missed.
Google Admin console → Apps → Google Workspace → Gmail → Authenticate email
Generate — and choose 2048
Pick your domain and select Generate new record. You are offered a key length, and this choice is worth a moment: Workspace has historically defaulted to 1024-bit, and a great many domains took the default years ago and never revisited it.
That is not theoretical. Two Workspace domains, both on 1024-bit Google keys today:
RFC 8301 §3.2 sets 1024 as the floor and recommends 2048.
Leave the selector as google unless you have a reason. It is what every checker tries first, including ours.
Publish the TXT record
Google shows you a value to publish at google._domainkey.example.com. Unlike Microsoft, this is a real key in a TXT record, not a CNAME:
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…"
The 2048-bit record is longer than a DNS string
A single TXT string caps at 255 characters, and a 2048-bit key exceeds it. The record has to be published as multiple quoted strings, which receivers concatenate. Most DNS providers handle the split automatically; some silently truncate instead, and the result is a key that looks published and does not verify. If yours is one of them, that is the reason 1024 is still offered.
Then click Start authentication
Back in the console, the button reading Start authentication is what actually turns signing on. Until it is clicked, Google has generated a key, you have published it, and no outbound mail is being signed with it.
There is no warning about this anywhere outside the console. The DNS is correct, every DKIM checker reports a valid key, and mail arrives unsigned. It is the single most common Workspace misconfiguration.
3. DMARC
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Then read the reports and work up to enforcement — the staged path covers what each stage answers. Workspace users tend to have a longer tail of third-party senders than they expect, because anything that integrates with Gmail tends to end up sending as the domain.
4. Verify from outside
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The key resolving proves the DNS is right. It does not prove anything is being signed — only a real message does that. Send one to an external address and look for d=example.com in the DKIM-Signature header. If the header is absent entirely, go back and click Start authentication.
The DKIM Inspector probes google among its default selectors and reports the key length, which is the quickest way to find out whether you are on a 1024-bit key from years ago.
What Workspace does differently
You hold the key, and you rotate it. Google generates the pair and gives you the public half to publish, which means you can inspect it and choose its length — and also that nothing rotates it for you. Microsoft's CNAME model takes both the control and the chore away. Neither is strictly better; Workspace gives you a knob and the responsibility that comes with it.
Generation and activation are separate. Almost no other platform splits these, which is precisely why the Start authentication step catches people.
The MX set has changed. The long-standing five-record set is still valid and still widely deployed:
1 aspmx.l.google.com. 5 alt1.aspmx.l.google.com. 5 alt2.aspmx.l.google.com. 10 aspmx3.googlemail.com.
Newer setups get a single record instead — smtp.google.com, which is what Google uses for its own domain. Both work. If you have the old set, there is no need to change it, and no advantage to doing so beyond four fewer records to look at.
Failure modes particular to Workspace
| Symptom | Cause | Fix |
|---|---|---|
| Valid DKIM record in DNS, no signature on the mail | Start authentication was never clicked | Go back into Authenticate email and click it |
| Key published but does not verify | A 2048-bit key truncated at 255 characters by a DNS provider that will not split TXT strings | Re-publish as multiple quoted strings, or fall back to 1024-bit |
| Only some outbound mail is signed | DKIM is configured per domain — secondary and alias domains each need their own key | Repeat the whole process for each domain in the tenant |
| Mail from a Google Group fails DMARC | The group relays and may modify the message, breaking SPF and sometimes DKIM | Adjust the group’s posting and footer settings, or accept it and rely on the list rewriting From: |
| SPF count is higher than expected | An old guide told you Google costs four lookups and someone budgeted around it | Re-count — it is one today |
Honest limits
- Nothing rotates your DKIM key. Rotation means generating a new one, publishing it and switching over, by hand, on a schedule you have to remember.
- The 1024-bit default has left a long tail of weak keys on domains that set this up once and moved on.
- Workspace does not host MTA-STS. If you want it, the policy file has to be served from somewhere you control.
- There is no DMARC report parsing. Google sends you reports about other domains and gives you nothing to read your own with.
All of the above is done at your DNS provider and in the Google console — none of it needs CertaDNS. The parts that do not stay done are DKIM rotation, the growing SPF record, and reading the DMARC XML; Email Authentication covers those.