SPF (Sender Policy Framework, RFC 7208) authorizes specific servers to send mail for your domain. When you start sending through Google Workspace, you must publish a single SPF record at your domain apex that includes Google Workspace's sending infrastructure — otherwise the messages will fail SPF, your DMARC checks will fail, and your mail will land in spam or be rejected outright.
If you already publish SPF for another sender (Google Workspace for inbound, a marketing tool, your CRM), do not publish a second record. Merge the new include into the existing record. RFC 7208 §3 forbids multiple SPF records on the same name and receivers MUST return permerror when they see one.
Publish these DNS records
Add the following record(s) to your domain's DNS zone. Most registrars (Cloudflare, Route 53, Namecheap, GoDaddy) accept values exactly as shown.
- Type
TXT- Host
@- Value
v=spf1 include:_spf.google.com ~all
- Use `~all` (soft fail) initially. Move to `-all` once you've confirmed in DMARC reports that no legitimate sender is missing.
- If you also send through a marketing tool, merge its `include:` into this record. Do not publish two TXT records starting with `v=spf1`.
Where in Google Workspace
The SPF configuration lives in Admin console → Apps → Google Workspace → Gmail → Authenticate email.
Verify the records
Once published, run the SPF Checker on your domain to verify the lookup chain expands cleanly and stays under the 10-DNS-lookup limit.
dig +short TXT your-domain.comCommon pitfalls
- Generating a new DKIM key in the Admin console rotates the key — old signatures stay valid until they expire, but verify mail still signs cleanly afterwards.
- If you've migrated from another provider and inherited an SPF record with conflicting includes, Google's authentication check will appear to pass while DMARC still fails alignment. Always check the DMARC report, not just the Admin console green checkmark.