Google Workspace needs three separate DNS records to authenticate your email — not one. Here is how to publish them in the right order, and why.
SPF
Add include:_spf.google.com to your domain’s existing SPF TXT record. Never create a second one: a domain must have exactly one SPF record, listing all of its authorised senders.
v=spf1 include:_spf.google.com ~allDKIM
Generate the key in the Google admin console (Apps → Google Workspace → Gmail → Authenticate email), publish the TXT record on the selector it gives you, then turn it on from that same page. Without that last step the key exists in DNS but Google signs nothing.
DMARC
Publish the monitoring policy on _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:your-address@yourdomain.comStay there long enough to identify every legitimate sender before tightening. The progression, step by step.
Common mistakes with Google Workspace
- A third-party sending tool configured through delegation breaks SPF alignment if its own domain is not added to the record.
- Email aliases do not automatically inherit DKIM signing from the primary domain.
- DKIM stays on the test selector until someone clicks « Start authentication » — the most common failure, and the most invisible: nothing announces that signing is off.
- Secondary domains and domain aliases are configured separately: each has its own DKIM key to generate and enable.
Checking that it holds
A setup that is correct on the day it is published does not necessarily stay that way: a new marketing tool, a contractor, a DNS migration, and alignment degrades quietly. Aggregate reports exist for that — provided someone reads them. Here is what they contain.
Once it is in place, Clarsend reads your reports and shows you what passes, what fails, and who is sending without your knowledge — without opening a single XML file.