Google Workspace SPF, DKIM and DMARC
The three records Google Workspace needs, and how to check they are live.
Google Workspace needs one SPF record, one DKIM record you have to generate yourself, and one DMARC record. Mail flows as soon as MX is pointed at Google, so all three are easy to skip — and all three are what decides whether your mail is trusted.
The step people most often miss is DKIM: Google does not sign your mail until you generate a key in the Admin console, publish it, and then press Start authentication. A published key with authentication off produces no signature at all.
The records Google Workspace needs
TXT · host @
v=spf1 include:_spf.google.com ~all
Google's recommended record when Workspace is your only sender. Move to -all once every other sender is accounted for.
TXT · host google._domainkey
v=DKIM1; k=rsa; p=<your generated public key>
Generate at Admin console → Apps → Google Workspace → Gmail → Authenticate email. Choose 2048-bit. The default selector is `google`.
TXT · host _dmarc
v=DMARC1; p=none; rua=mailto:<your reporting address>
Start here. Move to quarantine and then reject once aggregate reports show your senders aligning.
MX · host @
smtp.google.com (priority 1)
Google's current single-host inbound record. The older five-host ASPMX set still works; do not run both.
Values shown with placeholders are account-specific — copy the exact value from Google Workspace, never from a guide.
What goes wrong
- Adding a second sender eats your lookup budget fast
- `include:_spf.google.com` costs several lookups on its own because it nests. Add two or three more provider includes and you hit the limit of 10 and get a PermError, which DMARC counts as an SPF failure.
- Start authentication is a separate click
- Publishing `google._domainkey` does nothing until you return to the Admin console and start authentication for the domain. Until then messages carry no DKIM-Signature header.
- Gmail aliases and "send mail as" do not inherit DKIM
- Sending as another domain from a Gmail account signs with the authenticating domain, not the From domain, so DMARC alignment fails for that other domain unless it is also set up in Workspace.
- The default 1024-bit option is still offered
- The key-generation dialog defaults to 1024-bit on older tenants. Pick 2048-bit; if your DNS host rejects the longer value, it needs to be entered as multiple quoted strings in one TXT record.
Questions
- What is the SPF record for Google Workspace?
- `v=spf1 include:_spf.google.com ~all` as a TXT record on the root of your domain, when Workspace is your only sender. Add other senders as additional `include:` mechanisms in the same single record.
- What is the Google Workspace DKIM selector?
- `google` by default, so the record name is `google._domainkey.yourdomain.com`. You can choose a different selector prefix when generating the key, which is useful when another tool already owns `google`.
- Do I need DMARC for Google Workspace?
- Yes. Gmail and Yahoo require bulk senders to publish DMARC, and without it you get no reports about who is sending as your domain. `p=none` with a `rua` address is the safe starting point.
- Can I have two SPF records, one for Google and one for my marketing tool?
- No. Two `v=spf1` records is a PermError. Merge the includes into one record, or give the marketing tool its own sending subdomain with its own SPF record.
Fix this from ChatGPT or Claude
MailVakt is an MCP server, so your assistant can run this check itself, read the findings and walk you through the DNS edit. Ask it:
“example.com runs on Google Workspace. Check its SPF, DKIM and DMARC and tell me which records are missing or wrong.”
- Claude: Settings → Connectors → Add custom connector, then paste
https://mcp.mailvakt.com/mcp. - Cursor and other MCP clients: add the same address as an MCP server. Setup details.
Checks are free and need no account. Sign in only to collect DMARC reports for a domain.